Business Email Compromise in Microsoft 365: The First 24 Hours

Start with the answer: in the first 24 hours of a Microsoft 365 business email compromise, you do five things in order. Contain the account, kill every session and token, remove what the attacker planted, work out what they saw and sent, and notify the people who need to know. A password reset alone does none of that after the first step, because the attacker often holds more than the password.

Hour 0 to 2: contain the account

Block sign-in for the affected user, or at minimum reset the password and require multifactor authentication re-registration. Then revoke all sessions and refresh tokens for the user. This matters because a stolen session token or refresh token can keep working after a password change. Microsoft's guidance for compromised accounts treats session revocation as part of containment, not an extra.

If the attack began with a phishing message, find every other recipient of the same message. Microsoft's phishing incident response playbook walks through identifying who received it, who clicked and who entered credentials. Treat each of those people as a possible second victim until the logs say otherwise.

Hour 2 to 6: remove what the attacker planted

Attackers rarely just read mail. They plant persistence so that the access survives cleanup. Check these on every affected mailbox.

• Inbox rules. Look for rules that move messages to obscure folders such as RSS Subscriptions or Archive, mark mail as read, delete it, or forward it outside the company. These rules hide replies from the real owner while a fraudulent thread continues.
• Forwarding. Check mailbox forwarding addresses, forwarding set through rules, and delegate or full-access permissions that were added.
• Connected devices and authentication methods. A new phone number or authenticator registered by the attacker lets them back in after you reset the password.
• Application consent. Review the enterprise applications the user has consented to, and the permissions each holds.

Application consent deserves its own attention. In an OAuth consent attack, the user clicks Accept on a malicious application and grants it permission to read mail or files. The application then acts with a token of its own. Changing the password does nothing to it. Microsoft's playbook for compromised and malicious applications describes how to find the application, review its permissions and sign-in activity, and disable or delete it, then revoke the grants. Where policy allows, restrict user consent so that new applications need administrator approval.

Token theft and why multifactor authentication did not stop it

Many compromises now involve adversary-in-the-middle phishing. The victim signs in on a lookalike page that relays the real sign-in, including the multifactor prompt, and the attacker captures the resulting session token. The attacker then replays that token. This is why revocation is essential, and why the longer-term fix is to move to phishing-resistant sign-in methods and to use Conditional Access features that bind tokens to the device they were issued to. Microsoft documents token protection in Conditional Access for this purpose. Our article on multifactor authentication and passkeys covers the sign-in side.

Hour 6 to 12: preserve evidence and scope the damage

Before you delete anything, export the rule definitions and record what you found. Then pull the sign-in logs and the unified audit log for the affected users. You are trying to answer a short list of questions.

• When did the first suspicious sign-in happen, and from where?
• Which messages were read, searched, forwarded, sent or deleted?
• Which other accounts did the same address or application touch?
• Did the attacker send mail from the account to customers, vendors or staff?

Audit retention and licensing vary, so check early what your tenant actually kept. If the logs are thin, say so in your notes rather than guessing. The scope you can prove is the scope you report.

Hour 12 to 24: money, people and records

If a payment instruction was changed or a wire was sent, call the sending bank right away and ask for a recall, then file a report with the FBI Internet Crime Complaint Center. Speed matters more than paperwork at this stage. Tell the counterparties who received messages from the account, using a phone number you already know rather than one from the email thread.

Then work out your notification duties. Depending on your industry and the data in the mailboxes, state breach notification laws, contracts or sector rules may apply. A mailbox with client records, health information or financial account details is not the same as one with routine correspondence. Ask your counsel early, and keep a written timeline from the first alert.

What to fix in the following week

• Disable external auto-forwarding by policy, and alert on new inbox rules that forward or delete.
• Require phishing-resistant sign-in for administrators and finance staff first.
• Limit user consent to applications and review existing consents on a schedule.
• Set a payment-change procedure that requires a callback to a known number, so a perfect email is never enough to move money.
• Rehearse this plan once, with the logs you actually have.

Our cybersecurity team runs this response and the hardening that follows under written authorization and scope you approve. If you want a review of your Microsoft 365 tenant before an incident, start with our Cybersecurity service.

Sources

• Incident response playbook: Phishing (Microsoft Learn)
• Incident response playbook: Compromised and malicious applications (Microsoft Learn)
• Incident response playbook: Password spray (Microsoft Learn)
• Responding to a compromised email account in Microsoft Defender for Office 365 (Microsoft Learn)
• Token protection in Microsoft Entra Conditional Access (Microsoft Learn)
• Outbound spam policies and external email forwarding (Microsoft Learn)

This article is general information, not legal advice. Your obligations and the right steps depend on your systems, contracts and the laws that apply to you. Last reviewed November 9, 2026.

Keep reading

Next · SecuritySecrets in Git History: Find, Revoke, RotateA secret committed to git is compromised the moment it is pushed, even if you delete it a minute later. The fix is to revoke and rotate the credential first, then clean up. Here is how to find them and stop new ones.7 min read

• What a Code and Endpoint Security Review Finds in the First 24 Hours7 min
• Before Anyone Scans Your Website: Verification and Written Authorization7 min