Microsoft Entra ID Impossible Travel Sign-in

Detects successful Microsoft Entra ID interactive sign-ins for the same user from two geographically separated locations within a 90-minute window, where the implied travel speed between the two points exceeds what is physically possible (>=800 km/h, faster than modern commercial airliners) and the geographic separation is at least 500 km. This pattern indicates either VPN/proxy use or an adversary signing in to a compromised account from a different location than the legitimate user. Non-interactive sign-in categories are excluded because backend token refresh activity routinely egresses through cloud regions unrelated to the user. This activity is often observed from AiTM phishing kits or successful phishing campaigns.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/05/15"
  3integration = ["azure"]
  4maturity = "production"
  5min_stack_version = "9.4.0"
  6min_stack_comments = "ES|QL FIRST and LAST aggregation functions are GA in 9.4."
  7updated_date = "2026/05/15"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Detects successful Microsoft Entra ID interactive sign-ins for the same user from two geographically separated locations
 13within a 90-minute window, where the implied travel speed between the two points exceeds what is physically possible
 14(>=800 km/h, faster than modern commercial airliners) and the geographic separation is at least 500 km. This pattern
 15indicates either VPN/proxy use or an adversary signing in to a compromised account from a different location than the
 16legitimate user. Non-interactive sign-in categories are excluded because backend token refresh activity routinely
 17egresses through cloud regions unrelated to the user. This activity is often observed from AiTM phishing kits or
 18successful phishing campaigns.
 19"""
 20false_positives = [
 21    """
 22    Users on VPN or proxy egress that geo-resolves through a region distant from the user's physical location. Mobile
 23    clients on cellular carrier networks that peer through regional hubs may geo-resolve to a different region than the
 24    user's physical location. Corporate AWS Workspaces / VDI deployments where employees interactively sign in from a
 25    cloud-provider ASN.
 26    """,
 27]
 28from = "now-90m"
 29interval = "30m"
 30language = "esql"
 31license = "Elastic License v2"
 32name = "Microsoft Entra ID Impossible Travel Sign-in"
 33note = """## Triage and analysis
 34
 35### Investigating Microsoft Entra ID Impossible Travel Sign-in
 36
 37Microsoft Entra ID is accessible globally; legitimate users authenticate from one location at a time. Two successful interactive sign-ins for the same user separated by a distance and time delta implying travel faster than a commercial airliner cannot be the same human physically moving, and indicate either a VPN/proxy egress mismatch or a compromised account being accessed from a separate location by an adversary.
 38
 39This rule scopes to `SignInLogs` (interactive sign-ins) only; non-interactive token refresh activity is excluded because backend service calls routinely egress through cloud regions unrelated to the user.
 40
 41### Possible investigation steps
 42
 43- Identify the user (`azure.signinlogs.properties.user_principal_name`) and the geographic separation observed: `Esql.distance_km`, `Esql.travel_kmh`, `Esql.window_minutes` (bbox path over region centroids), and the set of distinct countries, regions, and cities (`Esql.source_geo_country_name_values`, `Esql.source_geo_region_name_values`, `Esql.source_geo_city_name_values`).
 44- Cross-check `Esql.honest_distance_km`, `Esql.honest_travel_kmh`, `Esql.honest_window_minutes` -- these measure the real great-circle distance between the user's actual first and last sign-in events with timestamps locked to those same events. When the honest distance is small but the bbox distance is large, the user appeared in an outlier region in the middle of the window (A->B->A pattern -- typical AiTM kit replay). When both agree, it's a clean two-region case.
 45- Pull all `azure.signinlogs` events with `azure.signinlogs.category: SignInLogs` for the user across the alert window. Sort by `@timestamp` and inspect each `source.ip`, `source.as.organization.name`, `source.geo.country_name`, `user_agent.original`, `azure.signinlogs.properties.device_detail.browser`, and `azure.signinlogs.properties.device_detail.operating_system`.
 46- Determine which sign-ins are consistent with the user's baseline (corporate VPN egress, home ISP, mobile carrier) and which are not. Pay close attention to UA / browser / OS divergence between the two geographic clusters — adversary sessions almost always show a distinct fingerprint from the legitimate user's.
 47- For each non-baseline sign-in: check the ASN. Hosting-provider ASNs (Clouvider, Host Telecom, Alibaba, cheap-VPS providers, and AWS/Azure/GCP rented compute) for interactive sign-ins are high-fidelity suspicious because legitimate end users do not typically egress through those networks.
 48- Inspect `Esql.app_id_values`, `Esql.app_display_name_values`, `Esql.resource_id_values`, and `Esql.resource_display_name_values` for the apps and resources touched from each geo. Microsoft Graph, Azure PowerShell, or Azure Resource Manager access from a non-baseline geo immediately after a baseline sign-in is the post-auth recon signature.
 49- Cross-reference Entra audit logs (`logs-azure.auditlogs-*`) for `add service principal`, `consent to application`, OAuth consent grants, MFA method registration, or recovery email/phone changes for the same user near the same window. Adversaries routinely add persistence immediately after authentication.
 50- Confirm with the user whether the sign-ins are theirs (VPN, travel) or unexpected.
 51
 52### False positive analysis
 53
 54- Users on VPN or proxy infrastructure egressing through a distant region: validate against the user's known VPN ranges and consider excluding by ASN at the rule-exception layer (not in the base query).
 55- Mobile carriers that geo-resolve outside the user's home country (cellular providers often peer through regional hubs): validate by user-agent (mobile UA fingerprint) and source ASN (carrier networks).
 56- AWS Workspaces / VDI / corporate-cloud deployments where employees interactively sign in from a cloud ASN: validate the AS organization name and the tenant's cloud footprint, then except the specific ASN per-tenant rather than blanket-excluding cloud ASNs (which would also suppress adversary sign-ins from rented compute).
 57
 58### Response and remediation
 59
 60- If the pattern is unexpected, immediately revoke all refresh tokens for the user (`Revoke-AzureADUserAllRefreshToken` or `Revoke-MgUserSignInSession`) and force re-authentication, then reset the password and clear any recovery methods.
 61- Investigate any OAuth consent grants minted to the user around the same window — these survive password resets if not explicitly revoked.
 62- Review Entra audit logs for any newly registered authentication methods (FIDO key, authenticator app, phone number) added near the same window: these are adversary persistence vectors.
 63- Review device registration events (`Add registered owner to device`, `Add registered users to device`) — adversary device joins establish persistence that survives password rotation if the underlying refresh tokens were not revoked.
 64- Cross-check Azure activity logs (`logs-azure.activitylogs-*`) for any resource changes by the user from a non-baseline `source.ip` in the same window.
 65"""
 66references = ["https://any.run/malware-trends/tycoon/"]
 67risk_score = 73
 68rule_id = "bc9f5144-0ead-476e-ba6e-cef295601195"
 69severity = "high"
 70tags = [
 71    "Domain: Cloud",
 72    "Domain: Identity",
 73    "Data Source: Azure",
 74    "Data Source: Microsoft Entra ID",
 75    "Data Source: Microsoft Entra ID Sign-in Logs",
 76    "Use Case: Threat Detection",
 77    "Use Case: Identity and Access Audit",
 78    "Tactic: Initial Access",
 79    "Tactic: Credential Access",
 80    "Resources: Investigation Guide",
 81]
 82timestamp_override = "event.ingested"
 83type = "esql"
 84
 85query = '''
 86// successful interactive sign-ins with country + region populated.
 87from logs-azure.signinlogs-*
 88| where data_stream.dataset == "azure.signinlogs"
 89    and event.outcome == "success"
 90    and azure.signinlogs.category == "SignInLogs"
 91    and azure.signinlogs.properties.user_principal_name is not null
 92    and source.geo.location is not null
 93    and source.geo.region_name is not null
 94
 95| eval Esql.source_geo_lat = st_y(source.geo.location),
 96       Esql.source_geo_lon = st_x(source.geo.location)
 97
 98// collapse each (user, country, region) into one centroid + the actual lat/lon
 99// of the first and last event in that region. FIRST/LAST lock coords to the
100// timestamp ordering so we can later build the honest event pair.
101| stats
102    Esql.region_centroid_lat = avg(Esql.source_geo_lat),
103    Esql.region_centroid_lon = avg(Esql.source_geo_lon),
104    Esql.region_first_lat    = first(Esql.source_geo_lat, @timestamp),
105    Esql.region_first_lon    = first(Esql.source_geo_lon, @timestamp),
106    Esql.region_last_lat     = last(Esql.source_geo_lat,  @timestamp),
107    Esql.region_last_lon     = last(Esql.source_geo_lon,  @timestamp),
108    Esql.region_first_seen   = min(@timestamp),
109    Esql.region_last_seen    = max(@timestamp),
110    Esql.region_event_count  = count(*),
111    Esql.region_city_values   = values(source.geo.city_name),
112    Esql.region_asn_values    = values(source.`as`.organization.name),
113    Esql.region_ip_values     = values(source.ip),
114    Esql.region_ua_values     = values(user_agent.original),
115    Esql.region_app_id_values = values(azure.signinlogs.properties.app_id),
116    Esql.region_app_display_name_values = values(azure.signinlogs.properties.app_display_name),
117    Esql.region_client_app_used_values  = values(azure.signinlogs.properties.client_app_used),
118    Esql.region_resource_id_values      = values(azure.signinlogs.properties.resource_id),
119    Esql.region_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),
120    Esql.region_browser_values = values(azure.signinlogs.properties.device_detail.browser),
121    Esql.region_os_values      = values(azure.signinlogs.properties.device_detail.operating_system)
122  by azure.signinlogs.properties.user_principal_name,
123     source.geo.country_name,
124     source.geo.region_name
125
126// roll up to the user. two parallel measurements:
127// bbox: corners over region centroids. catches A->B->A because B is still
128// a centroid in the set even when first/last events are in A.
129| stats
130    Esql.min_lat = min(Esql.region_centroid_lat),
131    Esql.max_lat = max(Esql.region_centroid_lat),
132    Esql.min_lon = min(Esql.region_centroid_lon),
133    Esql.max_lon = max(Esql.region_centroid_lon),
134    Esql.honest_first_lat = first(Esql.region_first_lat, Esql.region_first_seen),
135    Esql.honest_first_lon = first(Esql.region_first_lon, Esql.region_first_seen),
136    Esql.honest_last_lat  = last(Esql.region_last_lat,   Esql.region_last_seen),
137    Esql.honest_last_lon  = last(Esql.region_last_lon,   Esql.region_last_seen),
138    Esql.timestamp_first_seen = min(Esql.region_first_seen),
139    Esql.timestamp_last_seen  = max(Esql.region_first_seen), // first arrival in last region > tighter bbox window
140    Esql.honest_last_time     = max(Esql.region_last_seen),  // user's actual last event > honest window
141    Esql.region_count  = count_distinct(source.geo.region_name),
142    Esql.country_count = count_distinct(source.geo.country_name),
143    Esql.event_count   = sum(Esql.region_event_count),
144    Esql.source_geo_country_name_values     = values(source.geo.country_name),
145    Esql.source_geo_region_name_values      = values(source.geo.region_name),
146    Esql.source_geo_city_name_values        = values(Esql.region_city_values),
147    Esql.source_as_organization_name_values = values(Esql.region_asn_values),
148    Esql.source_ip_values                   = values(Esql.region_ip_values),
149    Esql.user_agent_original_values         = values(Esql.region_ua_values),
150    Esql.app_id_values                      = values(Esql.region_app_id_values),
151    Esql.app_display_name_values            = values(Esql.region_app_display_name_values),
152    Esql.client_app_used_values             = values(Esql.region_client_app_used_values),
153    Esql.resource_id_values                 = values(Esql.region_resource_id_values),
154    Esql.resource_display_name_values       = values(Esql.region_resource_display_name_values),
155    Esql.device_detail_browser_values       = values(Esql.region_browser_values),
156    Esql.device_detail_operating_system_values = values(Esql.region_os_values)
157  by azure.signinlogs.properties.user_principal_name
158
159// need at least 2 regions to have anything to compare. cap at 5 because regions
160// are finer-grained than countries (a traveling employee can hit 3-4 in 90m via
161// carrier hub bouncing) > bbox drift stays bounded below this.
162| where Esql.region_count >= 2 and Esql.region_count <= 5
163
164// bbox path (primary trigger): corners over region centroids.
165| eval Esql.p1 = to_geopoint(concat("POINT(", to_string(Esql.min_lon), " ", to_string(Esql.min_lat), ")")),
166       Esql.p2 = to_geopoint(concat("POINT(", to_string(Esql.max_lon), " ", to_string(Esql.max_lat), ")"))
167| eval Esql.distance_km    = round(st_distance(Esql.p1, Esql.p2) / 1000.0, 0),
168       Esql.window_minutes = date_diff("minute", Esql.timestamp_first_seen, Esql.timestamp_last_seen),
169       Esql.travel_kmh     = case(Esql.window_minutes > 0,
170                                  round(Esql.distance_km * 60.0 / Esql.window_minutes, 0), null)
171
172// honest pair (triage signal): real coords at the user's actual first and last
173// events, time locked to those same two events
174| eval Esql.honest_p1 = to_geopoint(concat("POINT(", to_string(Esql.honest_first_lon), " ", to_string(Esql.honest_first_lat), ")")),
175       Esql.honest_p2 = to_geopoint(concat("POINT(", to_string(Esql.honest_last_lon),  " ", to_string(Esql.honest_last_lat),  ")"))
176| eval Esql.honest_distance_km     = round(st_distance(Esql.honest_p1, Esql.honest_p2) / 1000.0, 0),
177       Esql.honest_window_minutes  = date_diff("minute", Esql.timestamp_first_seen, Esql.honest_last_time),
178       Esql.honest_travel_kmh      = case(Esql.honest_window_minutes > 0,
179                                          round(Esql.honest_distance_km * 60.0 / Esql.honest_window_minutes, 0), null)
180
181// 500 km separation + faster than a commercial airliner. bbox is the trigger
182// purely as triage signal.
183| where Esql.distance_km >= 500 and Esql.travel_kmh >= 800
184
185| keep azure.signinlogs.properties.user_principal_name,
186    Esql.source_geo_country_name_values,
187    Esql.source_geo_region_name_values,
188    Esql.source_geo_city_name_values,
189    Esql.source_as_organization_name_values,
190    Esql.source_ip_values,
191    Esql.user_agent_original_values,
192    Esql.app_id_values,
193    Esql.app_display_name_values,
194    Esql.client_app_used_values,
195    Esql.resource_id_values,
196    Esql.resource_display_name_values,
197    Esql.device_detail_browser_values,
198    Esql.device_detail_operating_system_values,
199    Esql.country_count,
200    Esql.region_count,
201    Esql.event_count,
202    Esql.timestamp_first_seen,
203    Esql.timestamp_last_seen,
204    Esql.window_minutes,
205    Esql.distance_km,
206    Esql.travel_kmh,
207    Esql.honest_distance_km,
208    Esql.honest_travel_kmh,
209    Esql.honest_window_minutes
210'''
211
212[rule.alert_suppression]
213group_by = ["azure.signinlogs.properties.user_principal_name"]
214duration = {value = 30, unit = "m"}
215missing_fields_strategy = "suppress"
216
217[[rule.threat]]
218framework = "MITRE ATT&CK"
219[[rule.threat.technique]]
220id = "T1078"
221name = "Valid Accounts"
222reference = "https://attack.mitre.org/techniques/T1078/"
223[[rule.threat.technique.subtechnique]]
224id = "T1078.004"
225name = "Cloud Accounts"
226reference = "https://attack.mitre.org/techniques/T1078/004/"
227
228
229
230[rule.threat.tactic]
231id = "TA0001"
232name = "Initial Access"
233reference = "https://attack.mitre.org/tactics/TA0001/"
234[[rule.threat]]
235framework = "MITRE ATT&CK"
236[[rule.threat.technique]]
237id = "T1528"
238name = "Steal Application Access Token"
239reference = "https://attack.mitre.org/techniques/T1528/"
240
241[[rule.threat.technique]]
242id = "T1557"
243name = "Adversary-in-the-Middle"
244reference = "https://attack.mitre.org/techniques/T1557/"
245
246
247[rule.threat.tactic]
248id = "TA0006"
249name = "Credential Access"
250reference = "https://attack.mitre.org/tactics/TA0006/"
251
252[rule.investigation_fields]
253field_names = ["azure.signinlogs.properties.user_principal_name"]

Triage and analysis

Investigating Microsoft Entra ID Impossible Travel Sign-in

Microsoft Entra ID is accessible globally; legitimate users authenticate from one location at a time. Two successful interactive sign-ins for the same user separated by a distance and time delta implying travel faster than a commercial airliner cannot be the same human physically moving, and indicate either a VPN/proxy egress mismatch or a compromised account being accessed from a separate location by an adversary.

This rule scopes to SignInLogs (interactive sign-ins) only; non-interactive token refresh activity is excluded because backend service calls routinely egress through cloud regions unrelated to the user.

Possible investigation steps

  • Identify the user (azure.signinlogs.properties.user_principal_name) and the geographic separation observed: Esql.distance_km, Esql.travel_kmh, Esql.window_minutes (bbox path over region centroids), and the set of distinct countries, regions, and cities (Esql.source_geo_country_name_values, Esql.source_geo_region_name_values, Esql.source_geo_city_name_values).
  • Cross-check Esql.honest_distance_km, Esql.honest_travel_kmh, Esql.honest_window_minutes -- these measure the real great-circle distance between the user's actual first and last sign-in events with timestamps locked to those same events. When the honest distance is small but the bbox distance is large, the user appeared in an outlier region in the middle of the window (A->B->A pattern -- typical AiTM kit replay). When both agree, it's a clean two-region case.
  • Pull all azure.signinlogs events with azure.signinlogs.category: SignInLogs for the user across the alert window. Sort by @timestamp and inspect each source.ip, source.as.organization.name, source.geo.country_name, user_agent.original, azure.signinlogs.properties.device_detail.browser, and azure.signinlogs.properties.device_detail.operating_system.
  • Determine which sign-ins are consistent with the user's baseline (corporate VPN egress, home ISP, mobile carrier) and which are not. Pay close attention to UA / browser / OS divergence between the two geographic clusters — adversary sessions almost always show a distinct fingerprint from the legitimate user's.
  • For each non-baseline sign-in: check the ASN. Hosting-provider ASNs (Clouvider, Host Telecom, Alibaba, cheap-VPS providers, and AWS/Azure/GCP rented compute) for interactive sign-ins are high-fidelity suspicious because legitimate end users do not typically egress through those networks.
  • Inspect Esql.app_id_values, Esql.app_display_name_values, Esql.resource_id_values, and Esql.resource_display_name_values for the apps and resources touched from each geo. Microsoft Graph, Azure PowerShell, or Azure Resource Manager access from a non-baseline geo immediately after a baseline sign-in is the post-auth recon signature.
  • Cross-reference Entra audit logs (logs-azure.auditlogs-*) for add service principal, consent to application, OAuth consent grants, MFA method registration, or recovery email/phone changes for the same user near the same window. Adversaries routinely add persistence immediately after authentication.
  • Confirm with the user whether the sign-ins are theirs (VPN, travel) or unexpected.

False positive analysis

  • Users on VPN or proxy infrastructure egressing through a distant region: validate against the user's known VPN ranges and consider excluding by ASN at the rule-exception layer (not in the base query).
  • Mobile carriers that geo-resolve outside the user's home country (cellular providers often peer through regional hubs): validate by user-agent (mobile UA fingerprint) and source ASN (carrier networks).
  • AWS Workspaces / VDI / corporate-cloud deployments where employees interactively sign in from a cloud ASN: validate the AS organization name and the tenant's cloud footprint, then except the specific ASN per-tenant rather than blanket-excluding cloud ASNs (which would also suppress adversary sign-ins from rented compute).

Response and remediation

  • If the pattern is unexpected, immediately revoke all refresh tokens for the user (Revoke-AzureADUserAllRefreshToken or Revoke-MgUserSignInSession) and force re-authentication, then reset the password and clear any recovery methods.
  • Investigate any OAuth consent grants minted to the user around the same window — these survive password resets if not explicitly revoked.
  • Review Entra audit logs for any newly registered authentication methods (FIDO key, authenticator app, phone number) added near the same window: these are adversary persistence vectors.
  • Review device registration events (Add registered owner to device, Add registered users to device) — adversary device joins establish persistence that survives password rotation if the underlying refresh tokens were not revoked.
  • Cross-check Azure activity logs (logs-azure.activitylogs-*) for any resource changes by the user from a non-baseline source.ip in the same window.

References

Related rules

to-top