Use Case: Identity
Impossible travel detection
A login from London followed by a login from Singapore 12 minutes later. Either your user has a private jet or someone stole their credentials. ManySignal knows which.
The credential theft you almost missed
A threat actor purchases a valid Okta credential from a dark web marketplace at 3:47 AM. The credential was harvested six months earlier via a phishing kit but only made it to this particular forum listing two weeks ago. The legitimate user authenticated from their home IP in Toronto at 3:39 AM — they were checking overnight Slack messages. Eight minutes later, the attacker authenticates from a residential IP in Amsterdam that routes through three consecutive Tor hops before reaching the Okta login endpoint.
The SIEM fires an impossible-travel alert at 4:02 AM. The on-call analyst sees it at 6:15 AM when they log in. By then, the attacker has spent 2 hours and 28 minutes in Microsoft 365, forwarding email to an external address and downloading a SharePoint folder containing Q3 board materials.
The reason this is hard to catch without automation: the SIEM alert is #47 in the queue, has no context about what the attacker did after login, and requires the analyst to manually cross-reference Okta logs, M365 audit logs, and IP reputation data from three separate consoles.
Trigger detection sketch
rule: impossible_travel_v2
type: correlation
sources:
- okta_system_log
- entra_signin_log
- google_workspace_login
trigger:
- event: authentication.success
- within: 30m
- same_user: true
- condition: |
geo_distance(auth1.ip, auth2.ip) / time_delta_hours > 900
AND NOT (auth1.ip IN corporate_vpn_ranges
OR auth2.ip IN corporate_vpn_ranges)
enrichments:
- ip_geolocation: maxmind_city
- ip_reputation: virustotal, shodan, recorded_future
- device_known: mdm_device_inventory
- hibp_breach_check: user.email
- calendar_travel: gsuite_calendar, o365_calendar
risk_score: 87
mitre: T1078.004 (Valid Accounts: Cloud Accounts)
Questions the agent asks before escalating
The triage agent answers each question automatically by querying the relevant data source. The analyst sees the answers, not the raw data.
What is the physical distance and minimum travel time between the two authentication locations?
Geo enrichmentDid a VPN or Tor exit node appear in either authentication event?
IP reputationHas this user authenticated from either location in the past 30 days?
Baseline lookupDid the second authentication succeed, and what actions followed within 15 minutes?
Activity logIs the second device a known, registered device for this user?
Device inventoryIs there an active Okta or Entra session still open from the first location?
Session graphHas the user's account been found in any recent breach dataset?
HaveIBeenPwned / HIBPDid the user submit a travel request or is a meeting in that city on their calendar?
HR / CalendarWhat happens after the triage agent answers
Revoke active sessions from the anomalous location via Okta or Entra ID API
AutonomousSend Slack message to user asking them to confirm or deny the login
AutonomousIf user denies: disable account and page the on-call analyst
Approve-gatedIf confirmed travel: add location to 30-day trusted location exemption
AutonomousEscalate to identity compromise workflow if 2+ denied logins in 7 days
RecommendHow this plays out in a legacy SOC
Alert fires at 4:02 AM. Analyst queue already has 63 open items. The impossible-travel alert is classified P2 (medium) because there's no automated context. The analyst manually opens Okta, copies the user's email, pivots to Microsoft 365 Defender, searches audit logs, downloads a CSV, and opens it in Excel to find the forwarding rule. This takes 45 minutes when done carefully. By the time the account is disabled, the attacker has been in the environment for 3+ hours and has already exfiltrated the board materials to a Dropbox account they control.
MITRE ATT&CK mapping
Impossible travel FAQ
What travel speed threshold triggers the detection?
ManySignal uses 900 km/h as the maximum credible commercial air speed. Any authentication pair that requires faster travel than that — including layover time — is flagged. VPN and Tor IPs are flagged immediately regardless of distance.
Does the detection handle legitimate split-tunnel VPN scenarios?
Yes. When a corporate VPN IP is detected, ManySignal resolves the egress IP to the corporate gateway and suppresses the impossible-travel flag if the gateway city matches a known office location. Split-tunnel environments are handled by marking corporate IP ranges as trusted zones.
Can an attacker evade this by using a VPN near the victim's city?
Using a VPN near the victim reduces the geographic anomaly score, which is why ManySignal combines location with device fingerprint, user agent, and behavioral baseline. A new device from a new ASN in a 'nearby' city still scores high on the composite risk model.
How quickly does the detection fire?
Within 90 seconds of the second authentication event landing in the data pipeline. Alert-to-triage-agent execution is under 3 minutes for identity events.
What identity providers are supported?
Microsoft Entra ID, Okta, Google Workspace, Ping Identity, JumpCloud, and any OIDC-compliant IdP via generic connector. Auth0 and Cognito are supported for application-layer authentication.
Run impossible travel detection against your IdP
Connect Okta or Entra ID in 15 minutes. See real alerts from your environment in the first session.