Anatomy of an AiTM Attack — How a Phishing Email Became a $47,250 BEC in 110 Minutes
Earlier this year, I led the investigation and response to a sustained adversary-in-the-middle (AiTM) credential phishing campaign. Five attack waves. Zero successful credential replays after detection. Full containment. Formal CISO-facing report delivered.
This post walks through a sanitized version of one attack wave — from the initial phishing email through to the BEC financial fraud attempt — to illustrate why modern M365 investigations require evidence from both cloud and endpoint environments.
All identifying information has been replaced with fictional data. The investigation methodology, attack patterns, and evidence sources are real.
The Attack Timeline
07:38 UTC — Phishing email delivered. The email appeared to be a Microsoft 365 password expiry notification. The sender domain was registered within the past 48 hours, with valid SPF, DKIM, and DMARC records — purpose-built infrastructure that passed email authentication checks. The URL pointed to an adversary-in-the-middle proxy server that perfectly mirrored the Microsoft login page.
07:41 UTC — Credentials and MFA captured. The user entered their credentials and completed the MFA push notification. The AiTM proxy relayed the authentication to Microsoft in real time, received the valid session token, and stored it. MFA did not prevent this — the user completed a legitimate MFA challenge issued by Microsoft, relayed transparently through the attacker’s proxy. This is the fundamental challenge of AiTM: the authentication is real, the MFA is real, and the session token is valid.
07:42 UTC — Attacker session established. The attacker replayed the stolen session token from a different IP address in a different country. Entra ID accepted the token — it was valid, issued by Microsoft, and contained a completed MFA claim. The sign-in logs now showed two concurrent valid sessions for the same user: the legitimate session from the UK and the attacker’s session from Eastern Europe.
07:42-08:10 UTC — Email reconnaissance. The attacker accessed the compromised mailbox and read 47 emails, with a clear focus on the Finance-Invoices folder. They synced four folders (Inbox, Sent Items, Finance-Invoices, Contacts), downloading the contents for offline analysis. The contact list was harvested — likely for future phishing campaigns. This behavior was visible through MailItemsAccessed events (available with E5/Audit Premium licensing).
08:12 UTC — Inbox rules created. Two rules: “Finance Filter” forwarded every email containing financial keywords (invoice, payment, wire transfer, bank details) to an external Protonmail address while moving the originals to the RSS Feeds folder — hiding them from the user. “Cleanup” auto-deleted bounce-back emails from the attacker’s own sent messages. These rules are mailbox-level configurations that survive password resets and session revocations.
09:20 UTC — Organization-wide escalation. Using Exchange Administrator privileges obtained through a role assignment, the attacker created a transport rule that silently BCCed every financial email from every user in the organization to an external address. This elevated the attack from single-mailbox interception to organization-wide email surveillance. During its active period, 34 emails from 18 different users were copied to the attacker.
09:32 UTC — BEC email sent. A fraudulent email was sent from the compromised account to accounts payable, requesting that an upcoming vendor payment of $47,250 be redirected to new bank details. The email referenced a real invoice number and used language consistent with the compromised user’s normal communication style. Because it originated from a legitimate internal mailbox, it bypassed all inbound email security controls.
10:12 UTC — Internal phishing. The attacker used the compromised account to send a phishing email to 12 other employees, leveraging the trust of an internal sender to attempt credential theft on additional accounts.
Why This Required Both Cloud and Endpoint Investigation
The cloud investigation revealed the identity compromise (AiTM token replay in the sign-in logs), the email access scope (47 emails read, 4 folders synced), the interception mechanisms (inbox rules, transport rule), the BEC fraud attempt ($47,250), and the persistence (OAuth application with Mail.ReadWrite.All admin consent).
The endpoint investigation revealed the payload execution (dropped to the user’s workstation via a downloaded attachment), the credential dump (LSASS accessed by the beacon process), and the lateral movement (from the initial workstation to a domain controller). Without the endpoint evidence, the containment plan would have missed the backdoor on the workstation and the compromised credentials that could be used to re-enter the environment.
Neither investigation alone told the complete story. The unified investigation — covering both environments — produced a containment plan that addressed every persistence mechanism and a remediation that closed every attack vector.
Key Takeaways for Defenders
Phishing-resistant MFA is the only AiTM defense. Push notifications, SMS, and authenticator app codes can all be relayed through an AiTM proxy. FIDO2 security keys and Windows Hello for Business bind the authentication to the origin domain — the proxy cannot relay them because the cryptographic response is tied to the legitimate Microsoft domain.
Inbox rules survive password resets. The most commonly missed containment step in BEC investigations. Resetting the password and revoking sessions does not remove inbox rules. They continue forwarding email until explicitly deleted.
Transport rules require admin-level investigation. An attacker with Exchange Administrator privileges can intercept email organization-wide. Checking inbox rules is not sufficient — the ExchangeAdmin audit log must be reviewed for transport rule changes during the incident window.
Block external auto-forwarding. A transport rule that blocks all auto-forwarding to external recipients (MessageTypeMatches AutoForward) would have prevented the inbox rule exfiltration in this incident. This is the single most impactful BEC prevention control.
MailItemsAccessed requires E5. Without E5/Audit Premium licensing, you cannot determine which specific emails the attacker read. On E3, you can see that the attacker had mailbox access, but not which emails they opened. This gap directly impacts the accuracy of regulatory notifications.
Learn the Complete Investigation
This case study is the running investigation scenario in the Practical Incident Response: Windows and Microsoft 365 course on this platform. Every module in the course produces formal investigation findings from this incident — from the initial Prefetch analysis of the dropped payload through the Entra ID sign-in log investigation to the Exchange Online forensics.
The first three modules are free. No account required. No email gate.