Attackers are increasingly turning to session hijacking to get around widespread MFA adoption. The data supports this, as:
- 147,000 token replay attacks were detected by Microsoft in 2023, a 111% increase year-over-year (Microsoft).
- Attacks on session cookies now happen in the same order of magnitude as password-based attacks (Google).
But session hijacking isn’t a new technique – so what’s changed?
Session hijacking has a new look
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.
Why do attackers want to steal your sessions?
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.
If you want to know more about the state of identity attacks in the context of SaaS apps, check out this report looking back on 2023/4.
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.
Comparing session hijacking approaches
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:
- Using modern phishing toolkits such as AitM and BitM.
- Using tools that target browser data such as infostealers.
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 attacks: AitM and BitM
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.
We talked about AitM and BitM phishing and how to detect and block it in much more detail in a recent Hacker News article: If you missed it, check it out here.
Infostealers
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:
- Infostealers target all of the session cookies saved in the victim’s browser(s) as well as all the other saved information and credentials, meaning that more sessions are put at-risk as the result of an infostealer compromise compared to a more targeted AitM attack which will only result in the compromise of a single app/service (unless it’s an IdP account used for SSO to other downstream apps).
- Because of this, infostealers are actually quite flexible. In the scenario that there are app-level controls preventing the session from being accessed from the hacker’s device (such as stringent IP locking controls requiring a specific office IP address that can’t be bypassed using residential proxy networks) you can try your hand at other apps. While it’s common for more robust controls on, say, your M365 login, they are less likely to be implemented for downstream apps – which can be just as fruitful for an attacker. Even if these accounts are usually accessed via SSO, the sessions can still be stolen and resumed by an attacker with their hands on the session cookies without needing to authenticate to the IdP account.
But aren’t infostealers blocked by EDR?
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:
- The user logs into their personal Google account on their work device and saves the profile.
- The user enables profile syncing (it’s easy to do and encouraged by design) and begins saving corp creds into the in-browser password manager.
- The user logs into their personal device and the profile syncs.
- They pick up an infostealer infection on their personal device.
- All the saved credentials, including the corp ones, get stolen by the malware.
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.
What about passkeys?
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.
Detecting and responding to session hijacking
There are multiple layers of controls that in theory work to prevent session hijacking at the end of the attack chain.
Stage 1: Delivering the malware
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.
Stage 2: Running the malware
The main control guarding against this is your AV/EDR solution, which we addressed in the previous section. TL;DR it’s not foolproof.
Stage 3: Detecting unauthorized sessions
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.
Video demo: Session hijacking in action
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.
Demo: Session hijacking using stolen cookies
Adding a new line of defense – the browser
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.
Find out more
Detecting stolen sessions is just one powerful feature designed to provide a layered defense against account takeover, alongside:
To see how Push Security’s browser agent stops identity attacks for yourself, request a demo with the team today or sign up for a self-service trial.