BEC Example: A Fictional Microsoft 365 Incident Walkthrough
A fictional AiTM business email compromise rebuilt from its Microsoft 365 logs: spray, token replay, inbox rules, forwarding, OAuth consent, fake invoice.
Fictional scenario. Everything in this article is invented: the company Meridian Freight (meridianfreight.example), its people, the IP addresses (RFC 5737 documentation ranges), the sessions and the e-mails. Only the log formats are real. It is the Try a sample dataset of M365 Forensics, so you can open it and follow along.
TL;DR. A password spray from a VPS fails. The next morning an accounts-payable clerk signs in through an AiTM phishing proxy; seven minutes later her session is replayed from another country. In 90 minutes the attacker registers an Authenticator app, creates two inbox rules named "." and "..", sets mailbox forwarding outside, syncs about 450 messages, searches for "facture virement IBAN", consents to a mail app, downloads 64 invoices and sends a fake bank-details e-mail, then deletes it. The tool returns Compromised with 18 findings, three of them critical. Below is how each step appears in the logs, and where the findings need a human eye.
The inputs
Four files, in the formats the real exports use:
| File | Source | Records |
|---|---|---|
AuditLog_2026-09-16.csv | Purview Unified Audit Log | 279 |
InteractiveSignIns_2026-09-14_2026-09-16.csv | Entra interactive sign-ins (portal CSV) | 26 |
NonInteractiveSignIns_2026-09-14_2026-09-16.json | Entra non-interactive sign-ins (portal JSON) | 54 |
AuditLogs_2026-09-16.csv | Entra audit logs (portal CSV) | 7 |
Coverage: 366 events from 2026-09-14 07:02 to 2026-09-15 16:33 UTC, with MailItemsAccessed present. The dataset also contains normal activity for eight users (office sign-ins, mail reads, file access, one legitimate inbox rule), so the attack has to be found, not just read.
The timeline (UTC)
| Time | What happened | Log evidence | Finding(s) |
|---|---|---|---|
| 09-14 22:10–22:17 | Password spray against 8 accounts, all failing | 8 sign-ins from 203.0.113.140 (US, AS20473), error 50126 | Password spraying from one IP (medium) |
| 09-15 07:44 | Claire Dubois (accounts payable) signs in from the Lyon office | Interactive sign-in, 192.0.2.10 (FR) | none (baseline) |
| 08:12:40 | Claire signs in again, through the AiTM proxy; MFA satisfied | Interactive sign-in from 198.51.100.23 (NL, AS14061 hosting), session 7f3c9a2e… | Hosting / VPN network (high) |
| 08:19:30 | The same session is used from the US | UserLoggedIn and non-interactive sign-ins from 203.0.113.77 (US, AS16509), same Session ID | One session from several places (high); impossible travel (high) |
| 08:24:51 | A new authenticator is registered | Entra audit User registered security info, then Update user | New MFA method (medium) ×2 |
| 08:31:12 | Inbox rule "." : subject/body contains invoice; payment; facture; virement; RIB; IBAN → move to RSS Feeds, mark read | New-InboxRule from 203.0.113.77, AADSessionId = the replayed session | Hides mail (high), payment keywords (high), meaningless name (medium) |
| 08:33:48 | Inbox rule ".." : from the supplier compta@transports-alpes.example → forward to billing-desk@secure-mailbox.example, delete | New-InboxRule | Forwards outside (critical), hides mail (high), meaningless name (medium) |
| 08:36:05 | Mailbox forwarding to the same outside address, keeping a copy | Set-Mailbox ForwardingSmtpAddress, DeliverToMailboxAndForward = True | External mailbox forwarding (critical) |
| 08:40–09:04 | About 450 messages synced / read over REST | 25 MailItemsAccessed records, OperationCount 14–22 each, from the US IP | Unusual volume of mailbox items (high) |
| 08:52:30 | Mailbox search "facture virement IBAN" | SearchQueryInitiatedExchange | Searched for payment keywords (medium) |
| 09:02:10–14 | Consent to "Mail Sync Pro": Mail.ReadWrite Mail.Send offline_access User.Read | Add service principal, Add delegated permission grant, Consent to application. | Consent with mailbox access (high); new service principal (low) |
| 09:15–09:32 | 64 invoices downloaded from the Finance SharePoint site, user agent rclone | FileDownloaded ×64 | Mass download (high) |
| 09:41:09 | E-mail "Changement de coordonnées bancaires – facture 2026-0915" sent to a customer | Send from the replayed session | covered by the attacker-session finding |
| 09:42:30 | The sent e-mail is deleted from Sent Items | SoftDelete | covered by the attacker-session finding |
| 13:58 | Claire back at the office, unaware | Interactive sign-in from 192.0.2.10, new session | none |
The critical correlation finding, "Actions performed from the attacker's session or IP", groups 103 events: everything from the two attacker IPs or the replayed session, including the inbox rules, forwarding, MFA registration, consent, reads, downloads, the send and the deletion. That single finding is the answer to "was it her or them?".
Why the verdict is "Compromised"
The rule is: any critical finding, or two different high findings on one account. Here there are three critical findings (external inbox-rule forwarding, external mailbox forwarding, attacker session) and eight high ones on Claire's account. The Why list under the verdict links to them.
Where the analyst still has to think
A real report does not paste the findings. Three examples from this dataset:
- Impossible travel mixes legitimate and malicious sign-ins. Its evidence lists hops "FR → NL · 694 km in 29 min" and "NL → US · 6245 km in 7 min". The first hop starts from Claire's genuine office sign-in; the attacker is on the NL and US sides. The finding points to the right account but the evidence must be split by hand. The session finding is the precise one.
- Threshold findings include the user's own activity. The mailbox-volume and mass-download findings list every event in their one-hour window, including Claire's Outlook reads and a file she opened from the office (
192.0.2.10). The attacker's share is the part from203.0.113.77with the REST client and thercloneuser agent. - One medium finding is a false positive. On 09-14 at 09:05, Sofia Garcia registered security info from the office IP. It is flagged as a new MFA method (medium) like the attacker's registration. Nothing else links it to the attack: a quick check with Sofia closes it.
Conversely, Thomas Becker's rule "Newsletters" (from a newsletter sender to a Newsletters folder, created from the office) produces no finding at all.
Scoping
- Read: the
MailItemsAccessedrecords from the attacker's IP use the REST client and carry the replayed session. The list ofInternetMessageIdvalues gives the messages to review (what MailItemsAccessed proves). - Forwarded: anything from the supplier after 08:33 (rule "..") and every incoming message after 08:36 (mailbox forwarding), until removal.
- Downloaded: 64 files from
sites/Finance/Shared Documents/Factures 2026. - Sent: at least one fraudulent e-mail to a customer; message trace would show the recipients.
- Persistence to remove: the Authenticator registered at 08:24, the "." and ".." rules, mailbox forwarding, the "Mail Sync Pro" grant and service principal, and the session itself.
The remediation list
The tool orders the steps from the findings: revoke sessions, reset credentials and re-register MFA, assess data exposure, remove the inbox rules, remove forwarding and block external auto-forwarding, block the attacker's IPs, move to phishing-resistant MFA, warn contacts, check payments, remove the consented app and restrict user consent, review MFA methods and app registrations. The first hour after a BEC explains why that order.
What this sample does not show
Real incidents are messier: exports truncated at 50,000 rows, sign-ins already expired, attackers on residential proxies instead of hosting networks, several victims. The limits are listed in retention and missing logs. The method stays the one described in the investigation guide: find the attacker's sign-in, follow the session, check every persistence mechanism.