Token Theft Detection: The MFA Bypass Attack That Boards Must Account For

AiTM Phishing: Detecting Token Theft Attacks in Real Time

Adversary-in-the-Middle (AiTM) phishing is the most significant evolution in credential theft techniques since the introduction of multi-factor authentication. These attacks do not crack passwords or bypass MFA through technical vulnerability, they render MFA irrelevant by stealing the authenticated session token after the user completes legitimate authentication. Understanding and detecting AiTM attacks is essential for any organisation relying on Microsoft 365 as its primary productivity platform.

How AiTM Attacks Work

The attack flow is straightforward and highly effective:

1. Phishing delivery: The attacker sends a convincing phishing email with a link to a login page. The email typically impersonates a Microsoft service (SharePoint sharing notification, Teams message, or Microsoft security alert).

2. Reverse proxy: The link does not point to a static credential harvesting page. Instead, it points to a reverse proxy server (commonly built with tools like Evilginx2 or Modlishka) that sits between the user and the real Microsoft login page.

3. Transparent authentication: The reverse proxy forwards the user's requests to the genuine Microsoft Entra ID login page and relays the responses back to the user. The user sees the real Microsoft login page, enters their real credentials, and completes their real MFA challenge (push notification, SMS code, or authenticator app).

4. Token capture: When Entra ID issues the authentication token (session cookie), the reverse proxy intercepts it before passing it to the user. The attacker now possesses a valid, MFA-authenticated session token.

5. Session hijack: The attacker imports the stolen token into their own browser. They are now authenticated as the victim, with full access to Microsoft 365, without needing the victim's password or MFA device. The token is valid until it expires (typically 1 hour for access tokens, up to 90 days for refresh tokens with default configuration).

Why MFA Does Not Help

This is the critical point that many security teams struggle with. MFA was designed to prevent authentication when credentials are stolen. AiTM attacks do not steal credentials in isolation, they steal the completed authentication session. The user successfully authenticates with MFA, and the attacker captures the result. Push MFA, SMS codes, and authenticator app codes are all equally ineffective against AiTM because they are all completed before the token is captured.

The only MFA methods that defeat AiTM are phishing-resistant authenticators: FIDO2 security keys and Windows Hello for Business. These methods are bound to the legitimate domain, a FIDO2 key will not respond to a proxy domain because the cryptographic challenge is domain-specific. If the user's browser is communicating with an attacker's proxy (attacker-domain.com) instead of login.microsoftonline.com, the FIDO2 key simply will not authenticate.

Detection Signals in Entra ID

While prevention (via phishing-resistant MFA) is the ultimate solution, detection must be in place for the transition period. Entra ID generates several signals that indicate AiTM-based token theft:

Signal 1: Anomalous Token (Entra ID Protection)

Entra ID Protection analyses token characteristics and flags anomalous tokens. Navigate to Entra ID > Security > Identity Protection > Risk detections. The "Anomalous Token" detection identifies tokens with unusual characteristics - specifically, tokens where the authentication location does not match the token replay location. If a user authenticates from London but the token is replayed from Moscow 10 seconds later, Entra ID flags this as anomalous.

Ensure Identity Protection is configured with:

• Sign-in risk policy: Block or require MFA for High risk sign-ins
• User risk policy: Require password change for High risk users

Signal 2: Unfamiliar Sign-in Properties

This detection fires when a sign-in exhibits properties not previously associated with the user - unfamiliar IP address, ASN (network provider), location, or browser. AiTM attacks typically replay tokens from infrastructure that is entirely different from the victim's normal sign-in pattern.

Signal 3: Impossible Travel

If the same user authenticates from two geographically impossible locations within a short timeframe (e.g., London and New York within 5 minutes), this indicates either token theft or credential sharing. While not AiTM-specific, impossible travel is a common indicator of token replay.

Signal 4: Suspicious Inbox Rule Creation

One of the first actions attackers take after gaining access via AiTM is creating inbox rules to hide their activity. They create rules that move security alerts, password reset emails, or communications from specific domains to deleted items or obscure folders. Monitor for inbox rule creation events in the audit log, particularly rules that delete or move emails matching keywords like "security," "alert," "suspicious," or "password."

Sentinel Detection Rules

Microsoft Sentinel provides advanced detection capabilities through KQL (Kusto Query Language) analytics rules. Deploy these rules for AiTM detection:

Rule 1: Token replay from different IP

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType == 0
| summarize IPAddresses = make_set(IPAddress), Count = count() by UserPrincipalName, bin(TimeGenerated, 10m)
| where array_length(IPAddresses) > 1
| extend IPCount = array_length(IPAddresses)
| where IPCount >= 2

This identifies users authenticating from multiple IP addresses within 10-minute windows, a strong indicator of token replay.

Rule 2: Suspicious inbox rule after risky sign-in

let riskySignIns = SigninLogs
| where RiskLevelDuringSignIn in ("high", "medium")
| project UserPrincipalName, RiskySignInTime = TimeGenerated;
let inboxRules = OfficeActivity
| where Operation == "New-InboxRule"
| project UserPrincipalName = UserId, RuleCreationTime = TimeGenerated, Parameters;
riskySignIns
| join kind=inner inboxRules on UserPrincipalName
| where RuleCreationTime between (RiskySignInTime .. (RiskySignInTime + 2h))

This correlates risky sign-ins with subsequent inbox rule creation, a classic AiTM post-compromise pattern.

Rule 3: Authentication from known AiTM infrastructure

Maintain a threat intelligence feed of known AiTM proxy IP ranges and domains. Sentinel's Threat Intelligence connector can ingest these indicators and match them against sign-in logs in real time.

Response Playbook for Confirmed Token Theft

When AiTM token theft is confirmed, execute the following response sequence:

Immediate containment (0-15 minutes):

1. Revoke all refresh tokens: In Entra ID, navigate to the user's profile and click "Revoke sessions." This invalidates all active tokens across all devices and applications.
2. Reset password: Even though the password was not directly compromised, reset it to invalidate any cached credentials.
3. Disable user account: If the scope of compromise is unclear, temporarily disable the account to halt all access.
4. Block sign-in from attacker IP: Create a Conditional Access policy blocking the attacker's observed IP address (named location set to blocked).

Investigation (15-60 minutes): 5. Review audit logs: Search the unified audit log for all actions taken by the user during the compromise window. Key events: file downloads, email forwarding rule creation, SharePoint permission changes, Power Automate flow creation. 6. Check for persistence mechanisms: Search for inbox rules, mail forwarding rules, OAuth app consent grants, and new MFA methods registered on the account during the compromise window. 7. Assess data exposure: Identify which files, emails, and Teams conversations were accessed during the compromise. Use Defender for Cloud Apps activity log for detailed file access history.

Recovery (1-4 hours): 8. Remove persistence: Delete any inbox rules, forwarding rules, OAuth grants, or MFA methods created during the compromise. 9. Re-enable account: Once persistence is removed and the password is reset, re-enable the account with a Conditional Access policy requiring phishing-resistant MFA. 10. Notify affected parties: If client data or sensitive information was accessed, initiate the data breach notification process per GDPR Article 33 (72-hour notification to supervisory authority).

Post-incident (1-7 days): 11. Accelerate phishing-resistant MFA: Use the incident to justify budget and timeline for FIDO2 or Windows Hello for Business deployment. 12. Implement Continuous Access Evaluation (CAE): Enable CAE in Entra ID to reduce token lifetime and enable near-real-time token revocation. 13. Configure token protection (preview): Entra ID token protection binds tokens to the device, preventing replay from a different device.

AiTM attacks represent a fundamental shift in the threat landscape. Organisations that rely solely on traditional MFA are operating with a false sense of security. Detection and response capabilities must be in place while the transition to phishing-resistant authentication is completed.