Full Report
Impossible Travel is one of the earliest indicators of user compromise, and it works against any user-centric event that can be tied back to a location. Huntress goes in-depth on this problem, explaining how it works, revealing challenges surrounding it, and offering real-world examples occurring within Microsoft 365.
Analysis Summary
# Best Practices: Impossible Travel Detection
## Overview
Impossible Travel detection is a location-based anomaly detection method used to identify potential account takeovers. It flags instances where a single user identity performs actions in two geographically distant locations within a timeframe that is physically impossible to traverse (e.g., logging in from London and then Tokyo 20 minutes later). These practices address early-stage user compromise and help security teams filter through the noise of modern cloud authentication logs.
## Key Recommendations
### Immediate Actions
1. **Enable Unified Audit Logging:** Ensure the Microsoft 365 Unified Audit Log (UAL) is active to capture `UserLoggedIn` events, which provide the necessary timestamp and IP-based location data.
2. **Audit Credential Sharing:** Issue a policy directive to end "legitimate" credential sharing between employees, as this is a primary driver of false-positive impossible travel alerts.
3. **Identify Known VPNs:** Document and whitelist the IP ranges of corporate VPNs and proxies to reduce initial noise in the detection pipeline.
### Short-term Improvements (1-3 months)
1. **Baseline User Behavior:** Implement a 30-day monitoring period to establish "normal" geographic footprints for each user.
2. **Deploy Velocity Calculations:** Establish a detection pipeline that groups events by User ID and calculates the "implied velocity" (distance between Event A and Event B divided by time elapsed).
3. **Refine Thresholds:** Set a "Travel Velocity" threshold (e.g., 500 mph) that accounts for commercial flight speeds but flags anything faster.
### Long-term Strategy (3+ months)
1. **Integrate Identity Threat Detection and Response (ITDR):** Move beyond simple location checks to include User Agent analysis and Autonomous System (AS) data to identify logins originating from data centers rather than residential ISPs.
2. **Automated Response Orchestration:** Develop playbooks that trigger Conditional Access policies (e.g., forced MFA or account lockout) when a high-confidence Impossible Travel event is detected.
3. **Implement ISPM:** Adopt Identity Security Posture Management (ISPM) to continuously close identity gaps and misconfigurations that allow travel-based bypasses.
## Implementation Guidance
### For Small Organizations
- Focus on built-in Microsoft 365 security reports and "Risky Sign-ins" alerts.
- Manually review alerts that show logins from foreign countries where the business does not operate.
### For Medium Organizations
- Utilize a Managed Detection and Response (MDR) provider to sift through the "100,000 events per hour" noise.
- Focus on `UserLoggedIn` events as they represent successful authentications and higher risk.
### For Large Enterprises
- Build a custom detection pipeline: **Event Pairing -> Velocity Calculation -> Exclusion of Normal Behavior -> Risk Heuristics.**
- Enrich logs with ASN (Autonomous System Number) data to distinguish between a user traveling and an attacker using a VPS (Virtual Private Server).
## Configuration Examples
**The Impossible Travel Logic Pipeline:**
1. **Step 1:** Group `UserLoggedIn` events by `UserPrincipalName`.
2. **Step 2:** Sort by `Timestamp`.
3. **Step 3:** Calculate distance between `Location_A` and `Location_B` (using GeoIP coordinates).
4. **Step 4:** Calculate `Time_Diff`.
5. **Step 5:** If `(Distance / Time_Diff) > 500mph`, flag as "Anomalous."
## Compliance Alignment
- **NIST SP 800-53:** Controls for Monitoring Physical/Logical Location (AC-17).
- **CIS Controls (v8):** Control 6 (Audit Log Management) and Control 13 (Network Monitoring and Defense).
- **ISO/IEC 27001:** Annex A.12.4.1 (Event Logging).
## Common Pitfalls to Avoid
- **Ignoring VPNs:** Failing to account for legitimate corporate or personal VPN use leads to high false-positive rates.
- **Over-reliance on GeoIP:** IP-to-location databases are not 100% accurate; always use "Risk Heuristics" (like User Agent changes) to support the location data.
- **Flat Thresholds:** Not accounting for the "teleportation" effect of cloud-to-cloud service integrations that may use various global data centers.
## Resources
- **Huntress Blog:** [hXXps://www.huntress[.]com/blog]
- **Microsoft 365 Audit Logs:** [hXXps://learn.microsoft[.]com/en-us/purview/audit-log-search]
- **MaxMind GeoIP Tools:** [hXXps://www.maxmind[.]com]
- **Tradecraft Tuesday On-Demand:** [hXXps://www.bigmarker[.]com/99/Time-Travelers-Busted]