SOC teams frequently look to the IP geolocation to determine whether an alert or activity poses a genuine threat. 

However, with the changing threat landscape, relying solely on this information is no longer sufficient. In this blog post, we explain why, drawing insights from our investigations, and offer guidance for a more comprehensive approach.   

The inside scoop:

In February and March of this year, Obsidian’s Threat Research team detected identity compromise across several customer tenants. These alerts shared common characteristics:

• The majority originated from residential IP/ISP spaces.
• They targeted Microsoft Entra ID.
• They were initiated by an outdated Chrome version in their user agent: “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36.”

In one instance, the residential ISP and its IP geolocation matched the user’s typical behavior. This was evident in the user’s high frequency of daily activity, which correlated closely with those specific attributes.

While alerts like this may be dismissed as false positives, several factors prompted our research team to probe further:

• These alerts stemmed from an Obsidian high-fidelity alert with a low false positive ratio.
• The alerts shared the same outdated user agent string.
• The identities involved triggered multiple different alerts.
• A similar pattern emerged across multiple tenants during the period.

Upon further research, we found that most IPs linked to the outdated user agent originated from residential proxy IPs. This discovery coupled with the above findings indicated that these were cases of genuine compromise, giving us a high level of confidence in our assessment. 

We promptly notified our customers and subsequently verified that these incidents were indeed legitimate security breaches. However, it remains unclear whether the residential IP mentioned earlier was deliberately involved in a targeted attack or merely coincidental.

Pay close attention to residential proxies:

Residential proxies serve as intermediary servers between users and websites, akin to VPNs. They help obscure users’ real IP addresses and are readily available for purchase (albeit at a slightly higher price compared to VPN services). Requests routed through residential proxies appear to originate from the residential IP and its associated service provider.

Unlike VPNs that use IPs assigned to infrastructure like AWS or GCP, residential proxies leverage IPs assigned to real individuals through Internet providers. Users worldwide lease their Internet bandwidth and IP to residential proxy providers. The dynamic nature of residential IPs makes them more challenging to identify compared to VPNs. To learn more, read Sekoia’s blog post that offers further insight on residential proxies. 

Activities from residential IPs can blend in with baseline activities in SaaS audit logs, potentially causing confusion and false negatives for automatic threat detection systems and analysts. A meticulously chosen IP whose location mimics that of the victim can even get through strict location-based conditional access policies, and cause a greater degree of confusion to analysts.

In addition to threat actors that are particularly pursuing persistence and stealthiness, some threat actors may resort to using residential proxies instead of VPNs due to organizational enforcement of no-VPN policies, which is a double-edged sword for cyber defenders.

Takeaways:

While abnormal IP geolocation is often a reliable indicator of suspicious activity, it can’t be solely relied upon–particularly since perpetrators frequently use residential proxies to hide their true location. 

When investigating alerts, analysts should adopt an identity-centric approach. This involves examining various signals associated with the identity in question. This includes:  

• Cross-referencing other alerts linked to the same identity.
• Evaluating non-IP geolocation attributes such as device information, access patterns, and access times.
• Consulting threat intelligence databases to check for indications of the use of residential proxies.
• Use multiple detection strategies that cover various stages of the kill chain to help account for detection gaps and false negatives.
• By taking these steps, analysts can more effectively assess the validity of identity alerts and identify potential security threats.

Obsidian’s identity security capabilities are designed to provide users with additional context into these potential false negatives. You can learn more about Obsidian’s approach to threat mitigation here.

Appendix – IoC

User Agent

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

The post Rethinking Identity Threat Detection: Don’t Rely on IP Geolocation appeared first on Obsidian Security.

*** This is a Security Bloggers Network syndicated blog from Obsidian Security authored by Farah Iyer. Read the original post at: https://www.obsidiansecurity.com/blog/rethinking-identity-threat-detection-the-ip-geolocation/