Thank you for your interest in Obsidian! Please enter your information in the form and we will contact you shortly to schedule a demo.
In a previous blog, we introduced the growing threat of session hijacking and explained just how dangerous and discrete these attacks can be. Today, in the second part of our series, we’ll walk through a demonstration of SaaS session hijacking in detail. Our objective is not only to explain the fundamentals of the attack, but also to show how easily a targeted user might be overlooked and highlight how we detect token compromise in your SaaS environment.
In discussing the various techniques attackers leverage to hijack a session token, we highlighted two prominent methods: malware and phishing via a man-in-the-middle (MITM) attack. Both techniques enable attackers to assume control of an existing, authenticated SaaS session, bypassing MFA and the need for login credentials. CrowdStrike, an Obsidian partner, recently detailed that such techniques were used in one of the biggest nation-state attacks of all time. Crowdstrike researchers found that browser cookies could be stolen using compromised administrative accounts as part of the SolarWinds intrusion.
Today, we’ll look more in depth at the technical aspects of a session hijacking attack:
When an attacker successfully hijacks a session token, they gain access to all resources that it authorizes. These can include a user’s email, shared and personal documents, other applications, and any privileges granted to that individual—which can, in the worst situations, enable administrative actions. Access to internal resources can also facilitate lateral movement throughout the interconnected SaaS environment, opening up opportunities for attackers to launch and maintain full campaigns across the organization. These potentially devastating outcomes are why our team is intent on helping security teams understand, identify, and mitigate session hijacking attacks in your organizations.
One simple approach to set up a MITM attack is to use the architecture shown below:
In this scenario, the user is properly accessing their Microsoft service portal using Azure Active Directory as their identity provider (IDP) and has MFA enabled to protect against compromised login credentials. To get into the middle of this process, the attacker will attempt to insert themselves between the user and IDP.
To set up a demonstration of a simple MITM attack scenario in our own lab, our team uses the following:
With this setup, we deploy the evilginx2 service to our server and develop the phishing messages intended for our test “victims.”
In the most basic MITM scenario, an attacker is able to develop a convincing phishing message to lure the user into clicking a malicious link that then prompts them to log in. For demonstration purposes, we see an unfortunate Microsoft user being fooled by the following phishing email.
The user then clicks the link to check on their account and is presented with a Microsoft login screen that appears legitimate—except the traffic is being proxied through the evilginx2 tool.
Once the user is logged in, they’ll have access to all licensed Microsoft applications along with any connected SaaS applications that use Microsoft as an IDP. In the above example, the user uses Microsoft as the SSO to authorize Salesforce access.
After the user successfully authenticates with the portal presented by the MITM tool, they’re presented with a page whose appearance is entirely authentic. This is because the proxy intercepts both user requests and server responses, relaying traffic between the two entities. Because of this, the SSL encryption remains intact and functions as designed—just not how the user might expect. To the user’s eyes, everything appears to be business as usual.
An attacker is able to intercept a number of sensitive details by proxying the user’s traffic through evilginx2.
These include the user’s IP address, user agent string, login credentials, and most importantly, their session token.
The first two items can help attackers evade detection by mimicking the legitimate user’s approximate location and their exact UAS. But the real crown jewel is the session token. This allows the attacker to authenticate into the user session without ever needing login credentials or an MFA token. In this demonstration, the attacker opens Firefox with the EditThisCookie2 extension installed, grabs the session tokens from the MITM server, navigates to the login portal, and authenticates into the session. From there, the sky’s the limit.
This is a simplistic demonstration of SaaS session hijacking using MITM. Our team has demonstrated these techniques successfully in a number of enterprise environments where various IDP and MFA security measures were enabled. In the wild, session hijacking attacks are typically far more sophisticated than our simulation and part of a complex campaign, as evidenced in the Crowdstrike research above. SaaS session hijacking is often executed discreetly. It’s difficult to detect because attackers reuse legitimate tokens and can establish persistence in connected applications.
Obsidian uses machine learning to identify cases of session hijacking, enabling security teams to mitigate these potentially devastating attacks promptly while simultaneously helping them harden the security posture of their SaaS environment. Our security researchers and detection engineers work collaboratively on a wide variety of account compromise scenarios and the models needed to thwart them. The Obsidian platform identifies suspicious activity across various SaaS services, including session hijacking, to enable your security team to quickly and confidently respond to threats.
For more on session hijacking and our comprehensive approach to SaaS security, check out our lightboard learning series video, presented by our co-founder and CPO Glenn Chisholm.