Business Email Compromise Response Playbook: Stopping Payments and Evicting Attackers

In a business email compromise, the money usually leaves before the security team hears about it, and every hour of delay makes it harder to get back. BEC combines two incidents at once: a fraudulent payment that finance and the bank must try to stop, and a compromised or impersonated mailbox that security must contain and clean. This playbook template covers both tracks in parallel, with named roles, decision points, the evidence to preserve and the reporting routes in the US and UK. It is written for incident responders, finance and treasury leads and the executives who sign off decisions, and it uses Microsoft 365 as the worked example because that is where most mailbox takeovers are investigated. Replace every [Organisation] placeholder and adapt the steps to your own platforms and banks.

How to use this template

• Adopt it as a sub-playbook of [Organisation]'s incident response plan. See the Incident Response Plan Template.
• Fill in every placeholder in square brackets: names, phone numbers, bank fraud lines, thresholds and approval limits. A BEC playbook with blank bank contacts fails in the first hour.
• Run two tracks at once. The payment track (steps marked P) and the mailbox track (steps marked M) start together. Never hold the bank call while the mailbox is investigated.
• Keep decision points explicit. Each "Decision" line names who decides and on what evidence.
• Test it twice a year with a tabletop exercise that includes finance, and update it after every real case.

The FBI calls BEC "one of the most financially damaging online crimes". The IC3 2024 annual report recorded 21,442 BEC complaints with reported losses of about US$2.77 billion. This template is guidance, not legal advice.

1. Scope and triggers

1.1 This playbook applies to any [Organisation] mailbox, payment process or supplier relationship where email (or a follow-up call, chat or video message) was used to request a payment, a change of bank details or sensitive data under a false identity.

1.2 Variants in scope:

1.3 Triggers that invoke this playbook: a supplier chasing an unpaid invoice that [Organisation] believes it paid; a staff report of an odd payment request; an alert for a new external forwarding rule or hidden inbox rule; a bank query about a payment; a customer reporting a fraudulent invoice from an [Organisation] address.

1.4 Out of scope: commodity phishing with no payment or mailbox impact, which follows the Phishing Incident Response Playbook. Deepfake video or voice cases also follow the Deepfake CEO Fraud Response Playbook.

2. Roles and contacts

2.1 Keep an out-of-band contact sheet: [Organisation]'s bank fraud lines for each bank ([Bank name, 24/7 fraud number]), cyber insurer hotline ([number]), external incident response retainer ([number]) and law enforcement routes (section 7). Store it outside the mail system, because the mail system may be the compromised channel.

3. Detection and triage

1. Record the report (Incident lead, minute 0). Time reported, who reported it, payment amount, date, beneficiary bank and account, and the message chain.
2. P1: Check whether money has moved (Finance lead, within 15 minutes). Identify sent, scheduled and pending payments to the suspect beneficiary, and stop anything not yet released.
3. M1: Establish whether an [Organisation] mailbox is involved (Security analyst). Read the full headers: was the message sent from [Organisation]'s tenant, from a lookalike domain, or from a genuine supplier domain? A message from the real supplier domain means the supplier may be compromised.
4. M2: Look for the classic signs of mailbox takeover. Microsoft lists these: suspicious inbox rules that forward mail or move it to folders such as Notes, Junk Email or RSS Subscriptions; recently added external forwarding; unexpected messages in Sent Items or Deleted Items; unexplained password changes or lockouts.
5. Decision: severity (Incident lead). Critical if money has left or an internal mailbox is attacker-controlled; high if a payment was requested and stopped; medium if a lookalike-domain attempt was blocked with no loss.

4. Containment

Payment track

1. P2: Call the bank now (Finance lead). The IC3 guidance is that "time is of the essence": contact your financial institution immediately, request a recall of the funds and provide any indemnification documents the bank needs. Ask the bank to contact the receiving bank. Give the transaction reference, amount, value date and beneficiary details.
2. P3: File with law enforcement in parallel (Legal or Finance lead). In the US, file at ic3.gov as soon as possible; IC3's Recovery Asset Team works with banks through the Financial Fraud Kill Chain to freeze funds. Section 7 lists the UK routes.
3. P4: Freeze the beneficiary in [Organisation]'s payment system and block further changes to that supplier's bank details pending verification.
4. Decision: second payment? If the attacker asks for more, the Incident lead and law enforcement decide whether to keep the thread open. Never send further funds.

Mailbox track

1. M3: Disable the account or block sign-in (Email administrator). Microsoft prefers disabling the account; if that is not possible, reset the password and do not send the new password by email. For synchronised accounts, reset in Active Directory; Microsoft advises resetting twice.
2. M4: Revoke sessions and refresh tokens with Revoke-MgUserSignInSession -UserId <UPN>. A password reset alone does not end existing sessions or app passwords.
3. M5: Remove attacker persistence: forwarding addresses, inbox rules (including hidden ones), unfamiliar MFA methods and devices, delegates, and app consents (Remove-MgOauth2PermissionGrant, Remove-MgServicePrincipalAppRoleAssignment). See the Entra ID Applications and Consent Guide.
4. M6: Block attacker infrastructure: sender addresses, lookalike domains and IP ranges at the mail gateway; purge the attacker's messages from other mailboxes.
5. Decision: disruptive containment (Executive sponsor). Disabling a senior executive's or finance mailbox mid-quarter is disruptive; the default is to disable, with a temporary clean account if needed.

Evidence to preserve before deleting anything: export inbox rules and forwarding settings, the full message chain with headers, sign-in and audit logs for the period, the bank payment instructions and the call log with the bank. Microsoft notes that mailbox auditing must already be enabled for scoping to work. See the Digital Forensics (DFIR) Guide.

5. Eradication

1. Find the entry point (Security analyst): credential phishing, adversary-in-the-middle session theft, consent phishing, password reuse or a compromised supplier. See the AiTM Phishing Guide.
2. Scope what the attacker read. In Microsoft 365, search the unified audit log for MailItemsAccessed. Sync events mean a whole folder was downloaded and every item in it is treated as compromised; bind events record individual messages by InternetMessageId.
3. Hunt across the tenant for the same IPs, user agents, app IDs and rule names in other mailboxes. BEC actors often hold several accounts.
4. Check the supplier side. If messages came from a genuine supplier domain, tell the supplier through a known contact, not by replying. Fraud can also come from abused legitimate infrastructure: in TruffleNet, attackers used a compromised cloud account's email service, signed with a stolen DKIM key, to send a fake vendor invoice.
5. Decision: close eradication (Incident lead) only when no attacker activity has been seen since revocation and every persistence item found has been removed.

6. Recovery

1. Re-enable the account with a new password, phishing-resistant MFA and fresh app passwords only where unavoidable. See the Phishing-Resistant MFA Guide.
2. Confirm genuine supplier bank details by calling a number held in [Organisation]'s vendor master, never one from the suspect email.
3. Reissue legitimate payments that were delayed, with dual approval.
4. Track the recall with the bank and law enforcement, and record amounts frozen, returned and lost for insurance.
5. Monitor the affected accounts closely for [30] days for new rules, consents and sign-ins.

7. Communication and notification

Use the mailbox audit results from section 5 to decide whether personal data was exposed. Do not speculate about recovery of funds in external messages.

8. Post-incident review

1. Hold the review within [10] working days with security, finance, procurement and the affected teams.
2. Produce a timeline: first attacker access, first fraudulent message, payment release, detection, bank call, revocation.
3. Identify the control that would have stopped it. In the Arup deepfake fraud, 15 transfers were made before the employee checked with head office directly; a mandatory callback would have come first.
4. Assign owners and dates to every action and report progress to the executive sponsor.

Implementation guidance

• Pre-stage the prerequisites: mailbox auditing on for every licence tier, log retention long enough to cover slow-burn BEC (attackers often watch threads for weeks), and admin roles for the people in section 2.
• Write the finance controls into policy: callback verification for any new or changed bank details, dual approval above [threshold], and a rule that urgency or secrecy in a request triggers verification. The FBI warns to be especially wary when the requester presses you to act quickly.
• Prevent the persistence you will otherwise be removing: block automatic external forwarding, restrict user consent to verified apps, and alert on new inbox rules and consent grants. See the Microsoft 365 Security Guide and the Email Security Guide.
• Small organisations: combine roles (often one IT provider plus the finance director), but keep the bank number, IC3 or Report Fraud route and the revocation steps on one printed page.
• Large organisations: automate the mailbox steps as a SOAR runbook triggered by a forwarding or rule alert, with human approval for disabling executive accounts.
• Exercise it: a tabletop where the bank call is made on a real (test) line, and a technical drill that runs the revocation commands against a test account.

References: FBI IC3: Business Email Compromise, The $55 Billion Scam · FBI IC3: 2024 Internet Crime Report · FBI: Business Email Compromise · NCSC: Reporting a scam email · Microsoft: Responding to a compromised email account · Microsoft: Detect and remediate illicit consent grants · Microsoft: Use MailItemsAccessed to investigate compromised accounts

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Email Identity and BEC Guide · Phishing Guide · Incident Response Guide · Payment Fraud Guide · Identity Incident Response Playbook