A Phished Mailbox, an Inbox Rule, and Six Outbound Emails
At a 120-person logistics company, the accounts-payable coordinator clicked a link in an email that appeared to be a SharePoint document share and entered her credentials on a lookalike page. She did not mention it. Four days later, a long-standing customer emailed the sales director to confirm a change of bank details 'per the coordinator's message,' and a second customer asked why the coordinator had sent an invoice reminder from a different-looking address. Investigation shows the coordinator's account has an MFA method registered that she does not recognize, an inbox rule that moves any message containing 'invoice' or 'payment' into the RSS Feeds folder and marks it read, and six outbound messages to customers from the previous day. She is currently signed in on her desktop, her phone, and a session from an IP address in another country. Mail filtering did not block the phishing page because it was hosted on a legitimate cloud domain.
1. State the first five actions in order, and explain why each step comes where it does.
Read the worked answer
The order is governed by one principle: cut the attacker's live access before you change credentials, or you hand them the new password.
- Revoke sessions and refresh tokens first. Kill all active sessions and force reauthentication. Resetting a password while a stolen refresh token is valid lets the attacker stay in - this is the most common containment mistake in mailbox compromise.
- Remove the attacker's MFA method, then reset the password. Delete the unknown authentication method before resetting, otherwise the attacker can re-register. Reset from an admin context, then require re-registration on a known device.
- Delete the inbox rule and check for forwarding, delegates, and transport rules. The RSS Feeds rule is deliberate hiding: mail arriving and never seen. Search for any forwarding address and any mailbox delegation added in the same window.
- Check for application consent and app passwords. A registered OAuth app or legacy app password survives a password reset and re-establishes access.
- Preserve evidence, then notify. Export sign-in logs, mailbox audit entries, and the six outbound messages before cleanup; the customer impact and any regulatory clock depend on them.
Containment first, eradication second, notification third - notification before you know the scope produces a second, worse message.
2. Define the scope of the incident. What must you determine about the six emails and the account's data before you brief leadership?
Read the worked answer
Scope has three dimensions: who was contacted, what was taken, and whether anyone else is compromised.
Outbound messages. Pull the six messages and their recipients. For each, determine: was it a bank-detail change, a data request, or a reply inside an existing thread? Thread hijacking is more convincing than a cold email and raises the risk that a customer acts on it. Ask which customers replied, and check whether the RSS rule hid those replies from the coordinator - that is why nobody noticed for four days.
Data access. Review mailbox audit logs and file-access logs for the attacker's IP and token. Did they read attachments, download a mailbox export, or open SharePoint/OneDrive files? AP data usually means bank details, vendor lists, and remittance advices.
Lateral exposure. Check whether the account had any admin role, shared mailbox access, or was a member of a group that can reset passwords. Then search tenant-wide for the same inbox-rule pattern and the same MFA-registration pattern on other accounts - phishing campaigns hit several people and only one reports it.
Brief leadership with a timeline, a confirmed-contact list, and a 'not yet known' list. Customers whose bank details were targeted need a phone call from a known number, not an email.
3. The CFO wants a single control that would have prevented this. Evaluate the realistic options.
Read the worked answer
No single control prevents it, and saying so is part of the answer - but one control changes the outcome more than any other.
Phishing-resistant MFA (FIDO2 security keys or passkeys) for finance and AP. A lookalike page that harvests a password is defeated when the credential is bound to the real domain. Push-based and SMS MFA can be relayed in real time by the same proxy that hosts the fake page, which is what likely happened here. This is the control with the highest ratio of prevention to cost, and it should go to the ~15 people who can move money first.
Number matching / additional context in MFA prompts is a cheap partial fix if hardware keys are not funded this quarter - it defeats prompt bombing but not a real-time relay.
Conditional access (block legacy auth, restrict impossible-travel sign-ins, require compliant devices for mail) limits what a stolen token can do, and would have flagged the foreign session within minutes.
Alerting on inbox-rule creation and new MFA registration is detection, not prevention - but this incident ran four days precisely because nobody watched. Both belong in the plan.
What not to claim: 'more phishing awareness training.' Training is worth having, but it is a probability reducer, not a control, and making it the headline tells staff that the next compromise is their fault.