In circumventing widespread Multi-Factor Authentication (MFA) implementation, assailants are increasingly resorting to session hijacking. The statistics support this assertion, evident by:
- Microsoft detecting 147,000 instances of token replay attacks in 2023, marking a 111% annual surge (Microsoft).
- Incidents targeting session cookies now rival the frequency of assaults on passwords (Google).
However, session hijacking is not a novel stratagem – so what has transformed?
Session hijacking has undergone a transformation
Traditional perceptions of session hijacking revolve around antiquated Man-in-the-Middle (MitM) maneuvers involving intercepting unsecured local network communications to seize login details or financial data such as credit card credentials. Alternatively, employing client-side attacks by manipulating a webpage, deploying malevolent JavaScript, and leveraging cross-site scripting (XSS) to extract the victim’s session ID were common tactics.
The contemporary manifestation of session hijacking is markedly distinct. Shifting away from network-centric origins, present-day session hijacking emphasizes identity-based assault conducted across the public internet, targeting cloud-based applications and services.
Although the methodology has evolved, the primary objectives remain consistent: pilfer valid session components – cookies, tokens, IDs – enabling the intruder to resume the session from a remote device (distinct from the victim’s, in a different browser and location).
Unlike outdated session hijacking techniques, commonly thwarted by rudimentary defenses like encrypted traffic, Virtual Private Networks (VPNs), or MFA, the modern iteration is adept at circumventing standard protective mechanisms.
A notable shift in attack context has transpired. Previously, the primary aim was to filch a set of domain credentials facilitating access to internal Active Directories, email accounts, and core business applications. Presently, the landscape of potential targets is more diverse – with each user maintaining numerous accounts across a vast array of cloud-based utilities.
What drives attackers to target your sessions?
Succinctly put: By commandeering active sessions, attackers can sidestep authentication hurdles like MFA. Seizing an ongoing session streamlines the infiltration process, eliminating the need to manipulate purloined usernames and passwords into an authenticated session.
While session tokens possess a finite lifespan in theory, in practice, they often endure for extended durations (typically around 30 days) or indefinitely as long as activity persists.
As aforementioned, compromising an identity can yield substantial gains for an attacker. Whether infiltrating an Identity Provider (IdP) identity like Okta or Entra, furnishing Single Sign-On (SSO) access to downstream applications, or targeting a valuable application like Snowflake housing extensive customer data, the potential exploits are varied. Conversely, a less attractive application may possess exploitable integrations.
The concept of identity as the contemporary security perimeter is increasingly espoused, with identity-driven breaches recurrently making headlines.
It’s paramount to acknowledge that not all session hijacking methodologies are equivalent, leading to varied responses when countermeasures are encountered. Consequently, distinct advantages and disadvantages arise predicated on the assailant’s chosen strategy.
Contrasting Methodologies of Session Hijacking
To execute a session hijack, the initial step entails seizing the session cookies linked to an active user session. In a contemporary context, two primary avenues exist:
- Employing contemporary phishing toolkits such as AitM and BitM.
- Utilizing tools aimed at harvesting browser data like infostealers.
Noteworthy is that both approaches target conventional credential data (e.g., usernames and passwords) alongside session cookies. Intruders are not emphatically opting for session cookie theft over password expropriation – rather, the tools they deploy cater to both, expanding their options. Should accounts lacking MFA be identified (a still prevalent scenario), pilfered passwords serve the purpose adequately.
Contemporary phishing stratagems: AitM and BitM
Modern phishing toolkits prompt victims to undergo any MFA verification during the interaction. AitM acts as a proxy, allowing the attacker to interdict all authentication elements – including confidentialities such as session tokens. BitM elevates this dynamic by coercing the victim to unwittingly take control of the attacker’s browser remotely – akin to the digital equivalent of the attacker passing their device to the victim, requesting them to log into Okta on their behalf, and reclaiming possession post-login.
Diverging from the ad-hoc nature of traditional MitM exploits, AitM tends to be more targeted, originating from a phishing campaign. While AitM exhibits superior scalability compared to erstwhile MitM methods, focused attention is naturally directed towards accounts affiliated with a specific application or service based on the emulated app or impersonated site.
Infostealers
In contrast, infostealers exhibit reduced targeting compared to AitM, embodying a more opportunistic modus operandi. This disparity is conspicuous when scrutinizing the delivery vectors for infostealers – dissemination through infected websites (or plugins), malvertising, peer-to-peer (P2P) download platforms, gaming forums, social media ads, public GitHub repositories, and beyond.
Subsequently, the ensuing discourse will specifically center on infostealers. This focus is justified when discussing session hijacking:
- Infostealers aim to extract all session cookies saved within the victim’s browser(s) along with additional stored credentials and data, expanding the exposure of numerous sessions post-infostealer infiltration in contrast to a more focused AitM assault, which might compromise a single application/service (unless targeting an IdP account instrumental for SSO connections to other downstream services).
- Owing to this adaptive nature, infostealers exhibit considerable flexibility. In circumstances where application-level protections impede session compromise, the…retrieved from the hacker’s system (such as strict IP locking measures necessitating a specific office IP address that cannot be circumvented using residential proxy networks) one can try their luck with alternative applications. Although it is standard to have more robust restrictions in place for, let’s say, your M365 access, they are less likely to be enforced for downstream applications – which can be equally profitable for an intruder. Even when these accounts are typically accessed through SSO, the sessions can still be pilfered and resumed by an attacker in possession of the session cookies without the need to authenticate to the IdP account.
However, do Endpoint Detection and Response solutions block information stealers effectively?
Not necessarily. Advanced EDR solutions will likely identify a majority of off-the-shelf information stealers, but threat actors are continuously devising new strategies, especially sophisticated and well-funded threat groups that design custom or tailored malware packages to evade detection. Hence, it becomes a game of outsmarting each other, and there are always instances that manage to slip through the cracks, or vulnerabilities that can be exploited to bypass them, such as this loophole in Microsoft Defender SmartScreen that was recently utilized to distribute information stealer malware.
Information stealer infections often originate from the compromise of unmanaged devices – for instance, in organizations accommodating BYOD, or in scenarios involving third-party contractors utilizing their personal equipment. The majority of historical information stealer compromises have been linked to personal devices. Nonetheless, since browser profiles can be synchronized across devices, a compromise on a personal device can easily lead to the exposure of corporate credentials:
- The user logs into their personal Google account on their work device and saves the profile.
- The user activates profile synchronization (an effortless and endorsed action by design) and starts storing corporate credentials in the in-browser password manager.
- The user logs into their personal device and the profile synchronizes.
- They unwittingly catch an information stealer infection on their personal device.
- All the stored credentials, including the corporate ones, are snatched by the malware.
Consequently, relying solely on EDR cannot completely eradicate the risk posed by information stealers, considering the actual mechanics of identity attacks and how the personal and corporate identities of your users can converge in the contemporary workspace.
What about passcodes?
Passcodes serve as a phishing-resistant method of authentication, making them effective in thwarting AitM and BitM attacks that necessitate the victim to complete the authentication process before seizing the session. Nonetheless, in the context of information stealers, no authentication process takes place. The modus operandi of an information stealer attack focuses on the device endpoint (refer to the above explanation), while the act of importing purloined session cookies into the assailant’s browser merely resumes the existing session without requiring authentication again.
Identifying and responding to session hijacking incidents
Various layers of controls theoretically function to prevent session hijacking towards the end of the attack cycle.
Phase 1: Disseminating the malware
The target individual must first be enticed to download the information stealer. As mentioned previously, this can occur in numerous scenarios and sometimes not on a corporate device equipped with anticipated controls (e.g., email security, content filtering, known-malicious site blocking).
Even when these controls are in place, they often fall short.
Phase 2: Executing the malware
The primary defense mechanism against this is your AV/EDR solution, as discussed in the preceding section. In summary, it is not foolproof.
Phase 3: Spotting unauthorized sessions
Once an attacker has acquired your session cookies, your last hope of detecting them lies at the moment they are utilized to hijack the session.
For most organizations, the final defense lies in in-app controls like access restriction policies. As mentioned earlier, circumventing IP locking constraints, for instance, is typically not arduous unless they are notably stringent – like being restricted to a specific office’s IP address. Nevertheless, even in such cases, if the intruder cannot reach your M365 account, the likelihood of each downstream app having identical stringent policies is slim.
Therefore, while there is a decent probability that information stealers will be identified and thwarted on corporate devices, it is not a fail-safe guarantee – and numerous information stealer attacks manage to evade them completely. In terms of identification and prevention of unauthorized sessions, the efficacy of app-level controls remains debatable.
Watch a demonstration: Session hijacking visualized
Peruse the video demo below to observe the attack chain in play from the moment of an information stealer compromise, showcasing session cookie theft, re-importing the cookies into the attacker’s browser, and circumventing policy-based controls in M365. It also exhibits the targeting of downstream apps typically accessed through SSO in the context of both a Microsoft Entra and Okta compromise.
Integrating an additional defense layer – the browser
Security experts typically employ the concept of the Pyramid of Pain in these circumstances. Whenever a detection effort fails, it tends to be related to identifying the incorrect indicator type (i.e., it is connected to a variable easily manipulated by the attacker).
For the attack to succeed, the attacker must resume the victim’s session in their own browser. This constitutes an action, a behavior, that cannot be sidestepped.
So, imagine being capable of detecting whenever an attacker leverages a pilfered session token to hijack a session?
The team at Push Security has introduced a control precisely for this purpose. By injecting a unique marker into the user agent string of sessions conducted in browsers enrolled in Push. By scrutinizing logs from the IdP, you can pinpoint activity from the same session that retains the Push marker and activities lacking the marker.
This situation can solely transpire when a session is extracted from a browser and maliciously imported into a diverse browser. Additionally, it serves as a final defense barrier against any form of account takeover attack where an application typically accessed from a browser with the Push plugin installed is suddenly accessed from a different location.
To dive deeper into this feature, explore the release here.
Learn more
Detecting compromised sessions is merely 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 demonstration with the team today or register for a self-service trial.
About Author
