Detecting Impossible Travel in Azure AD Sign-In Logs

Why this matters

Impossible travel is one of the highest-confidence account compromise signals available, precisely because it doesn’t depend on guessing attacker intent — it’s pure physics. If the same account signs in from Tel Aviv and then from São Paulo nine minutes later, no commercial flight makes that possible. Either the credentials are shared (a policy problem) or stolen (a security incident), and the sign-in log already contains everything you need to tell the two apart.

Indicators to look for in Azure AD sign-in logs

• Two sign-ins for the same userPrincipalName with location fields implying a physically impossible travel speed
• A sudden change in deviceDetail (OS, browser, trust state) alongside the location jump
• riskLevelAggregated already flagged by Entra ID’s own risk engine, but not yet acted on
• A change in clientAppUsed from a normal interactive browser session to a legacy or non-interactive protocol
• conditionalAccessStatus showing success when the policy should have blocked the second location

How LogTriage detects this

LogTriage’s impossible travel detector groups sign-ins per user, computes the haversine distance between consecutive sign-in coordinates, and divides by elapsed time to get implied speed. Anything above 500 km/h (configurable) gets flagged — fast enough to rule out normal travel, slow enough to still catch attackers using VPN exit nodes that aren’t absurdly far apart. Azure AD’s own location coordinates are used directly; for other formats, LogTriage falls back to IP-based geolocation from its own enrichment pipeline, so the same detection logic works even outside Azure AD.

Detection / evidence checklist

• Confirm both sign-in locations and the exact elapsed time between them
• Check whether the account has MFA enabled, and whether MFA was satisfied on both sign-ins
• Review what the account accessed between the two sign-ins — that’s your actual exposure window
• Force a password reset and session revocation if compromise is confirmed
• Check Conditional Access policy logic — a working policy should have blocked the impossible second sign-in