Investigating Microsoft 365 BEC: OAuth grants, mailbox rules, and the BEC kill chain

Modern Business Email Compromise (BEC) doesn't look like the 2017 playbook anymore. The attacker isn't just phishing a password and logging in from a suspicious IP. They're consenting their malicious OAuth app into the tenant, adding forwarding rules to a partner-domain mailbox, sitting on an inbox for weeks to learn invoice cadence, then changing wire details on a single email at the right moment. By the time the finance team notices, the attacker is gone, the consent grant is still active, and the audit trail is fragmentary.

This guide walks the full BEC investigation: from the moment a user reports a suspicious email to the moment you produce a defensible report that answers how did they get in, what did they read, what did they take, and who else is exposed? It assumes a Microsoft 365 tenant and is anchored to MITRE ATT&CK techniques where relevant.

The BEC kill chain in 2026

The modern pattern is roughly seven steps:

1. Initial access — AiTM phishing (Evilginx / Tycoon / EvilProxy) intercepts session tokens, bypassing MFA without alerting the user (T1566.002 + T1539).
2. Persistence — Attacker grants consent to a malicious OAuth app with Mail.ReadWrite and Mail.Send, often disguised with a legitimate-looking display name (T1098.003).
3. Reconnaissance — OAuth-driven IMAP/Graph access reads months of mail history. No interactive sign-in, no MFA, no Conditional Access enforcement on the app (T1114).
4. Defence evasion — Inbox rules forward responses to attacker-controlled folders or external addresses and auto-delete bounce-backs (T1564.008).
5. Collection — Long dwell on the inbox to learn invoice patterns, signatures, and approval flows.
6. Impact — A single email is reply-spoofed with changed wire details. Funds move. The malicious mailbox rule deletes the bounce or any reply that would expose it (T1565.001).
7. Lateral move — The compromised mailbox is used to phish the next victim from a trusted internal sender (T1534).

The investigation has to cover all seven, and crucially the order in which they happened. Out-of-order timelines lose cases.

Step 1: Triage in the first 30 minutes

Before you touch anything that mutates state (password reset, session revoke, consent revoke), get answers to:

• Confirmed or suspected? A reported suspicious email is not confirmed access. Look for at least one of: anomalous sign-in, anomalous OAuth consent in the last 30 days, anomalous inbox rule, or anomalous mail-forwarding configuration.
• Who else is in the blast radius? If the compromised user has delegated mailbox access, send-as permissions, or shared inbox membership, everyone they could send-as is potentially affected.
• What evidence retention do you have? Default sign-in log retention is 30 days. Default audit log retention is 90 days (180 with Purview Audit Standard, longer with Premium). Pull what you have now — this is the single biggest IR mistake we see.

Step 2: Pull the evidence (before containment)

Four data sources cover most BEC investigations. Pull them all into static evidence before changing state:

• Sign-in logs — Entra ID Monitoring & health > Sign-in logs. Filter the affected UPN, 30 days back. Export to JSON.
• Unified audit log — Purview Audit with the UPN as User and operation types MailItemsAccessed, Set-InboxRule, New-InboxRule, Set-Mailbox,Add-MailboxPermission, Set-MailboxAutoReplyConfiguration.
• OAuth consent events — Entra Audit logs filtered to operation Consent to application and Add app role assignment grant to user. Pivot by the user and by the attacker-introduced enterprise app.
• Mailbox rules — Get-InboxRule -Mailbox <upn> | Format-List in Exchange Online PowerShell. Run this before you change the password. Some attackers create rules that delete themselves on condition; you want them captured live.

Step 3: Identify the malicious OAuth app

In modern BEC, the OAuth consent is the persistence mechanism. Even after password reset and session revocation, the app token keeps reading mail until you revoke the consent specifically.

What to look for in the consent log:

• New enterprise apps registered or consented in the last 30 days with Mail.*, MailboxSettings.*, offline_access, or full_access_as_app scopes.
• Apps with a publisher domain that doesn't match the display name (“Microsoft 365 Backup” published from a Gmail address).
• Apps consented via user consent rather than admin consent — especially dangerous if your tenant still allows user-consent to non-verified publishers.
• Multi-tenant apps owned by a tenant ID you don't recognise. Cross-reference to the published lists of known-malicious OAuth app IDs from CISA and Mandiant advisories.

Step 4: Reconstruct the timeline

You now have sign-in events, audit events, consent events, and mailbox rules. The goal is a single chronological narrative. The order matters because it tells you the actual entry point.

The questions a defensible timeline must answer:

1. When was the first anomalous successful sign-in? Where from? Which client (browser UA / device ID / app)?
2. When was the first OAuth consent? Who consented (the user themselves, or an admin acting on user behalf)?
3. When was the first inbox rule created? What does it do? Forward to where?
4. What mail items were accessed and when? MailItemsAccessed is the only operation that tells you “the attacker read this specific email”. Without Advanced Audit / E5 you cannot answer this.
5. What outbound mail was sent from the compromised mailbox? Tracking IDs of message sends correlate to recipients downstream.

Step 5: Containment in the right order

Containment for BEC has a specific order. Doing it out of order leaves the attacker access:

1. Revoke OAuth consent for the malicious app — this is the one most teams miss. Password reset alone doesn't affect app-issued tokens.Remove-AzureADUserAppRoleAssignment or Graph DELETE /oauth2PermissionGrants/{id}.
2. Revoke active sessions — Revoke-AzureADUserAllRefreshTokenforces the user (and any session-token-replay attacker) to reauthenticate.
3. Reset password — only meaningful after sessions are revoked; otherwise active refresh tokens stay valid.
4. Delete malicious inbox rules — Remove-InboxRule. Keep a copy of the rule definition first.
5. Disable the malicious enterprise app — not just revoke; set accountEnabled to false on the service principal so re-consent attempts fail.
6. Block legacy authentication tenant-wide if you haven't already.
7. Force re-enrolment of MFA if there's any chance the attacker registered their own authenticator device.

Step 6: Notify the downstream blast radius

BEC investigations don't end with the source mailbox. The attacker has been sending mail from a trusted internal sender for as long as they've had access. Every external recipient of mail from the compromised user during the dwell window is a potential downstream victim.

Pull the outbound mail trace for the compromised mailbox across the access window. Categorise external recipients by relationship type (vendor, customer, partner, regulator). The vendor recipients with active invoice cycles are the highest-risk downstream targets. They need a direct phone call — not an email — warning them not to act on changed payment details until your IR concludes.

Step 7: The report

A defensible BEC report has six sections:

1. Executive summary — one paragraph: who was compromised, how, when discovered, was data taken, has it been contained.
2. Timeline — one row per significant event, anchored to UTC. Every row references the source artefact (audit log row ID, sign-in event ID).
3. Evidence inventory — what artefacts were collected, when, by whom, with what hash. The chain of custody.
4. Affected entities — the user, the enterprise app, any delegated-permission users, any downstream recipients with elevated risk.
5. Containment actions — what was done, when, by whom, with what outcome.
6. Lessons learned and hardening recommendations — the forward-looking section the board reads.

Hardening: making BEC harder for the next attacker

• Restrict user consent to verified publishers only. Block consent for high-risk scopes (Mail.*, full_access_as_app) without admin approval.
• Block legacy authentication at the Conditional Access layer.
• Require phishing-resistant MFA (FIDO2, certificate-based) for privileged roles. Push-based MFA is bypassable by AiTM proxies.
• Enable Advanced Audit / Purview Premium so MailItemsAccessed is logged. Without it you cannot disprove data access.
• Conditional Access for OAuth apps — require app-level CA policies for high-risk scopes.
• Out-of-band wire-change verification — the single highest-ROI process control. Phone call to a known good number for every wire detail change.

Doing this with tooling

Everything above can be done manually in Entra, Purview, and Exchange Online PowerShell. For a single mailbox, that's a long day. For a multi-account BEC that pivoted through three users and an OAuth app, manual correlation is the bottleneck.

CICADA IR pulls sign-in logs, audit logs, mailbox events, OAuth consent events, and endpoint telemetry into one investigation workspace, builds the entity graph and timeline automatically, and generates the BEC report with chain-of-custody intact. The DEMO M365 BEC investigation that ships with every appliance walks through this exact scenario end-to-end. See Getting Started or the companion Entra ID compromise workflow for the upstream identity-side investigation.