Incident response · 12 Oct 2026

Business Email Compromised? Recovery Steps

Business email compromise is the costliest cybercrime type in the FBI's IC3 reports, year after year. If a mailbox in your company is in someone else's hands, work this list top to bottom - fast, because they are reading everything you write while you fix it.

Contain in the first 30 minutes

Everything in this section happens before you investigate anything. Speed matters more than elegance - the attacker is inside the mailbox right now, reading whatever arrives while you work.

Sign out all sessions. A password change alone does not always kill sessions that are already open. In Microsoft 365, a global admin revokes them from Entra ID (Azure Active Directory): find the user, review sign-ins, and revoke sessions - this kills every refresh token the attacker holds. In Google Workspace, a super admin opens the user in the Admin console and signs them out of all sessions. Do not skip this step even if you plan to change the password in the same minute.

Reset the password from a clean device. Not the user's laptop. You don't yet know how the attacker got in, and if that machine is compromised, the new password goes straight back to them. Use a different machine, ideally one that has never been logged into the affected account, and generate a long, random, unique password.

Turn on 2FA if it's missing. If the account has no second factor, enable it now. If MFA already exists, check which methods are registered and remove any you don't recognize - an attacker who added their own phone number stays in even after your password reset.

Assume they set traps before you locked them out

Attackers rarely sit passively in a mailbox. Before you evicted them, they had time to make sure they could get back in - or keep receiving a copy of everything. Check every item below, on every compromised account.

  • Inbox forwarding rules. In Microsoft 365, check both places: inbox rules on the mailbox itself and mail flow rules (transport rules) at the tenant level, because attackers with enough access hide forwarding at the transport layer where users never see it. Forwarding to an external address you don't recognize is the classic BEC persistence move.
  • Delegated access. Look for full-access or send-as / send-on-behalf permissions granted to external addresses. Attackers add a delegate so they can keep reading mail without ever touching the account again.
  • OAuth app consents. This is the dangerous one. A malicious app consent survives a password reset completely - the app holds its own tokens and keeps pulling mail through the API. Review enterprise applications and user consents for anything approved recently that you don't recognize, and revoke it.
  • Recovery email and phone. If the attacker changed the recovery details, your next password reset hands the account back to them. Verify both.
  • Auto-replies. A quiet auto-reply can be used to redirect conversations or reassure senders while fraud is in flight. Remove anything that isn't yours.

Audit what they touched

Containment buys you the breathing room to answer the question your management, your insurer, and possibly a regulator will all ask: what did they see and do?

In Microsoft 365, the Unified Audit Log is your source of truth - search it for the affected account across the incident window: messages sent, items accessed, permissions changed, rules created. In Google Workspace, use the investigation tool in the Admin console, which lets you pivot by user across Gmail events, login history, and Drive activity.

Work this checklist:

  • Sent items. What was sent from the mailbox, to whom, and what did it say? Export the list before anyone starts deleting.
  • Login history. Where did they sign in from, and when? Look for countries and times that make no sense for the user, plus impossible-travel login pairs.
  • File access. If the account touches Drive, SharePoint, or OneDrive, check which files were opened or downloaded. A compromised mailbox attached to a file store often turns into a data breach.
  • Teams and Chat messages. In Microsoft 365, check whether they read or sent Teams messages. Attackers use chat to pivot to colleagues with more credibility than email - a short "can you approve this payment?" from a real account bypasses a lot of suspicion.

Protect the money

Business email compromise is invoice fraud. The mailbox is not the target - the payment run is. While you clean up, someone in finance may be about to act on an email the attacker sent days ago.

  • Warn finance and AP immediately. One phone call, right now: any email requesting a bank-detail change, a new vendor, a new beneficiary, or an urgent payment is treated as hostile until verified - even if it appears to come from the CEO or a long-standing supplier.
  • Verify bank-detail changes by phone, using a number you already had on file. Never the number in the email. This single habit would stop most BEC losses.
  • Put a verbal callback policy in place today: any change to payment details, any new account, any urgent wire requires a voice call to a known contact. No exceptions - not for the CFO, not for the biggest client.
  • Check for pending wires. Ask the bank what outbound payments are queued and freeze anything that traces back to an email request.

Protect everyone else

If the attacker used the mailbox to send phishing or fraud, your problem now includes everyone in the sent-items list.

Notify the contacts from a different channel - call or message them from a clean account. Tell them plainly: this mailbox was compromised, disregard any requests or links sent from it in this window, and verify anything financial by phone. Most will appreciate the heads-up; the ones mid-transfer will thank you for it.

Remove the malicious sent mail where your platform allows it. In Microsoft 365 you can search and purge messages across mailboxes with an eDiscovery content search; in Google Workspace, the investigation tool can remove matching messages. Do this only after you've preserved the evidence - export first, purge second.

Credentials and beyond

People reuse passwords. Attackers count on it.

The moment a work password is known to an attacker, assume it's being tried against personal email, banking, social media, and every SaaS tool the company uses. If the same password - or a small variation of it - exists anywhere else, change it there too, from a clean device, everywhere it appears.

Then check whether the credentials were already out there before this incident. Two free tools on this site do exactly that: the password breach check tests a password against known breach corpora, and the email breach check shows which dumps your address appears in. The result also tells you how they may have gotten in - and which other accounts to fix first.

How they got in

You need an entry hypothesis before you can say the door is closed. In real BEC cases it is almost always one of these:

  • A phishing page. A lookalike login portal - often after a thread hijack, where a real contact's compromised mailbox replies to an existing conversation with a "review this document" link. The user types the password; the attacker types it back.
  • A reused password from an older breach. See the checks in the previous section.
  • MFA fatigue. The attacker triggers push after push until the user, annoyed, taps Approve. Known as prompt bombing.
  • Session token theft. AiTM phishing kits (Evilginx-style) proxy the real Microsoft or Google login page and catch the session cookie after a successful MFA login. The attacker replays the cookie and walks straight in - MFA was satisfied, so nothing looks wrong.
  • Brute-forced legacy authentication. Old protocols like IMAP, POP, and SMTP basic auth have no MFA support at all. If they're enabled, the attacker just tries passwords until one works.

Whatever the answer, two fixes close the two most common doors: enforce MFA with number matching instead of plain Approve, and disable legacy authentication protocols tenant-wide. Both are free and take an afternoon.

Report

Two reports matter, and both are time-sensitive.

The bank recall. If any money moved, call the bank the same hour and request a wire recall. Speed decides recovery: within hours, funds are often still at the receiving bank and can be frozen; within days, they've usually hopped jurisdictions. Follow the call in writing.

The crime report. File with the FBI's IC3 - it's the standard intake point for BEC and feeds the recovery pipeline that gets seized money back. Keep the report number; your bank, insurer, and lawyer will all want it. The full walkthrough - what to include, who to tell, what happens after filing - is in the guide on how to report a cybercrime.

If it's bigger than one mailbox

If the signs point beyond a single account - admin logins you don't recognize, other mailboxes sending strange mail, encrypted files - stop following this list and treat it as a full incident. Start with the broader rundown of what to do when you've been hacked, and if you'd rather have an experienced hand on the call while you work through containment, audit, and hardening, get in touch - emergency response is part of the job.

BEC FAQ

Use your admin account, not the user's. In Microsoft 365, a global admin can reset the password and revoke sessions from Entra ID regardless of what the attacker changed; in Google Workspace, a super admin does the same from the Admin console. Do it from a clean device. Then immediately review the account's recovery email, recovery phone, and registered MFA methods, and remove anything you don't recognize - otherwise the attacker takes the account back the moment you finish.

No. A password reset alone doesn't kill every active session, and it does nothing about what they left behind. OAuth app consents survive a password reset entirely - a maliciously consented app keeps its own tokens and keeps reading mail through the API. Inbox forwarding rules, mailbox delegates, and changed recovery details persist too. That's why the recovery steps cover session revocation, rule and consent review, and recovery checks - not just a new password.

If the attacker sent mail from your domain, yes - and quickly. Notify them from a different channel, tell them the mailbox was compromised, and ask them to disregard any requests or links sent from it during the incident window, especially anything about payment details. Partners remember who warned them. Silence only protects the attacker's window.

Sometimes - if you move within hours. Call your bank immediately and request a wire recall, and ask what outbound payments are queued so anything suspicious can be frozen. File with the FBI's IC3 the same day, because that report feeds the recovery pipeline that returns seized funds. Every hour of delay lets the money hop further, so recall first, document second.

Three main ways. MFA fatigue: they trigger push notification after push notification until the user approves one just to make it stop. AiTM phishing kits: the fake login page relays the real one, so MFA succeeds normally and the attacker catches the session cookie instead - after that they never need your password or MFA again. And SIM swapping: they port the phone number to intercept SMS codes. Number-matching prompts and passkeys close these gaps; SMS codes don't.

Mailbox compromised and need it handled today?

Containment, audit and hardening - done with you, not just for you.

Contact