Attackers are increasingly turning to session hijacking to get around widespread MFA adoption. The data supports this, as:
But session hijacking isn’t a new technique – so what’s changed?
When we think of the classic example of session hijacking, we think of old-school Man-in-the-Middle (MitM) attacks that involved snooping on unsecured local network traffic to capture credentials or, more commonly, financial details like credit card data. Or, by conducting client-side attacks compromising a webpage, running malicious JavaScript and using cross-site scripting (XSS) to steal the victim’s session ID.
Session hijacking looks quite different these days. No longer network-based, modern session hijacking is an identity-based attack performed over the public internet targeting cloud-based apps and services.
While the medium is different, the objectives are largely the same: Steal valid session material – cookies, tokens, IDs – in order to resume the session from the attacker’s device (a different remote device, browser, and location).
Unlike legacy session hijacking, which often fails when faced with basic controls like encrypted traffic, VPNs, or MFA, modern session hijacking is much more reliable in bypassing standard defensive controls.
It’s also worth noting that the context of these attacks has changed a lot. Whereas once upon a time you were probably trying to steal a set of domain credentials used to authenticate to the internal Active Directory as well as your email and core business apps, nowadays the identity surface looks very different – with tens or hundreds of separate accounts per user across a sprawling suite of cloud apps.
In short: Stealing live sessions enables attackers to bypass authentication controls like MFA. If you can hijack an existing session, you have fewer steps to worry about – no messing about with converting stolen usernames and passwords into an authenticated session.
While in theory session tokens have a limited lifetime, in reality, they can remain valid for longer periods (usually around 30 days) or even indefinitely as long as activity is maintained.
As mentioned above, there’s a lot that an attacker can gain from compromising an identity. If it’s an IdP identity like an Okta or Entra account with SSO access to your downstream apps, perfect! If not, well maybe it’s a valuable app (like Snowflake, perhaps?) with access to the bulk of your customer data. Or maybe it’s a less attractive app, but with interesting integrations that can be exploited instead.
It’s no surprise that identity is being talked about as the new security perimeter, and that identity-based attacks continue to hit the headlines.
Not all methods of session hijacking are the same, however, which means that they react differently to the controls they come up against. This creates different pros and cons based on the attacker’s chosen approach.
To hijack a session, you need to first steal the session cookies associated with a live user session. In the modern sense, there are two main approaches to this:
It’s worth noting that both of these methods target both typical credential material (e.g. usernames and passwords) as well as session cookies. Attackers aren’t necessarily making a choice to go after session cookies instead of passwords – rather, the tools they’re using support both, widening the means available to them. If accounts without MFA are identified (and there are still a lot of those) then passwords will do just fine.
Modern phishing toolkits see the victim complete any MFA checks as part of the process. In the case of AitM, the tool acts as a proxy, meaning the attacker can intercept all the authentication material – including secrets such as session tokens. BitM goes one step further and sees the victim tricked into remotely controlling the attacker’s browser – the virtual equivalent of an attacker handing their laptop to their victim, asking them to login to Okta for them, and then taking their laptop back afterward.
Unlike traditional MitM which is often highly opportunistic, AitM tends to be much more targeted – as it’s the product of a phishing campaign. While AitM scales much better than traditional MitM attacks (which were very local) with AitM you’re naturally focused on accounts belonging to a specific application or service based on whatever app you’re emulating, or site you’re impersonating.
On the other hand, infostealers tend to be less targeted than AitM – much more of an opportunistic smash-and-grab. This is particularly evident when looking at the typical delivery mechanisms for infostealers – by infecting websites (or plugins), malicious advertising (malvertising), P2P download sites, gaming forums, social media ads, public GitHub repos… the list goes on.
For the remainder of this article, we’re going to focus on infostealers specifically. There are good reasons for this when talking about session hijacking:
Not necessarily. The better EDRs will probably detect the majority of commercial infostealers, but attackers are continually innovating, and in particular, more sophisticated and well-resourced threat groups are known to develop custom or bespoke malware packages to evade detection. So it’s a cat-and-mouse game and there are always exceptions that slip through the net, or vulnerabilities that can be exploited to get around them, like this flaw in Microsoft Defender SmartScreen, which was recently exploited to deliver infostealer malware.
Infostealer infections are often traced back to the compromise of unmanaged devices – such as in BYOD-supporting organizations, or in the case of third-party contractors using their own equipment. And the majority of historical infostealer compromises have been attributed to personal devices. However, since browser profiles can be synced across devices, a personal device compromise can easily result in the compromise of corporate credentials:
So, EDR can’t be relied upon to eliminate the risk posed by infostealers entirely when considering the reality of how identity attacks work, and how the personal and corporate identities of your users can converge in the modern workplace.
Passkeys are a phishing-resistant authentication control, which means they are effective in preventing AitM and BitM attacks which require the victim to complete the authentication process to be able to hijack the session. However, in the case of infostealers, no authentication takes place. The infostealer attack targets the endpoint (see above) while the action of importing stolen session cookies into the attacker’s browser simply resumes the existing session rather than going through the authentication process again.
There are multiple layers of controls that in theory work to prevent session hijacking at the end of the attack chain.
The victim must first be lured to download the infostealer. As mentioned earlier, this can happen in a lot of different places, and sometimes doesn’t happen on a corporate device with expected controls (e.g. email security, content filtering, known-bad blocklisting).
And even when they are in place, they often fall short.
The main control guarding against this is your AV/EDR solution, which we addressed in the previous section. TL;DR it’s not foolproof.
Once an attacker has stolen your session cookies, the last chance you have to detect them is at the point they are used to hijack the session.
The last line of defense for most organizations will be in-app controls such as access restriction policies. As mentioned earlier, it’s usually not that difficult to bypass IP locking restrictions, for example, unless they’re especially locked down – such as to a specific office’s IP address. Even then, if the attacker can’t access your M365 account, it’s unlikely that each of your downstream apps will have the same levels of restrictive policy in place.
So while there’s a reasonable chance that infostealers will be detected and blocked on corporate devices, it’s not an absolute guarantee – and many infostealer attacks will circumvent them entirely. When it comes to detecting and blocking unauthorized sessions, you’re reliant on variable app-level controls – which again aren’t that effective.
Check out the video demo below to see the attack chain in action from the point of an infostealer compromise, showing session cookie theft, reimporting the cookies into the attacker’s browser, and evading policy-based controls in M365. It also shows the targeting of downstream apps that are usually accessed via SSO in the context of both a Microsoft Entra and Okta compromise.
Security practitioners are used to leveraging the concept of the Pyramid of Pain in these situations. When a detection fails, it’s usually focused on detecting the wrong kind of indicator (i.e. it’s tied to a variable that is easy for the attacker to change).
For the attack to succeed, the attacker must resume the victim’s session in their own browser. This is an action, a behavior, that can’t be avoided.
So, what if you could detect whenever an attacker uses a stolen session token and hijacks a session?
The Push Security team has released a control that detects just this. By injecting a unique marker into the user agent string of sessions that occur in browsers enrolled in Push. By analyzing logs from the IdP, you can identify activity from the same session that both has the Push marker and that lacks the marker.
This can only ever happen when a session is extracted from a browser and maliciously imported into a different browser. As an added benefit, this means it also acts as a last line of defense against any other type of account takeover attack, where an app that is usually accessed from a browser with the Push plugin installed is suddenly accessed from a different location.
To learn more about the feature, check out the release here.
Reference: https://thehackernews.com/2024/09/session-hijacking-20-latest-way-that.html
Our mission is to educate our customer base, build capacity in every country we operate in and make cyber security affordable to all