BEC Response Playbook: Containing a Compromised Account in Microsoft 365 or Google Workspace

Why this matters more than most vulnerability write-ups

Most of what gets covered on a security blog is a CVE: a flaw in software that a vendor eventually patches. Business email compromise isn't that. There's no patch for it, because the "vulnerability" is a combination of trust, urgency, and the fact that an email account, once accessed, looks completely normal to everyone except the person watching the sign-in logs.

The numbers back up why this keeps showing up in incident response retainers. The FBI's Internet Crime Complaint Center has tracked BEC losses since 2013, and its most recent public update puts total reported BEC/EAC exposed losses at roughly $55 billion for the period from October 2013 through December 2023.[1] In the FBI's 2024 Internet Crime Report, BEC was the second-highest-loss crime category tracked by IC3, with 21,442 complaints and close to $2.8 billion in reported losses that year alone.[2] Those are reported figures from victims who filed complaints — actual totals are almost certainly higher, since underreporting is common in fraud cases generally.

This playbook focuses on the two platforms most small and mid-size organizations actually run their email on: Microsoft 365 and Google Workspace. It's written for the person who gets the call at 4pm on a Friday — not a red-team exercise, and not a vendor pitch.

What actually happens during a BEC incident

Strip away the vendor diagrams and a BEC incident usually follows a short, boring sequence. An employee's credentials get phished, or an attacker abuses a malicious OAuth app grant that never asked for a password at all. The attacker signs in — sometimes from an unfamiliar country, sometimes through a residential proxy that looks unremarkable in a login log. They don't do anything dramatic. They read. They watch for invoices, payroll threads, and wire instructions. Then, at the right moment, they either send an email from the real account or set up a look-alike domain and insert themselves into an existing conversation.

The mechanism that makes this durable is persistence: a hidden inbox rule that forwards or deletes certain messages, or a mail-forwarding address that quietly BCCs everything to an external mailbox. That's usually the piece defenders miss on the first pass, because resetting a password does nothing to remove a rule that's already sitting inside the mailbox. Google's own guidance on compromised accounts makes this point directly — suspending a user resets sign-in cookies and OAuth tokens, but the investigation into what the attacker changed still has to happen separately.[3]

Containment in Microsoft 365

Microsoft's own phishing investigation playbook lays out a five-stage workflow: identify the message, scope affected users, assess interaction, identify follow-on activity, then contain and remediate.[4] For a suspected BEC account takeover specifically, the containment stage is where speed matters most.

• Disable the account in the Microsoft Entra admin center, or via PowerShell, to block new sign-in tokens.
• Revoke sessions so refresh tokens already issued to the attacker stop working immediately — disabling the account alone doesn't invalidate tokens that were issued before the change.
• Reset the password and re-register MFA, since an attacker who had mailbox access may also have registered their own authentication method.
• Search the unified audit log for the incident window, looking specifically for New-InboxRule, Set-Mailbox, Add-MailboxPermission, and mail-forwarding changes.
• Review delegate and Send-As permissions on the mailbox and strip anything that wasn't there before the incident.
• Check OAuth app consents granted to the account — a surprising number of BEC incidents involve a malicious app grant rather than a stolen password at all.

Microsoft frames this as moving "from detection to containment without skipping critical validation steps", and that sequencing matters: resetting a password before you've captured the sign-in and audit logs can erase the evidence you need to scope the incident properly.[4]

Containment in Google Workspace

Google's admin guidance follows a similar shape, adapted to Workspace's console. The first move is to suspend the suspected account, which automatically resets sign-in cookies and OAuth tokens.[3] From there:

• Review User log events in the Admin console (or the Security Investigation Tool, where licensed) for suspicious or flagged sign-ins over the relevant window — Google retains this data for up to six months.
• Check OAuth log events in the security report for third-party app grants the user didn't authorize.
• Use Email log search to review delivery logs and confirm what actually left the domain during the compromise window.
• If the compromised user had admin rights, review the admin audit log for configuration changes made during the incident.
• Check for mobile devices associated with the account and wipe anything unrecognized.

As with Microsoft 365, the platform-level lockdown is necessary but not sufficient. It stops new access; it doesn't tell you what already happened, which is why the log review has to run in parallel, not after.

The part that's easy to skip: stopping the money

Account containment protects the mailbox. It does nothing for a wire transfer that's already in flight, and in a lot of BEC cases, that's the part that actually costs money. If a fraudulent payment has gone out, the response has to run on a separate, faster track than the technical investigation.

In practice this means working two tracks at once. Call the bank that sent the wire and ask specifically for a fraud recall — the sending bank is the one that can initiate a SWIFT or Fedwire recall request to the receiving institution. At the same time, file a complaint with the FBI's Internet Crime Complaint Center at ic3.gov and explicitly request the Recovery Asset Team. When a qualifying transfer is reported quickly enough, IC3 can coordinate with the receiving bank through what's commonly referred to as the Financial Fraud Kill Chain, attempting to freeze funds before they're withdrawn.

It's worth being precise about how strong this evidence is: the widely cited figures for the Kill Chain's effectiveness — a reported 74% success rate and roughly $328 million frozen in fiscal year 2021 — trace back to FBI congressional testimony reported secondhand, not a document IC3.gov itself was directly opened and confirmed during this research.[5] Treat those numbers as reported estimates rather than independently audited statistics. What's consistently repeated across sources, including law-firm and financial-services guidance, is that the effective window is short — often described as roughly 24 to 72 hours — and that domestic transfers caught early have meaningfully better odds than transfers that have already crossed into international correspondent banking.[5][6] Never treat a stated recovery success rate as a promise; the process is a triaged federal intervention with thresholds and conditions the FBI sets and can change.

If a payment has already gone out, don't wait for the technical investigation to finish before calling the bank. The two tracks — account containment and payment recall — should start in the same hour, run by different people if you have them.

Building the response, not just running it

A playbook that only exists in someone's head gets followed inconsistently, and BEC is exactly the kind of incident where inconsistency is expensive — the difference between calling the bank in the first hour and calling it the next morning can be the difference between recovering funds and writing them off. A written plan doesn't need to be long. It needs to answer, in advance: who has the authority to disable an account without a meeting first, who calls the bank, who talks to the client or vendor whose invoice got spoofed, and where the pre-incident audit logging settings live so nobody's guessing whether mailbox auditing was actually turned on.

That last point is easy to overlook and expensive to discover during an incident. Both platforms need auditing enabled before something happens — Microsoft's playbook lists mailbox auditing and unified audit log access as baseline prerequisites to confirm during planning, not during response.[4] If auditing was off, the investigation has a hole in it that can't be retroactively filled.

Defensive measures worth the friction

None of this is exotic. It's the same handful of controls that show up across FBI IC3 guidance going back a decade,[7] and they hold up because BEC hasn't fundamentally changed its mechanics — it's still built on trust and timing, not malware.

The out-of-band verification step is the one organizations most often skip, probably because it's a process change rather than a product purchase. It's also the control that stops a BEC attempt even when the technical defenses have already failed — if someone in accounts payable picks up the phone and confirms a "new" bank account with the vendor directly, the fraud attempt dies right there regardless of how convincing the email looked.

Security takeaway

BEC doesn't get the same headline treatment as a critical RCE, and that's part of why it's still so effective — it doesn't need a zero-day. It needs one convincing email and one busy person moving fast. The response that actually limits damage isn't a single tool; it's a sequence that runs the account lockdown and the financial fraud response in parallel, backed by logging that was already turned on before anyone needed it.

Sources & References

1. [1] FBI Internet Crime Complaint Center — "Business Email Compromise: The $55 Billion Scam" (PSA I-091124-PSA) — September 2024 — View source
2. [2] Nacha, summarizing the FBI IC3 2024 Internet Crime Report — "FBI's IC3 Finds Almost $8.5 Billion Lost to Business Email Compromise in Last Three Years" — April 24, 2025 — View source
3. [3] Google Workspace Admin Help — "Identify and secure compromised accounts" — View source
4. [4] Microsoft Learn — "Phishing investigation playbook," Security Operations discipline — updated 2026 — View source
5. [5] Schneider Downs, citing FBI Cyber Division testimony to the House Judiciary Committee — commentary on the Financial Fraud Kill Chain and Recovery Asset Team — View source
6. [6] Stampli — "Payment Fraud: The First 24 Hours" — overview of bank recall and IC3 reporting timing — View source
7. [7] FBI Internet Crime Complaint Center — "Business E-mail Compromise" (PSA I-012215-PSA) — January 22, 2015 — View source

Disclaimer: This article is general security guidance, not legal or financial advice. Wire-fraud recovery outcomes depend on jurisdiction, bank policy, and timing that vary case by case.