Thieves are progressively resorting to session encryption to evade extensive MFA implementation. The data provides evidence of this, such as:
- 147,000 token replay assaults were pinpointed by Microsoft in 2023, marking a 111% surge year-over-year (Microsoft).
- Offenses on session tokens are now occurring in similar proportions as password-centric assaults (Google).
Nevertheless, session encryption isn’t a recent strategy – so what modifications have occurred?
Session encryption adopts a novel approach
When recalling the quintessential case of session encryption, we often recollect archaic Man-in-the-Middle (MitM) schemes that involved eavesdropping on insecure local network traffic to seize login details or, more frequently, financial specifics like credit card data. Alternatively, by executing client-side schemes compromising a website, running malevolent JavaScript, and utilizing cross-site scripting (XSS) to filch the person’s session credentials.
Session encryption now exhibits quite a different facade. No longer reliant on networks, contemporary session encryption is an identity-centering assault executed over the internet publicizing attacks on cloud-based applications and amenities.
Although the modality differs, the purposes remain predominantly unchanged: Appropriate genuine session components – cookies, tokens, IDs – to recommence the session from the assailant’s device (an alternate remote device, browser, and location).
Diverging from antiquated session encryption, which frequently falters when confronted with fundamental restrictions like encrypted traffic, VPNs, or MFA, modern session encryption proves to be much more dependable in circumventing traditional defensive deterrents.
It’s pivotal to acknowledge that the circumstances of these assaults have undergone substantial changes. Previously, the intent may have been to pilfer a group of domain credentials utilized for authenticating with the internal Active Directory along with your email and essential business applications; nowadays, the identity expanse has transformed significantly – encompassing tens or hundreds of distinct accounts per user across an extensive range of cloud applications.
Why do infringers aim to pilfer your sessions?
Put succinctly: Hijacking live sessions empowers intruders to elude authentication restraints like MFA. If an existing session can be hijacked, there’s less ambiguity involved – no fussing about transitioning purloined usernames and passwords into an authenticated session.
While theoretically session tokens have a restricted lifespan, in actuality, they can endure for extended durations (usually around 30 days) or even perpetually as long as there’s activity.
As mentioned earlier, there’s much to be gained by malefactors through compromising an identity. Whether it’s an IdP identity like an Okta or Entra account offering SSO access to your downstream applications, ideal! If not, perhaps it’s a valuable application (like Snowflake, perchance?) with access to the majority of your client data. Or maybe it’s a less appealing app, yet equipped with intriguing integrations that can be exploited instead.
It comes as no surprise that identity is being spotlighted as the novel security perimeter, and identity-centered assaults continue to trigger discussion.
Nevertheless, not all methodologies of session encryption are identical, consequently reacting diversely to the impediments they encounter. This generates assorted merits and demerits contingent on the mode adopted by the assailant.
Contrasting session encryption methodologies
To seize a session, the initial step involves appropriating the session cookies linked with an active user session. In contemporaneous terms, two primary methodologies exist:
- Employing contemporary phishing utilities like AitM and BitM.
- Employing utilities targeting browser material such as infostealers.
It’s fundamental to discern that both these methodologies target conventional credential components (e.g., usernames and passwords) in addition to session cookies. Intruders aren’t necessarily opting to target session cookies instead of passwords – rather, the utilities at their disposal accommodate both, broadening the avenues within their reach. If accounts devoid of MFA are singled out (and there are still numerous), passwords will prove sufficient.
Contemporary phishing assaults: AitM and BitM
Contemporary phishing toolkits necessitate the victim to undergo any MFA validations as part of the protocol. Concerning AitM, the utility functions as a proxy, allowing the assailant to intercept all authentication components – including confidentialities like session tokens. BitM advances a step further, duping the victim into controlling the assailant’s browser remotely – simulating the virtual analog of an assailant proffering their laptop to the victim, directing them to login to Okta, and subsequently retrieving their laptop afterward.
Unlike orthodox MitM which is commonly opportunistic, AitM tends to be markedly targeted – as a byproduct of a phishing campaign. While AitM scales more efficiently than conventional MitM assaults (predominantly constrained to a local scope), with AitM, focus naturally gravitates toward accounts linked to a specific application or service contingent on the app you’re simulating or the site you’re impersonating.
Infostealers
Conversely, infostealers typically exhibit less precision than AitM – leaning more towards an impromptu grab-and-run technique. This becomes glaringly apparent when analyzing the common delivery mechanisms for infostealers – through site infections (or plugins), malevolent advertising (malvertising), P2P download platforms, gaming forums, social media ads, public GitHub repositories… the list goes on.
Subsequently, in the sequel of this narrative, we’ll concentrate specifically on infostealers. Several valid justifications underpin this decision when discussing session encryption:
- Infostealers target all session cookies stored in the victim’s browser(s) along with all other preserved data and credentials, thereby endangering more sessions in the aftermath of an infostealer infiltration compared to a more precise AitM attack culminating in the breach of a singular app/service (unless it’s an IdP account employed for SSO to other downstream apps).
- Owing to this, infostealers are considerably flexible. In the contingency where app-level restrictions prevent session interception from reachingreached from the trespasser’s gadget (for example, strict IP locking measures necessitating a specific office IP address that cannot be circumvented using residential proxy networks) you can experiment with other applications. Although more stringent controls are typically applied to your M365 login, they are less likely to be enforced for downstream applications – which can be equally attractive to an attacker. Even if these accounts are generally accessed via SSO, an attacker who seizes the session cookies can still purloin and resume them without needing to authenticate to the IdP account.
Yet aren’t info extractors thwarted by EDR?
Not always. The more advanced EDR solutions will likely identify the bulk of commercial info extractors, but malefactors are continuously evolving, particularly advanced threat groups are known to craft customized or tailored malware packages to evade detection. Hence, it’s an ongoing game of cat and mouse, and there are invariably exceptions that elude detection, or vulnerabilities that can be exploited to bypass them, like this vulnerability in Microsoft Defender SmartScreen, which was recently utilized to distribute info-stealing malware.
Info-stealer infections are commonly linked back to the compromise of unmanaged devices – like in BYOD-supporting environments, or in scenarios involving third-party contractors using their personal equipment. And the majority of past info-stealer breaches have been attributed to personal gadgets. Nevertheless, since browser configurations can be synchronized across devices, a compromise of a personal device can effortlessly lead to the infiltration of corporate credentials:
- The user logs in to their personal Google account on their work tool and saves the configuration.
- The user activates configuration synchronization (this is a straightforward process and encouraged by design) and starts storing company credentials in the in-browser password manager.
- The user logs into their personal gadget and the configuration synchronizes.
- They encounter an info-stealer infection on their personal device.
- All the saved credentials, including the business ones, are appropriated by the malicious software.
Therefore, EDR cannot be solely relied upon to completely mitigate the risk posed by info extractors considering the actuality of how identity assaults operate, and how the personal and corporate identities of your users can intersect in the contemporary workplace.
What about passcodes?
Passcodes are a phishing-resistant authentication measure, indicating they are efficient in deterring AitM and BitM attacks that necessitate the victim to finalize the authentication process to hijack the session. Nevertheless, in the case of info extractors, no authentication is required. The info extractor assault targets the endpoint (as mentioned earlier) while the actions of importing pilfered session cookies into the malefactor’s browser merely restore the existing session without going through the authentication process afresh.
Detecting and retaliating against session hijacking
There are multiple layers of controls that theoretically function to avert session hijacking at the final stages of the attack chain.
Phase 1: Disseminating the malware
The victim must first be enticed to download the info extractor. As mentioned previously, this can transpire in various settings and sometimes not on a corporate gadget with anticipated controls (e.g., email security, content filtering, known-bad blocklisting).
Even when they are in place, they frequently come up short.
Phase 2: Executing the malware
The primary defense against this is your AV/EDR solution, as discussed in the previous section. TL;DR it’s not foolproof.
Phase 3: Identifying unauthorized sessions
Once a malefactor has filched your session cookies, your final opportunity to detect them is when they are employed to seize the session.
For most organizations, the ultimate line of defense will be in-app controls such as access limitation policies. As previously mentioned, it’s often not arduous to bypass IP locking constraints, for instance, unless they are highly restricted – akin to being bound to an exact office IP address. Yet, even then, if the offender cannot access your M365 account, it’s improbable that each of your downstream applications will maintain the same elevated levels of restrictive policy.
Thus, while there is a plausible likelihood that info extractors will be identified and obstructed on business gadgets, it’s not an absolute assurance – and numerous info-stealer assaults will evade them entirely. Regarding detecting and preventing unauthorized sessions, you heavily rely on varying app-level controls – which, once more, are not particularly efficacious.
Video demonstration: Session hijacking in progress
Witness the video demonstration below to observe the attack sequence live from the point of an info-stealer incursion, illustrating session cookie theft, reimporting the cookies into the offender’s browser, and circumventing policy-based controls in M365. It also displays the targeting of downstream applications normally accessed via SSO within the context of both a Microsoft Entra and Okta breach.
Incorporating a new line of defense – the browser
Security professionals are accustomed to leveraging the notion of the Pyramid of Pain in these circumstances. When a detection fails, it commonly revolves around spotting the incorrect type of indicator (i.e., closely connected to a variable that the offender can easily alter).
For the assault to prosper, the offender must resume the victim’s session in their own browser. This is an action, a behavior, that cannot be avoided.
So, what if you could identify whenever an attacker exploits a purloined session token and seizes a session?
The Push Security team has introduced a measure that identifies precisely this. By introducing a distinct marker into the user agent string of sessions that transpire in browsers enrolled in Push. By scrutinizing logs from the IdP, you can spot activity from the same session that both possesses the Push marker and lacks the marker.
This scenario can only transpire when a session is extracted from a browser and maliciously imported into a different browser. As an added benefit, this also serves as a final line of defense against any other form of account takeover attack, wherein an application typically accessed from a browser with the Push plugin installed is abruptly accessed from a different location.
To delve deeper into this feature, explore the release here.
Learn more
Detecting stolen sessions represents just one potent feature designed to furnish a layered defense against account takeover, alongside:
To witness how Push Security’s browser agent thwarts identity attacks firsthand, request a demo with the team today or sign up for a self-service trial.
About Author
