What is AiTM phishing and why doesn't MFA stop it?

Adversary-in-the-middle (AiTM) phishing proxies the real login flow between the victim and the identity provider. The victim completes MFA against the attacker's proxy, which relays the request to the real IdP and receives a valid post-MFA session token. MFA was satisfied, so the authentication log looks clean. The attacker then replays the stolen session token from a different IP.

How does LogTriage detect a stolen session token being replayed?

By combining multiple Azure-specific signals: a non-interactive sign-in (isInteractive: false) using a device or browser fingerprint not previously associated with the account, from an IP/ASN different from the one that completed MFA. No single signal is conclusive alone; the combination is what elevates the risk score.

Which legacy authentication protocols are the most common MFA bypass path?

IMAP, POP3, and older Exchange ActiveSync clients are the most common. They're pre-modern-auth protocols that don't support the Conditional Access redirect flow required to enforce MFA. If Conditional Access has any gap in coverage for these protocols, they remain a viable bypass path.

Can LogTriage tell me which Conditional Access policies failed to block the bypass?

Yes. LogTriage's Azure signal extractor reads appliedConditionalAccessPolicies directly from the sign-in payload and surfaces each policy evaluation result — what evaluated, what succeeded, and what should have blocked but didn't — as a distinct risk factor in the report.

Detecting MFA Bypass in Azure AD Sign-In Logs

Why this matters

MFA dramatically reduces account takeover risk, but it isn’t bulletproof. Adversary-in-the-middle (AiTM) phishing kits proxy the real login flow and steal the session token after MFA succeeds, meaning the sign-in log shows a perfectly legitimate-looking authenticated session — the compromise is in what happens next, not in the authentication event itself. Legacy authentication protocols that don’t support modern MFA prompts are the other common bypass path.

clientAppUsed showing legacy protocols (IMAP, POP3, older Exchange ActiveSync clients) that can’t enforce Conditional Access MFA requirements
isInteractive: false sign-ins immediately following an interactive sign-in from a different device or location
appliedConditionalAccessPolicies showing a policy that evaluated but didn’t actually block
mfaDetail showing successful MFA paired with a device or browser fingerprint that’s never been seen for that user before
A session token being used from a different IP/ASN than the one that originally authenticated it

How LogTriage detects this

The Azure-specific signal extractor (azure_signals.py) reads conditionalAccessStatus, mfaDetail, appliedConditionalAccessPolicies, and device trust state directly from the sign-in payload, and surfaces each as a distinct, named risk factor — not a single opaque score. That matters here specifically: telling an analyst which control was bypassed (legacy auth vs. a policy gap vs. a stolen session) is what actually shortens the response.

Detection / evidence checklist

Identify whether legacy authentication protocols are still enabled for the affected account or tenant-wide
Check for session tokens used from a second IP/device shortly after the original authentication
Review Conditional Access policy assignment — confirm the policy that should apply to this user/app combination is actually enabled, not just configured
If AiTM is suspected, revoke all active sessions and refresh tokens for the account, not just the password
Disable legacy authentication protocols tenant-wide if they aren’t required by a specific, documented application

Frequently Asked Questions

What is AiTM phishing and why doesn't MFA stop it?: Adversary-in-the-middle (AiTM) phishing proxies the real login flow between the victim and the identity provider. The victim completes MFA against the attacker's proxy, which relays the request to the real IdP and receives a valid post-MFA session token. MFA was satisfied, so the authentication log looks clean. The attacker then replays the stolen session token from a different IP.
How does LogTriage detect a stolen session token being replayed?: By combining multiple Azure-specific signals: a non-interactive sign-in (isInteractive: false) using a device or browser fingerprint not previously associated with the account, from an IP/ASN different from the one that completed MFA. No single signal is conclusive alone; the combination is what elevates the risk score.
Which legacy authentication protocols are the most common MFA bypass path?: IMAP, POP3, and older Exchange ActiveSync clients are the most common. They're pre-modern-auth protocols that don't support the Conditional Access redirect flow required to enforce MFA. If Conditional Access has any gap in coverage for these protocols, they remain a viable bypass path.
Can LogTriage tell me which Conditional Access policies failed to block the bypass?: Yes. LogTriage's Azure signal extractor reads appliedConditionalAccessPolicies directly from the sign-in payload and surfaces each policy evaluation result — what evaluated, what succeeded, and what should have blocked but didn't — as a distinct risk factor in the report.

See this detection run on a real report

Try the live demo with a pre-loaded malicious log set — no signup required — or upload your own log file and get a full AI-reviewed threat report in minutes.

Try Live Demo → Analyze Your Own Logs