Why defenders care
The alert can expose stolen passwords, session token theft, AiTM phishing, malicious proxy use, or unauthorized access from attacker infrastructure.
What impossible travel means
Impossible travel occurs when sign-ins for the same account appear from geographically distant locations within a timeframe that should not be physically possible. It is a starting point, not a verdict.
Why defenders get burned
VPNs, mobile carrier routing, cloud proxies, travel, stale geo-IP data, and corporate egress points can all create high-volume false positives.
Diagram 1 — Impossible travel detection logic
What bad looks like
Real compromises usually include more than one signal. The goal is to correlate impossible travel with identity, device, mailbox, and user behavior.
Session reuse without a password failure
Legitimate login appears first. Minutes later, an attacker reuses a stolen session from another country without obvious password guessing.
Inbox rule after suspicious sign-in
Impossible travel is followed by a new forwarding rule, delete rule, or rule that hides messages from finance, payroll, or executives.
MailItemsAccessed spike
The user has a burst of mailbox activity shortly after the risky sign-in, especially from a new IP, device, app, or country.
High-volume impossible travel does not always mean high-volume compromise.
A wave of alerts can be caused by VPN changes, mobile IP rotation, or bad geo-IP mapping. Treat volume as a triage signal, then pivot into stronger evidence.
Diagram 2 — Investigation workflow
Investigation checklist
Use this checklist to separate false positives from real identity compromise.
| Question | Why it matters | Bad indicator |
|---|---|---|
| Are the IPs known corporate VPN or ZTNA exits? | VPN egress often causes impossible travel noise. | Unknown ASN, anonymizer, residential proxy, hosting provider. |
| Was MFA satisfied, bypassed, or not required? | Authentication strength changes the risk decision. | MFA satisfied from unfamiliar location with no user recognition. |
| Is the device familiar? | Known compliant devices lower risk; unknown devices raise risk. | New browser, new OS, unmanaged device, unfamiliar client app. |
| Were inbox rules created? | BEC actors commonly hide, forward, or delete messages. | Rules targeting finance, payroll, invoices, executives, or security alerts. |
| Was there mailbox access or mass sending? | Post-login behavior often confirms impact. | MailItemsAccessed spike, SendAs activity, external forwarding, phishing sent internally. |
KQL detection blocks
Use these as lab-friendly starting points. Tune names, fields, tables, and thresholds to match your environment and data connector availability.
Successful sign-ins from multiple countries
SigninLogs | where TimeGenerated > ago(1h) | where ResultType == 0 | extend Country = tostring(LocationDetails.countryOrRegion) | summarize Countries = make_set(Country), SignInCount = count(), IPs = make_set(IPAddress) by UserPrincipalName | where array_length(Countries) >= 3 | order by SignInCount desc
Impossible travel plus new client app or device detail
SigninLogs | where TimeGenerated > ago(24h) | where ResultType == 0 | extend Country = tostring(LocationDetails.countryOrRegion) | extend Browser = tostring(DeviceDetail.browser) | extend OS = tostring(DeviceDetail.operatingSystem) | summarize Countries = make_set(Country), Browsers = make_set(Browser), OperatingSystems = make_set(OS), IPs = make_set(IPAddress), Count = count() by UserPrincipalName | where array_length(Countries) >= 2 and (array_length(Browsers) >= 2 or array_length(OperatingSystems) >= 2) | order by Count desc
Suspicious inbox rules after risky sign-in
let RiskyUsers =
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| summarize Countries = make_set(Country) by UserPrincipalName
| where array_length(Countries) >= 2
| project UserPrincipalName;
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation in ("New-InboxRule", "Set-InboxRule")
| where UserId in (RiskyUsers)
| project TimeGenerated, UserId, Operation, ClientIP, Parameters
Diagram 3 — False positive vs compromise decision tree
Response actions
If the correlation points toward compromise, move quickly. Identity incidents spread fast because valid sessions can bypass traditional password-based thinking.
Revoke sessions
Invalidate refresh tokens and force re-authentication. This is critical when token theft or AiTM phishing is suspected.
Reset credentials and MFA
Reset the password, review MFA methods, remove unknown authenticators, and require re-registration when needed.
Remove mailbox persistence
Delete malicious inbox rules, forwarding, OAuth grants, and suspicious app consent created during the compromise window.
Key takeaway: Impossible travel is not the case. It is the doorway into the case. The strongest investigations prove or disprove compromise with correlated behavior.