Impossible Travel and Risky Sign-In Alert Investigation: A Step-by-Step Workflow
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The impossible travel alert is one of the most actionable detections in identity security, but it is also one of the most frequently mishandled. Teams either dismiss it as a VPN false positive without investigation (missing real account takeovers) or escalate every alert to full incident response (burning analyst time on false positives). The right approach is a timed, systematic investigation workflow that distinguishes the two cases in 15 minutes or less.
The alert's value is its speed: an impossible travel detection fires during an active authentication event, which means the attacker's session may still be active when the alert reaches your team. Fast investigation and containment — before the attacker exfiltrates data, establishes persistence, or changes authentication factors — determines whether the incident is a minor containment or a major breach.
The 15-minute investigation protocol
The investigation protocol is structured around the decisions that need to be made in order: first, pull both authentication events with full context; second, determine whether either IP is a known false positive source such as a VPN or corporate proxy; third, contact the user directly to confirm or deny the suspicious session; and fourth, review post-alert activity to look for attacker persistence actions that confirm an account takeover even if the user is unreachable. Each step has a time target because the attacker's session is active during the investigation, and actions like adding email forwarding rules or registering new MFA devices happen in the first minutes after authentication. The protocol works across identity providers: Entra ID, Okta, Ping Identity, and Google Workspace all expose the required log data through their respective admin consoles or APIs, though the specific query syntax differs.
Step 1: Pull both authentication events (minutes 1-3)
Extract the full authentication records for both events. For Entra ID: use the Azure AD Sign-ins blade filtered by the user and the alert timeframe, or use the Microsoft Graph API (GET /auditLogs/signIns?$filter=userPrincipalName eq 'user@domain.com' and createdDateTime ge 2026-07-10T14:00:00Z). For each event record: IP address, IP geolocation, device ID, device name, operating system, browser/application, MFA authentication method, Conditional Access policy applied, and whether the login succeeded or failed. Export both events to a temporary working document.
Step 2: Check whether either IP is a VPN or hosting provider (minutes 3-6)
Query both IP addresses against GreyNoise (api.greynoise.io/v3/noise/quick/{ip}) or IPInfo (ipinfo.io/{ip}/json). If either returns {'org': 'Cloudflare', 'hosting': true} or similar VPN/hosting indicators, the suspicious login is likely VPN traffic from the user. Also check your internal IP allowlist: is the IP in your corporate VPN pool, proxy egress range, or known cloud service provider range? If the suspicious IP is a residential IP in a country the user has no connection to, treat it as a confirmed suspicious session regardless of VPN status. Document the IP context in your working notes.
Step 3: Contact the user directly (minutes 6-10)
This is the single fastest way to determine whether the session is legitimate. Send a direct message via a channel you know is controlled by the user (phone call, Microsoft Teams, Slack) — not email, because if the account is compromised, email may be monitored by the attacker. Ask: 'Are you currently traveling?' and 'Are you using a VPN or proxy today?' If the user confirms one session and has no knowledge of the other, the second session is an unauthorized access in progress. Proceed to containment immediately without waiting for further investigation. If the user is unreachable, assume the worst and proceed to containment.
Step 4: Review post-alert session activity (minutes 10-15)
While waiting for user response (or if user is unreachable): check what the suspicious session did after authentication. In Entra ID: review the Unified Audit Log (compliance.microsoft.com > Audit) filtered for the user during the suspicious session window. High-priority activities: New-InboxRule operations (email forwarding rules), Add device to Conditional Access trusted device list, Consent to application, ExchangeItem:Export operations, MFAMethod:Add operations. Any of these in the suspicious session window strongly confirms ATO and triggers immediate containment regardless of user contact.
Containment actions for confirmed ATO
Once you confirm an account takeover, speed and completeness are both critical. Speed matters because the attacker's current access token remains valid even after you revoke refresh tokens, giving them a window of continued access that equals the token lifetime (typically up to one hour in Entra ID). Completeness matters because attackers in ATO scenarios commonly establish multiple persistence mechanisms simultaneously: email forwarding rules, new MFA device registrations, OAuth application authorizations, and new inbox delegates, any one of which restores access if not individually removed. Execute session revocation and password reset in parallel with the persistence audit rather than sequentially, so that the attacker's access is severed while you are discovering what else they did. Preserve all authentication logs and Unified Audit Log entries for the compromise window before they age out of retention.
Revoke all active sessions and tokens
Entra ID (PowerShell): Connect-AzureAD; Revoke-AzureADUserAllRefreshToken -ObjectId (Get-AzureADUser -ObjectId user@domain.com).ObjectId. This invalidates all refresh tokens, forcing re-authentication on the next token request. For Okta: okta.com admin console > Users > {user} > More Actions > Clear user sessions. For Google Workspace: Admin Console > Users > {user} > Reset Sign-in cookies. After revocation, the attacker's active session remains valid until the current access token expires (typically 1 hour for Entra ID, shorter for Okta). Force immediate full re-authentication by also triggering a password reset.
Audit and revert attacker-configured persistence
Check for persistence mechanisms added during the compromise window. Email forwarding rules: Search-UnifiedAuditLog -UserIds user@domain.com -Operations New-InboxRule | Where-Object {$_.CreationDate -ge [alertTime]}. MFA device additions: Search-UnifiedAuditLog -Operations 'Update user' | select -ExpandProperty AuditData | ConvertFrom-Json | Where-Object {$_.ModifiedProperties.Name -contains 'StrongAuthenticationMethod'}. New OAuth app authorizations: Get-AzureADUserOAuth2PermissionGrant | Where-Object {$_.PrincipalId -eq [userObjectId]}. Revert any attacker-added persistence: remove inbox rules, remove unrecognized MFA devices, revoke suspicious OAuth grants.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
The impossible travel alert workflow is: pull both events, check whether either IP is a known VPN or proxy, contact the user directly, review post-alert session activity, and containment if confirmed. Most investigations resolve in 15 minutes with one of two conclusions: VPN false positive (document and tune away) or confirmed ATO (contain immediately). Reduce false positives by maintaining a Conditional Access named locations list of known VPN/proxy ranges, and reduce missed real ATOs by treating user non-response as a confirmation trigger rather than a reason to wait. The combination of fast investigation and pre-built containment playbooks turns one of the most high-value detections into a consistent, effective response.
Frequently asked questions
What is an impossible travel alert?
An impossible travel alert fires when a user account logs in from Location A and then Location B within a time window too short to travel between them physically. For example: a login from New York at 2:00 PM and a login from London at 2:20 PM. Physical travel between these cities takes 7+ hours, so the sequence is impossible if the same person is performing both logins. Identity providers (Entra ID, Okta, Ping, Google Workspace) calculate this using IP geolocation and time difference between authentication events.
What are the most common false positive causes for impossible travel alerts?
VPN and proxy routing is the most common cause: user authenticates from their actual location but their traffic exits through a VPN server in another country, so both the real IP and the VPN IP appear in authentication logs. Cloud application authentication: some SaaS apps authenticate on behalf of users from data center IPs that are geographically inconsistent with the user. Corporate proxy: all office traffic exits through a corporate proxy in a different region, making all users appear to log in from that proxy's location. Content delivery networks: some authentication flows proxy through CDN nodes whose IP geolocations do not match the user's location. Frequent business travelers: executives who fly frequently trigger impossible travel alerts legitimately when catching a connection.
How do I investigate an impossible travel alert in 15 minutes?
Minute 1-5: Pull the sign-in logs for both authentication events. Note the IP addresses, user agent strings (browser version, OS), device IDs, and MFA methods used for each. Minute 5-10: Check whether either IP is a known VPN or proxy (query GreyNoise, IPInfo, or your IP reputation feed for 'VPN' or 'hosting provider' classification). Check whether the device ID matches a known registered device for the user. Call or message the user directly asking whether they are traveling or using a VPN. Minute 10-15: If the user confirms one session and denies the other, it is an active ATO. Proceed to containment immediately.
What evidence do I gather to confirm an account takeover?
Review the post-alert sign-in activity: what did the suspicious session do after authentication? OAuth token grants (new app authorizations), email forwarding rules added, files accessed or downloaded, MFA device registrations, and password changes are the highest-fidelity ATO indicators. Check whether the session bypassed MFA: Entra ID Identity Protection logs the authentication strength. If the legitimate user authenticated with MFA and the suspicious session did not (or used a different MFA method), this indicates credential theft rather than password compromise. Check for inbox rules: email auto-forwarding to external addresses is a common ATO indicator and often shows up in the same time window as the impossible travel event.
What immediate containment steps should I take when I confirm an ATO?
Revoke all active sessions immediately: in Entra ID, run Revoke-AzureADUserAllRefreshToken -ObjectId [userObjectId] or use the 'Revoke sessions' option in the Entra admin center. Reset the password to a new temporary value and force MFA re-enrollment. Block all active OAuth token grants: review and revoke any new app authorizations that appeared in the attack window. Remove any inbox forwarding rules or other persistence the attacker configured. Communicate to the user: explain what happened, provide them a secure channel for password reset, and verify their recovery contact information has not been modified. Collect and preserve all sign-in log data before it expires (Entra ID logs by default are available for 30 days on premium plans).
How do I reduce false positives for impossible travel alerts without missing real ATOs?
Build a named locations list in Entra ID Conditional Access that includes known corporate IP ranges, VPN exit nodes, and trusted proxy IPs. Configure Entra Identity Protection to exclude named locations from risk calculation for the VPN/proxy entries. For frequent travelers, use Entra ID's Trusted Locations feature to include commonly accessed countries as lower-risk. For the Okta environment: configure IP zones with trusted IP ranges and configure the sign-on policy to treat known-IP logins at lower risk. Do not disable impossible travel detection globally, tune it specifically for the false positive sources you identify, and verify tuning has not suppressed genuine detections by reviewing the suppressed events regularly.
What is token theft and how does it cause impossible travel detections?
Token theft occurs when an attacker captures a valid session token (via AiTM phishing, XSS, or man-in-the-browser) and replays it from their own IP address without needing the user's password or MFA. The user authenticates legitimately from Location A (their MFA is satisfied, the token is issued). The attacker uses the stolen token from Location B simultaneously. Both the user and the attacker are using the same account at the same time from different locations, triggering impossible travel. Token theft detections look different from password-based ATOs: the suspicious session has the same authentication strength as the legitimate session (no MFA bypass), because the token was already post-MFA when stolen.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.