Azure AD Sign-In Logs MFA Bypass

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.

Indicators to look for in Azure AD sign-in logs

  • 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

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.

← All use cases