Microsoft 365 business email compromise — the response playbook

This playbook fires the moment you have credible signal that a Microsoft 365 (or Google Workspace) mailbox is under attacker control: an impossible-travel sign-in, a user reporting a payment they did not authorise, a finance clerk noticing an altered bank-account detail on an invoice, or a Defender/Entra alert on an anomalous OAuth grant or a newly created inbox rule.

In scope: mailbox account takeover, fraudulent payment redirection (both vendor-invoice and CEO-fraud variants), and the OAuth-token / device-code variant where the attacker never needed the password.

Not in scope: commodity credential phishing with no mailbox access yet (handle as a routine password-reset event), and on-premises Exchange compromise (a different eradication surface). If ransomware or data-extortion is also present, run this playbook in parallel with your ransomware plan — the identity-containment steps here come first.

Two clocks run at once and neither waits for your investigation to finish.

The money clock. If a fraudulent wire has left, the practical recovery window is measured in hours. The FBI Financial Fraud Kill Chain works best when the originating bank and IC3 are engaged within roughly 72 hours of a fraudulent transfer; after that, funds are typically layered away. Domestic ACH and SWIFT recalls have their own, shorter, bank-specific windows. Treat *any* suspected fraudulent payment as a same-hour escalation.

The regulatory clock. If the compromised mailbox held personal data — and a mailbox almost always does — GDPR Art. 33 gives you 72 hours from awareness to notify the supervisory authority. If you are an essential or important entity, NIS2 Title 13 (24h early warning / 72h notification) may also fire; for financial entities, DORA Art. 19 runs in parallel.

Start a timestamped incident log now. The *should-have-known* point, not the *confirmed* point, starts both clocks.

Two tracks run in parallel. Do not serialise them.

Track 1 — freeze the money (finance + legal lead): - Call the originating bank fraud desk. Request a wire recall / SWIFT recall on the specific transfer, by reference number. - File an IC3 complaint at ic3.gov and cite the Financial Fraud Kill Chain. - Freeze every pending or scheduled payment to the same counterparty; re-verify any recently changed bank detail out-of-band, on a phone number you already held — never one taken from the email.

Track 2 — contain the identity (SOC / IR lead): - Revoke sessions and refresh tokens — do not merely reset the password. A password reset alone leaves a stolen OAuth refresh token fully valid. In Entra: disable the account, then *Revoke sign-in sessions*, which invalidates issued refresh tokens. - Reset the password and re-register MFA from a known-clean channel. - Block the account from mail flow if outbound phishing or exfiltration is ongoing. - Before you change anything you can preserve, capture the Unified Audit Log and message trace for the account (see the evidence checklist).

The single most common error at this gate is treating a BEC like a password compromise. Modern BEC is a *token* compromise.

A password reset changes one credential. The attacker planted persistence that outlives it. Hunt and remove each:

• Inbox rules. Look for rules that move, delete, or mark-as-read messages containing words like *invoice, payment, wire, bank, remittance*, or that forward to an external address or an obscure folder (RSS Feeds, Conversation History). Attackers use these to hide the victim replies from the victim.
• Mail forwarding. Check both mailbox-level forwarding (SMTP forwarding address) and transport rules. Remove external auto-forwarding and disable it tenant-wide if you have no business need for it.
• Consented OAuth applications. Review enterprise applications and user-consented app registrations tied to the account. Revoke any unrecognised or over-permissioned grant (*Mail.ReadWrite*, *Mail.Send*, *offline_access*). This is the persistence that survives every password reset.
• Registered devices and sessions. Revoke any registered device or authentication-transfer session you do not recognise.

Use Microsoft Defender Threat Explorer to trace the delivered phishing lure and find every other recipient in the same campaign — account takeover is rarely a single mailbox.

Close the initial-access door. The current dominant vector is device-code-flow phishing: the victim is shown a legitimate Microsoft device-code page and unknowingly authorises the attacker. The FBI May 2026 Kali365 advisory documents this phishing-as-a-service kit doing exactly that at scale. Deploy a Conditional Access policy that blocks device code flow for all users bar a documented exception list, and block legacy authentication.

Notify. File the GDPR Art. 33 notification within 72h if personal data in the mailbox was accessible; file NIS2 / DORA notifications if in scope; retain the IC3 complaint reference. If customer or supplier data was exposed through the mailbox, plan the downstream notifications now.

Recover. Re-enable the account only after tokens are revoked, MFA is re-registered as phishing-resistant (FIDO2 / passkey, not SMS), persistence is confirmed removed, and the audit log is preserved. Warn any counterparties who received phishing from the compromised mailbox — before they, too, wire money to the attacker.

Preserve these before remediation overwrites them, ordered by which gate consumes them:

• Unified Audit Log export for the account (sign-ins, rule creation, consent grants, message access) covering the incident window plus 30 days prior.
• Message trace for the account (the inbound lure and any outbound fraudulent mail).
• Sign-in logs showing the anomalous token use: source ASN/IP, device, and the OAuth application ID that was used.
• The fraudulent email(s) with full headers, plus the altered invoice or payment instruction.
• Bank correspondence and the IC3 reference number for the money-recall track.
• The list of inbox rules, forwarding addresses, and OAuth grants removed, each with a timestamp and the operator who removed it.

The hard part is not the list — it is having the telemetry when you need it. Mailbox audit logging must be on *before* the incident, and sign-in and token logs must be retained long enough to reconstruct the takeover. This is where a continuous behavioural view pays off: the AI Traffic Analysis pillar of Zero Hunt watches the behavioural layer — an OAuth refresh token replayed from a new ASN, a burst of inbox-rule creation, an anomalous outbound exfiltration pattern — the signals that survive a password reset and that MFA never sees, and it keeps the timestamped record the notification gates will ask for.

• Resetting the password and declaring victory. The stolen refresh token and the consented OAuth app both survive a password reset. Revoke sessions and audit app consents, every single time.
• Serialising money and identity. Finance waits for IT to *finish investigating* before calling the bank, and the recall window closes. Run both tracks in the first hour.
• Trusting an in-band channel to verify. Confirming a changed bank detail by replying on the same email thread — which the attacker inbox rule is silently intercepting. Verify out-of-band, on a number you already held.
• Destroying the timeline. Deleting the malicious rules and forwarding before exporting the audit log, leaving no evidence of what was exfiltrated or when. Preserve first, remediate second.
• Fixing one mailbox. The lure went to a distribution list; three other accounts are already compromised and quiet. Pivot from the delivered message to every recipient.

A single BEC can trigger several regimes off the same evidence base:

• GDPR Art. 33/34 — personal data in the mailbox was accessible: 72h supervisory-authority notification, plus data-subject notification where the risk is high.
• NIS2 Title 13 — essential/important entities: 24h early warning, 72h notification, 1-month final report. Same evidence, a different summary.
• DORA Art. 19 — financial entities: major-incident reporting on the DORA cadence.
• Law enforcement — IC3 in the US; in Italy, a *denuncia* to the Polizia Postale, and, for the funds-recall track, the victim bank fraud office.

Build the evidence chain once and export per regime, rather than running parallel trails. See the identity-provider compromise playbook when the takeover reached the IdP itself, and the exfiltration-only ransomware angle when the mailbox theft is the precursor to extortion.