Investigating Geo Impossible Travel Alerts

If you experienced a wave of exhaustion just reading this blog title, then you’re intimately familiar with the woes of triaging location velocity / geo-impossible / or geo-infeasible travel alerts. The premise is simple, it should be inhumanly improbable to travel from the user’s last login geolocation to their current login geolocation over the defined time period. While these types of alerts can identify malicious activity, in practice, the vast majority of them tend to represent legitimate activity that can be cumbersome to investigate. In this blog we’ll cover some of the most common false positive alerts, a general investigative methodology to triage these types of alerts, and some policies you can put in place to reduce the need for this type of signal altogether.

5 common sources of false positives

1. VPN/Proxy usage
Many users leverage VPNs or proxies to secure their internet connection, which can make it appear as though they’re logging in from multiple, geographically dispersed locations.

2. Mobile network fluctuations
Switching between Wi-Fi and cellular networks can cause rapid changes in a user’s IP address, which might trigger these alerts. Even in-flight wifi has been known to trigger this type of false positive. Keep eyes out for ASNs and Organizations associated with mobile networks to quickly prune false positives.

3. Shared account usage
When multiple users share a single account, especially across different regions, geo-impossible alerts are often falsely triggered. Service accounts are notorious for this type of misuse. Minimize this when at all possible in your organization.

4. Content Delivery Networks (CDNs)
CDNs optimize content delivery by routing traffic through various servers around the world. This can make legitimate login attempts appear as though they’re coming from multiple locations.

5. Business travel
Frequent travelers might legitimately log in from different locations within a short time frame, which can easily trigger these alerts. Take a look at the employee information and see if they’re in a role that’s prone to travel frequently.

Investigating these types of alerts (typically 5 - 10 minutes)

Our recommendation to rule out these false positive cases is taking a look at IP enrichment. We've got a preference for Spur for this type of problem since they do an excellent job of identifying VPN / proxy IPs. Evaluate whether the organization is associated with a CDN, Mobile Network, or VPN/Proxy provider to rule out 3 of the 5 most common false positive cases.

The last two are typically done by looking up the user. Service accounts that are shared will generally be easy to spot based on the generalized name not affiliated with an individual. Use your record of truth to identify the user’s role or function and clear the other two common false positive cases.

If the common false positive cases aren’t sticking out or warrant further validation – proceed further in your triage.

1. Look for if multifactor authentication was used. If so, a malicious user would’ve had to hijack the session, have another method of persistence, perform MFA fatigue, or SIM swapped.
   1. Were there multiple attempts for MFA within a 4 hour time period preceding a successful login?
   2. Were there multiple geolocations and devices within the same session?
   3. Were any multifactor methods recently added for this user?
   4. Did the user login with SMS?
      

If none of the above are true, you should be highly confident this isn’t threat related activity. If something was true, you may want to look further.

2. Look at the actions that were performed in the session. Anything resembling establishing persistence or accessing sensitive information? If so, this may warrant further investigation.
   
   
3. Did this user login from a trusted device that’s been previously seen? Is there an MDM or EDR agent on the device? Generally speaking, mobile devices should raise less suspicion than typical workstations. Threat actors rarely use a user’s device to access SaaS applications, so any validation that it’s a managed asset should lower your creep score.

By this point, you should have an understanding of whether it’s worth ringing the fire alarm or resolving the activity as a false positive.

Preventions against impossible travel

As one of the least efficacious signals out of the box for most identity based tools, putting some security controls in place to enhance posture and significantly reduce the alert volume may be worthwhile.

1. Conditional Access Policies
   1. Block logins from countries you don’t actively do business in
   2. Block the use of any anonymous VPN or proxy service from being able to authenticate
2. Require multifactor authentication in your environments
   1. Use “Number Challenge” or similar features to mitigate MFA Fatigue Attacks
   2. Use biometric methods like Okta FastPass when possible for users
   3. Bonus points for using FIDO keys for privileged accounts 
   4. Bonus points for not allowing SMS as a factor
3. Remove shared account usage (to the extent possible) in your environment

As a decades-old problem, triaging and investigating alerts is broken and needs a smarter approach. Let us show you how Prophet AI can streamline your alert triage and investigation, allowing your team to focus on what really matters.

Further reading

What is MFA fatigue attack?
SOC metrics that matter
Top 3 scenarios for auto remediation
Automated incident response: streamlining your SecOps
Key SOC tools every security operations needs
Demystifying SOC automation
Alert triage and investigation in cybersecurity: best practices
SOC analyst challenges vs SOC manager challenges
Alert tuning best practices: keys to reducing false positives
How to investigate Okta alerts
AI SOC: Key to solving persistent SOC challenges
AI SOC Analyst: A comprehensive guide