Detecting Business Email Compromise in Microsoft 365 Audit Logs

Why this matters

Business email compromise doesn’t need malware, doesn’t need an exploit, and routinely costs organizations more than ransomware. Once an attacker has a working session in a mailbox, the entire attack — financial fraud, data theft, or further phishing — happens through completely legitimate Microsoft 365 operations: reading mail, creating a forwarding rule, sending a wire transfer request that looks exactly like the real thing.

Indicators to look for in the M365 Unified Audit Log

• Operation: New-InboxRule or Set-InboxRule creating rules that forward, delete, or move mail matching financial or executive-related keywords
• Operation: Set-Mailbox enabling external forwarding on an account that never had it before
• A burst of MailItemsAccessed or Send operations inconsistent with the user’s normal mailbox activity volume or timing
• Sign-in immediately preceding the rule change from a Workload and location inconsistent with the user’s history
• Rule names or conditions deliberately designed to be inconspicuous (single characters, rules that target only specific senders like finance or HR contacts)

How LogTriage detects this

The M365 parser extracts Workload, Operation, and UserId from every audit record, which lets the same session and risk-scoring pipeline used across every other format flag the specific operation sequence — sign-in, then mailbox rule change, then mail access — that distinguishes routine mailbox administration from an active BEC session.

Detection / evidence checklist

• Pull every inbox rule created or modified for the affected account in the suspicious window
• Check whether external forwarding was enabled, and to which external address
• Review MailItemsAccessed events to scope exactly which messages were read, not just that access occurred
• Remove the malicious rule, disable forwarding, and force a credential and session reset
• Notify any party who may have received a fraudulent message sent from the compromised account before remediation