Defending against Session Hijacking

Multi-factor Authentication (MFA) is very effective at limiting what an adversary can do with a stolen password.

According to research commissioned by Google in 2019, MFA thwarted 99% of automated credential-based attacks and 93% of phishing campaigns. It remains one of the most essential and effective controls against account takeovers.

In some circumstances (outlined below), MFA can be bypassed. Okta’s Cyber Threat Research team has observed the proliferation of malware designed to extract session cookies from the browser of an infected user, and increasing use of phishing techniques designed to bypass authenticators that rely on a shared secret.

Both of these techniques rely on extracting a session cookie from the browser of a legitimate user that has already authenticated to an application.

In this article we will:

• Explain how adversaries steal session cookies,

• Discuss how to defend against session cookie theft, and

• Discuss approaches to detecting abuse of session cookies.

About Session Cookies

Session cookies are small blocks of data stored in a user’s browser after they sign-in to a web application. The cookie includes an identifier generated by the app that helps keep track of a signed-in user, ensuring they won’t need to sign-in again until the session expires or the user logs out.

If an attacker steals a session cookie and injects it into their browser, they can often access the same session as the legitimate user. The two most common techniques used to steal session cookies are:

• Malware infection on a legitimate user’s endpoint, and

• Phishing attacks that use transparent HTTP proxies (adversary-in-the-middle attacks).

Cookie-hungry Malware

Many of the most prevalent malware families observed today include ‘infostealer’ modules that have the ability to extract cookies from browser sessions running on an infected machine. The majority of malware families the US Cybersecurity and Infrastructure Security Agency (CISA) listed in its Top 10 Malware Strains of 2021 report are capable of stealing session cookies.

This malware is often deployed via “cracked” (pirated) games or delivered as malspam. Once installed, these modules silently extract cookies, which are in turn bought and sold in dark web forums, occasionally accompanied by tools that attempt to mimic the browser configuration used by the target.

Adversary-in-the-Middle Attacks

Attackers also use social engineering to obtain session cookies by directing users to a malicious website that is configured as a reverse proxy server. These phishing sites are able to relay requests between a targeted user and an impersonated web application. If a user is tricked into signing in to the legitimate web application via one of these malicious sites, the attacker can access the user’s credentials and the session token returned to the browser.

These attacks can be effective against user accounts protected only by factors that rely on codes sent via SMS, email or authenticator apps.

In any successful attack, the attacker is subject to the constraints of the stolen session: both it's duration and the resources accessible during the session. If the legitimate user logs out (or is logged out by administrators), the session cookie is invalidated.

Defending Against Session Cookie Theft

The advice below is also available to download as an infographic.

Due to the variety of ways session cookies can be stolen, there is no single solution that will prevent their theft. We recommend a “defense in depth” approach to protecting your organization:

• Endpoint protection software can protect user devices against malware that extracts session cookies from the user’s browser. Okta offers integrations with several EDR vendors that allow administrators to deny authentication requests from devices exhibiting poor security hygiene.

• Use strong authenticators such as WebAuthn, U2F keys, smart cards: these offer the strongest resistance to “Adversary-in-the-Middle” attacks. Okta FastPass also offers strong phishing resistance in most deployment scenarios.

• Authentication policies can be used to restrict access to user accounts based on a range of customer-configurable prerequisites. We recommend administrators restrict access to applications to only those devices that are registered (with Okta FastPass) and managed by Endpoint Management tools, and if they are assessed to have a strong security posture. We also recommend forcing re-authentication every time a sensitive resource is accessed.

• Deny or perform step-up authentication on requests to access applications from rarely-used networks. With Okta Network Zones, access can be limited by location, ASN (Autonomous System Number), IP, and IP-Type (which identifies known anonymizing proxies).

• Use Behavior Detection to act (via step-up authentication) or alert (via System Log) when a user’s sign in behavior deviates from a previous pattern of activity.

• Fine-tune application session time-outs based on the risk that unauthorized access to the data poses to the organization. This limits the window available for an attacker to exploit access to stolen session cookies.

• Train users to identify indicators of suspicious emails, phishing sites and common social engineering techniques used by attackers. No matter how advanced the attacker’s infrastructure, most cookie thieves rely on social engineering. Make it easy for users to report potential issues by configuring End User Notifications and Suspicious Activity Reporting.

• Protect administrative sessions: Take a "Zero Standing Privileges" approach to administrative access. Assign administrators Custom Admin Roles with the least permissions required for daily tasks, and require dual authorization for JIT (just-in-time) access to more privileged roles. Apply ASN and IP Session Binding (from Settings > Features) to all administrative apps to prevent the replay of stolen administrative sessions. Enable Protected Actions (under Settings > Features) to force re-authentication whenever an administrative user attempts to perform sensitive actions.

• Talk to your SaaS partners about support for Demonstrating Proof-of-Possession, Continuous Access Evaluation Profile (CAEP) and Universal Logout.

Detecting Abuse of Session Cookies

Application Logs often contain the first signs of cookie theft. Authentication and Access Requests to Okta are logged in Okta System Log, which can be viewed in the admin console, streamed to security analytics tools or programmatically requested using the System Log API.

For more advice on common avenues for detection, we recommend the following resources:

• Telling More Okta Detection Stories with Google Chronicle

• Okta and Splunk Combine to Detect Common Attacks

• Detecting Real-Time Phishing Attacks

When writing detections, try to enumerate the legitimate reasons in your environment why user attributes might change mid-session and alert on anything that remains.

Strongly consider updating incident response playbooks to quickly invalidate active sessions any time a malware infection is detected on an endpoint. Given the prevalence of infostealers in commodity malware campaigns – and considering the relatively minor impact to a user when a session is invalidated – we view this as a pragmatic precaution.

Okta administrators have several tools available for invalidating a session cookie, which in turn invalidates the session. They can clear a user’s sessions in the admin console (People > Select Person > More Actions > Clear User Sessions), via the Okta API or from Workflows.

Okta admins can only invalidate IdP sessions and the sessions of third-party app providers that support Single Log Out as part of their integration with Okta. Ask your SaaS providers about APIs or other features that help alert on a change in user context.

Change Log

1.1 - March 8, 2024

• Updated recommendations to include new features released as part of Okta Secure Identity Commitment: Protected Actions, ASN/IP Session Binding.

1.0 - August 9, 2022

• Original Article Published