BEC Response: What to Do in the First Hour (Microsoft 365)
The first hour after a Microsoft 365 business email compromise: stop the money, keep the logs, revoke sessions and remove persistence, in the right order.
TL;DR. In the first hour: (1) if a payment is involved, call the bank and freeze pending transfers; (2) start the log exports (UAL, Entra interactive and non-interactive sign-ins, Entra audit) before anything expires; (3) block the account or reset its password from a clean device and revoke sessions; (4) record, then remove, inbox rules, forwarding, unknown MFA methods and app consents; (5) warn the people the mailbox wrote to. A password reset alone leaves stolen sessions, rules, forwarding, consents and attacker MFA methods in place.
The first hour is where most of the avoidable damage happens: a second payment goes out, the attacker notices and deletes their traces, or someone "cleans up" the mailbox and destroys the only record of what was forwarded. The order below balances stopping harm with keeping evidence.
0–10 minutes: money first
If the BEC involves a payment (changed bank details, an "urgent" transfer), the recovery window is short.
- Ask finance to stop pending transfers and treat every bank-detail change received since the first suspicious event as unverified.
- Call your bank and ask for a recall of any transfer already made.
- In the United States, file a complaint with the FBI's IC3: its Recovery Asset Team works with financial institutions to freeze fraudulent transfers through the Financial Fraud Kill Chain, most of which are BEC cases (2024 IC3 report). Elsewhere, report to the police and your national cybercrime reporting service.
- Verify any bank-detail change by phone, using a number you already had, never one from the e-mail.
10–20 minutes: preserve the evidence
Start exports now; they take time and retention is short (7 days for Entra sign-ins on free tenants).
- Purview audit search for the whole tenant, 30+ days back.
- Entra interactive and non-interactive sign-ins, Entra audit logs.
- Current state:
Get-InboxRule -Mailbox <user> -IncludeHidden | Format-List *andGet-Mailbox <user> | Format-List Forwarding*,DeliverTo*saved to files.
Details in how to export the logs. Hash the files. Do the analysis afterwards, on copies.
20–40 minutes: cut the attacker's access
In this order, following Microsoft's compromised account response:
| # | Action | How | Why |
|---|---|---|---|
| 1 | Disable the account (preferred) or reset the password | Entra admin center → user → Account enabled off; or reset from a clean device, never sending the new password by e-mail | Blocks new sign-ins |
| 2 | Revoke sessions | Entra admin center → user → Revoke sessions, or Revoke-MgUserSignInSession -UserId <UPN> | Invalidates refresh tokens; a reset alone does not kill a stolen session |
| 3 | Review MFA methods | Entra → user → Authentication methods; remove any the user did not register | Attackers add their own Authenticator or phone |
| 4 | Review app consents | Entra → user → Applications; remove unknown apps | Consented apps keep their own tokens |
| 5 | Review admin roles | Entra role assignments | In case the account was privileged or escalated |
| 6 | Remove forwarding | Set-Mailbox <user> -ForwardingSmtpAddress $null -ForwardingAddress $null | Stops mail leaving |
| 7 | Remove malicious rules | Remove-InboxRule after recording them | Stops hiding / forwarding |
Two notes. Access tokens already issued can remain valid until they expire (one hour by default) unless the application supports Continuous Access Evaluation (Microsoft Learn). And for accounts synchronised from on-premises Active Directory, Microsoft recommends resetting the password in AD, twice.
If the attacker's IPs are known, add them to a blocked named location in Conditional Access and check whether they touched other accounts.
40–60 minutes: warn and scope
- Warn contacts. The attacker writes from the real mailbox. Tell the customers and suppliers the account corresponded with (the Sent Items and the attacker's
Sendrecords tell you who) that any bank-detail change must be confirmed by phone. - Check the hiding folders (RSS Feeds, Archive, Conversation History, Notes, Deleted Items) for the replies the attacker hid, and recover deleted items from Recoverable Items to see what was sent and removed.
- Check the tenant for siblings: other users signed in from the same IPs, the same app consented elsewhere, the same rule names. BEC campaigns send their next phishing from the compromised mailbox to its contacts.
- Start the timeline from the exports: M365 Forensics produces the verdict, findings and a remediation list ordered by urgency from the logs, without uploading them. The investigation guide covers the full method.
Common mistakes
| Mistake | Consequence |
|---|---|
| Resetting the password and stopping there | Session, rules, forwarding, consents, attacker MFA stay active |
| Deleting rules before recording them | You no longer know what was forwarded or hidden |
| Exporting only the victim's interactive sign-ins | Replay and spray are invisible |
| Sending the new password to the user's mailbox | The attacker may still read it |
| Waiting for "the full picture" before containment | A second payment goes out |
| Telling the attacker (replying from the mailbox) | They accelerate or clean up |
After the first hour
- Finish the investigation: what was read (MailItemsAccessed), what was sent, who else was targeted.
- Assess notification duties if personal data was exposed (for example under the GDPR's 72-hour rule).
- Harden: phishing-resistant MFA, block legacy authentication and device code flow where not needed, set external auto-forwarding to Off in the outbound spam policy, restrict user consent, route Entra logs to long-term storage.
Microsoft's incident response playbooks go further for phishing, password spray and app consent grant.
Frequently asked questions
What should I do first after a business email compromise?
If money may be moving, call the bank and ask finance to freeze pending payments. In parallel, export the audit and sign-in logs, then revoke the account's sessions, remove attacker persistence (rules, forwarding, MFA methods, app consents) and reset the password.
Should I delete the malicious inbox rule immediately?
Record it first: export the rule details and its audit record. Then remove it. Deleting first loses the parameters you need to know what was forwarded or hidden.
Is disabling the account better than resetting the password?
Microsoft recommends disabling the account during the investigation where possible, together with revoking sessions. If the account cannot be disabled, reset the password and revoke sessions.
Further reading
- Microsoft Learn: Revoke user access in an emergency
- Malicious inbox rules and forwarding
- Glossary: business email compromise, token replay