This blog was co-authored by Obsidian Senior Security Researcher Jody Forness and Machine Learning Engineer Marcus McCurdy.
The security industry can be rife with vendors who tout the advanced machine learning and artificial intelligence capabilities behind their model-based detections. This can make it difficult for customers to discern whether or not these capabilities actually play a major role in the solution—or if they’re really just a small piece. At Obsidian, our security researchers and detection engineers work continuously to develop new models, improve our existing ones, and enable our customers to stay ahead of account compromise threats. Creating accurate, high-fidelity models is at the core of Obsidian’s threat detection solution. Specifically, the Obsidian impossible travel model has played an integral role in identifying malicious activity amidst the noise in SaaS environments.
The impossible travel model represents years of research and development into SaaS architecture and user behavior—there were many iterations, thousands of false positives, and plenty of blood, sweat, and tears. In this article, we’ll shine some light on the development of the Obsidian cross-service impossible travel model and share a recent story where this detection helped one of our customers identify and promptly mitigate a particularly tricky Microsoft compromise in real-time.
Creating Obsidian’s Impossible Travel Model
The concept of “impossible travel,” the detection of two geographically disparate events from a single account, is a great idea whose execution is an absolute nightmare. SaaS environments are riddled with VPNs, weird server configurations, and mobile connections that bounce around. Even Microsoft’s impossible travel detection is triggered mistakenly by activity originating from Microsoft’s own infrastructure!
A successful impossible travel model should do more than just calculate the speed and distance between two different data points—it requires broad historical data from each service across the organization and targeted historical data for each user. This historical data enables the model to create clusters around geographic locations that are typical for individual users and the wider organization: home connections, favorite coffee shops, and office locations, for example.
But what exactly does a “common” location look like when the structure, geographic distribution, and data access patterns vary so wildly across different organizations? Some businesses are geographically disparate with massive presences in specific regions and proportionally smaller presences all over the world. This challenged our team to determine which regions should be clusters and which are just noise. Another common issue we encountered was dealing with users with very limited historical data which wouldn’t serve as a sufficient baseline. The key was pre-qualifying users based on their history in an application: is there enough historical data for this user to create meaningful clusters of activity?
It was important to our team that impossible travel detections were high-fidelity and fired off with as few false positives as possible in order to combat the alert fatigue that has long plagued security teams across the board. This meant being selective about the data we ingested and potentially excluding things like traffic from whitelisted VPNs, traffic that didn’t meet activity thresholds, and clusters that weren’t “dense” enough. After all, our team was looking to eliminate as much noise as possible while still flagging malicious activity. (It’s why at Obsidian, the title of “Machine Learning Engineer” means you’re one of the smartest people I’ve met in my ten years as a security professional!)
In January 2022, we released a new iteration of the impossible travel model that utilized improved frequent location filtering. This was an improvement not only to the underlying model, but to the cross-service compromise detection which baselines user behavior in one SaaS platform in order to detect account takeovers in another. And, sure enough, we were able to identify this exact type of compromise in a customer environment in short order.
Case Study: Mitigating Compromise with Cross-Service Detection
On January 12, 2022, Obsidian triggered a cross-service impossible travel alert in a customer environment which indicated that a user had logged in with a rare IP provided by Frontier Communications, also an unusual ISP for this user and organization. The user agent string came from Firefox, which was divergent from the user’s typical browser of Chrome or Safari.
The customer reached out after their initial investigation and we were able to confirm their suspicion that this was a malicious event. Because Obsidian had sufficient history of this user’s normal behavior in Box, we were able to look across services to identify the connections in Microsoft 365 as aberrant.
So what exactly did we detect? This was an account compromised through a by-the-book phishing attack. Details of the session stood out as immediately suspicious: different user agent strings and an atypical ISP. Activity was further confirmed as malicious when we identified the creation of several mail inbox rules designed to hide the attacker’s original phishing email. Then, we discovered something more sinister—a possible MFA bypass attack.
While the company believed they had multi-factor authentication enabled in Microsoft 365, the attacker was likely able to exploit a little-known basic authentication protocol known as BAV2ROPC which allowed them to use credentials to request an OAuth token. Microsoft issued an advisory about this and has recommended that basic authentication be disabled entirely. Obsidian was able to not only help our customer quickly understand the details and scope of the attack, but also identify the posture deficiencies which were exploited to make it possible.
Obsidian’s work is never done, and we’re working on an OAuth abuse model that would identify similar incidents across connected applications. Until then, a word of advice: stay vigilant and cover your SaaS.