12.1 Understanding AiTM Attack Mechanics

Understanding AiTM Attack Mechanics

An adversary-in-the-middle credential phishing attack does not attempt to guess, brute-force, or crack a password. It does not exploit a vulnerability in MFA. It proxies the entire authentication session — capturing the user’s password AND the session token that the identity provider issues after MFA succeeds. The attacker replays this stolen token to access the victim’s account without ever triggering another MFA challenge.

This is why AiTM phishing is the highest-priority attack technique for M365 environments: it renders MFA ineffective as a preventive control while leaving no trace of MFA bypass in the logs. The sign-in log shows a successful MFA authentication. It looks legitimate. The only indicators are the infrastructure the authentication was proxied through and the post-authentication behaviour that follows.

How the AiTM proxy works

A standard phishing attack sends the victim to a fake login page that captures their password. The attacker then uses the stolen password to sign in — but MFA blocks them because they cannot provide the second factor.

An AiTM attack eliminates this problem. The attacker deploys a reverse proxy server (typically using toolkits like Evilginx2, Muraena, or Modlishka) that sits between the victim and the real Microsoft login page. The proxy:

1. Serves a phishing page that looks identical to the Microsoft sign-in page. The URL is different (e.g., login-microsoftonline.secure-portal-verify.com) but the page content is visually identical.

2. When the victim enters their username and password, the proxy forwards these credentials to the real Microsoft login page in real time.

3. Microsoft’s sign-in service receives a valid username and password. It triggers the user’s configured MFA challenge (Authenticator push, SMS code, FIDO2 key).

4. The victim completes the MFA challenge on their real device — because it IS a real authentication to the real Microsoft login service. The proxy is transparent.

5. Microsoft issues a session token (a cookie containing the authentication state). The proxy captures this token before forwarding the authenticated page back to the victim.

6. The attacker now has: the user’s password AND a valid session token that has already passed MFA. The attacker replays this token from their own infrastructure to access the victim’s mailbox, SharePoint, Teams, and any other M365 service the user has access to.

The critical insight: MFA protected the authentication — the user completed MFA successfully. But MFA did not protect the session token. The token is a bearer credential — whoever possesses it can use it. There is no binding between the token and the user’s device. This is the fundamental weakness that AiTM exploits.

What the attacker does after token capture

The AiTM proxy captures the token. The attacker’s next actions follow a predictable pattern (documented in Microsoft Threat Intelligence reports on Storm-1167, Storm-0867, and Storm-0539):

Minutes 0-5: Token replay and mailbox access. The attacker replays the stolen session token from their own IP address (typically VPS infrastructure or residential proxy). They access Outlook Web Access or the Graph API to read the victim’s mailbox. The sign-in log shows a successful authentication from a new IP — but since the token already passed MFA, no MFA challenge is recorded for this sign-in.

Minutes 5-15: Persistence establishment. The attacker creates inbox rules to maintain access and hide their activity. Common patterns: create a rule that moves all incoming email containing specific keywords (e.g., “password reset,” “suspicious,” “security alert”) to a hidden folder or deletes it. Create a mail forwarding rule that copies all incoming email to an external address controlled by the attacker.

Minutes 15-60: Reconnaissance. The attacker reads the victim’s recent email to understand: the victim’s role, their communication patterns, their financial authority, and active business transactions. This reconnaissance informs the next phase — BEC.

Hours 1-24: Business email compromise. The attacker uses the compromised mailbox to send emails to internal or external targets — typically: a vendor payment diversion (change banking details on an active invoice), an internal funds transfer request (impersonating the victim to request a wire transfer), or internal phishing (sending phishing emails from the compromised mailbox to other employees, using the victim’s identity as the trust vector).

Hours 1-48: MFA method modification. The attacker may register a new MFA method (their own Authenticator app or phone number) to maintain access even after the stolen token expires. This is persistence — even if the victim’s password is reset, the attacker has their own MFA method registered.

Ongoing: Internal phishing and lateral expansion. The attacker sends phishing emails from the compromised mailbox to other users in the organisation. These internal phishing emails bypass Safe Links and Safe Attachments because they originate from a trusted internal sender. Each successful compromise gives the attacker access to an additional mailbox, expanding the campaign.

Why standard defences fail

MFA does not prevent AiTM. MFA protects the authentication, not the token. The user completes MFA successfully — but the token is captured before it reaches the user’s browser.

Safe Links does not always catch the phishing URL. AiTM phishing pages are hosted on freshly registered domains or compromised legitimate websites. They may not appear in Safe Links’ URL reputation database at the time of the initial campaign. Zero-hour auto purge (ZAP) may remove the email later — but by then, the user has already clicked.

Conditional access without token binding does not prevent token replay. Standard conditional access evaluates the sign-in properties (location, device compliance, application). A replayed token carries the original sign-in properties — it may pass the same conditional access evaluation the legitimate sign-in passed. Only conditional access policies that enforce token binding (Continuous Access Evaluation with strict enforcement, or token protection policies) can detect that the token is being replayed from a different device.

Password reset does not revoke active tokens. If the victim’s password is reset but active tokens are not explicitly revoked, the attacker’s stolen token remains valid until it expires (typically 1 hour for access tokens, up to 90 days for refresh tokens).

What DOES stop AiTM

Token protection (Conditional Access Token Binding). Binds the session token to the device that completed the original authentication. If the token is replayed from a different device, conditional access rejects it. This is the definitive preventive control. Subsection 11.12 covers deployment with blast radius and rollback.

Continuous Access Evaluation (CAE) with strict enforcement. Enforces real-time revocation of tokens when critical events occur (password change, account disable, IP location change). Standard CAE handles some scenarios; strict enforcement mode extends coverage.

FIDO2 security keys. Phishing-resistant authentication that binds the credential to the origin domain. The FIDO2 key will not authenticate to login-microsoftonline.secure-portal-verify.com because it only authenticates to login.microsoftonline.com. The AiTM proxy cannot proxy a FIDO2 challenge because the key validates the domain.

Immediate token revocation as a containment action. Once a compromised account is identified, revoke all refresh tokens (Revoke-AzureADUserAllRefreshToken or Graph API). This forces the attacker’s stolen tokens to expire without renewal. Subsection 11.7 covers this with blast radius and verification.

The investigation indicators

When investigating a potential AiTM attack, these are the indicators you search for. Each maps to a specific investigation subsection later in this module:

This table is the investigation roadmap. The remaining subsections in this module execute each step.

Subsection artifact: The investigation indicator table above. Save it as a reference card. It maps every AiTM indicator to its data source and investigation step — the foundation of the AiTM investigation playbook artifact you will complete by the end of this module.

Knowledge check