Business email compromise response plan: the money first, then the mailbox

Two incidents, not one

A business email compromise is a fraud and an intrusion at the same time, and they need different people moving at different speeds.

The fraud is a bank transfer. Its window is short, it is worked by finance and the bank, and nothing the security team does to the mailbox affects it.

The intrusion is somebody with access to a mailbox, and usually more than a password. It is worked by the security team, and doing it in the wrong order leaves the operator in place while everybody believes it is handled.

Start both. Do not let either wait for the other. The first-hour versions are invoice fraud, payment sent and cloud account compromise; this is the plan around them.

Track A: the money

Owner: finance, with the incident lead informed.

1. Phone the sending bank's fraud line now. Not email, not the relationship manager's voicemail. Ask for a recall of the transfer and for the receiving bank to be contacted to freeze the funds. Have the amount, date, reference and beneficiary account details in front of you.
2. Report it to law enforcement the same day. In the United States that is a complaint at ic3.gov with the transaction details; elsewhere, your national fraud reporting route. Recovery depends heavily on how quickly the receiving bank is reached, and the likelihood falls fast once funds have been moved onward.
3. Stop the next payment. Freeze changes to supplier bank details, and hold any payment to an account that was changed in the last ninety days until it has been confirmed by phone on a number taken from a contract or an old invoice, never from the email that asked for the change.
4. Tell the real supplier or customer. The thread may be compromised on their side, not yours. Until you know which, assume both.
5. Preserve the fraudulent messages as evidence, with full headers, before anyone deletes them to be tidy.

Track B: the mailbox

Owner: security team.

B1. Evict, in this order

The order matters because each step closes something the previous one does not.

1. Revoke sessions and refresh tokens for the account.
2. Reset the password, then require re-registration of MFA. Check the registered methods first: an operator who added their own authenticator or phone number keeps access through every reset until it is removed.
3. Export, then remove, inbox rules. Export first. A rule that moves anything containing "invoice" or "payment" to RSS Feeds tells you what they were hiding and is evidence of intent.
4. Remove forwarding. Mailbox-level forwarding (ForwardingSmtpAddress) is not an inbox rule and does not show up if you only look at rules.
5. Review OAuth consent grants and enterprise applications for the user. A grant with Mail.Read and offline_access never meets a login prompt, so it survives everything above. Microsoft's app consent playbook has the queries.
6. Check delegates and mailbox permissions, including SendAs and FullAccess granted to another account.
7. Remove the account from privileged roles until the investigation closes, if it held any.

B2. Scope

Question	Where the answer is
When access began	Entra sign-in logs: first sign-in from infrastructure the user does not use. Look at the token and session identifiers, not only IP addresses
How they got in	The phishing message (search the mailbox and quarantine for the lure), an adversary-in-the-middle proxy (a successful MFA sign-in from an unfamiliar ASN seconds after the user's own), or a consent grant
What they read	MailItemsAccessed in the unified audit log, where your licence records it. Be aware of its throttling: above a threshold in a day it stops recording individual items
What they sent	Sent Items is not reliable, operators delete from it. Use message trace
Who else	The same lure to other recipients, the same sign-in infrastructure against other accounts, and the same OAuth application across the tenant
Internal spread	Messages sent from the compromised mailbox to colleagues. Internal phishing from a trusted sender has a far higher success rate than the original lure

Retention decides how much of this you can answer. Check how far back your sign-in and audit logs go before you promise anybody a complete account.

B3. Notify

If the operator could read the mailbox, they could read everything in it. Whether that is a reportable personal data breach depends on what the mailbox held and on your jurisdiction, and it is a decision for counsel and the data protection lead, made on the evidence from B2.

Tell the people whose threads were hijacked. They are the next targets.

Recover and harden

The fixes that would have prevented the most common versions of this:

• Phishing-resistant MFA (FIDO2 or passkeys) for finance, executives and administrators. Push and code-based MFA are relayed by adversary-in-the-middle kits.
• Restrict user consent to applications, with an admin workflow for the rest.
• Block automatic external forwarding at the tenant, and alert on rule creation that moves or deletes by keyword.
• Conditional access on device compliance or location for the accounts that can move money.
• A payment change process that cannot be completed by email alone. This is the control that stops the fraud even when the intrusion succeeds, and it is a finance control, not a security one.

Review

Ask what finance would have needed to see to refuse the payment, and what the security team would have needed to see to notice the sign-in. They are usually different gaps, and a review that finds only one of them has looked at half the incident.