Session hijacking: how attackers steal sessions and how to detect and prevent it

Session hijacking steals valid session tokens to bypass authentication and MFA entirely. Learn how to detect and prevent session hijacking with browser-level controls.

Book a demo

Session hijacking lets attackers bypass authentication and MFA entirely

Session hijacking is the theft and replay of valid session tokens — browser cookies or OAuth tokens — to access an authenticated session without needing the user's password or MFA. The attacker obtains a session token through infostealer malware, AiTM phishing, or malicious browser extensions, then replays it from a different browser.

The application treats the attacker as the authenticated user because the session is already valid. Session hijacking is the post-authentication counterpart to credential theft — while MFA protects the login, it can't protect a session that's already been established.

How session hijacking works

Session hijacking allows attackers to access accounts without going through the login process altogether. Instead of stealing credentials, they steal the session that was created after authentication.

A user logs into an application and receives a session token
The session token is stored in the browser and used to maintain access
The attacker obtains that token through malware or a malicious extension
The token is replayed from another browser or device
The application treats the attacker as an authenticated user

Because the session is already trusted, no password or MFA challenge is required. The attacker inherits the user's access immediately.

Attackers obtain session tokens through infostealer malware, AiTM phishing, and malicious browser extensions. The window between theft and replay can be minutes — infostealers exfiltrate tokens within seconds of execution, and stolen sessions are used or sold almost immediately. Infostealers are the dominant vector, delivered primarily through ClickFix attacks.

Why most security tools fail to detect session hijacking

Session hijacking doesn't involve a login event. From the application's perspective, the session is already authenticated. Most logs show normal activity — requests are valid, authentication has already been completed, and access patterns may look legitimate.

Identity providers detect anomalous logins, not anomalous session usage. Session hijacking doesn't involve a login — the attacker replays an existing session. IdP-based signals like impossible travel and device fingerprinting are probabilistic and miss sophisticated attackers who use residential proxies and headless browsers.

A few platforms offer server-side protections — Microsoft's Token Protection binds refresh tokens to the device TPM, and Continuous Access Evaluation can reject tokens from untrusted locations. But Token Protection doesn't cover browser session cookies, which are the dominant session hijacking vector, and CAE with strict location enforcement requires specific licensing and configuration. Beyond Microsoft, most SaaS applications have no replay detection at all.

If a stolen session token is replayed against Salesforce, Snowflake, Slack, or the hundreds of other apps in a typical enterprise environment, the application accepts it as a valid session. And even where an app does support session revocation, acting on it requires that you're an admin for that specific application, with the right license tier, and that you know the session was stolen in the first place. Across a SaaS estate of hundreds of apps, that level of per-app admin access and detection coverage doesn't exist.

Diagram explaining why traditional security tools cannot detect session hijacking — stolen tokens are replayed after login, with no new authentication event to alert on.

How do you prevent session hijacking?

You can't control session token lifetimes or cookie policies on third-party SaaS applications, so session hijacking defense has to focus on two things: preventing the theft and detecting the replay.

Preventing token theft means stopping the upstream attacks — AiTM phishing that captures tokens through a reverse proxy, ClickFix that delivers infostealer malware, and malicious extensions that exfiltrate cookies through browser APIs. Detecting token replay means identifying when a stolen session is used from a different browser or device after the theft has already occurred. For the third-party applications where session hijacking actually happens, defense shifts to the browser: stop the theft vectors where you can, and detect replay deterministically when you can't.

Push Security dashboard showing tagged browser sessions and an alert detecting stolen session token replay indicative of a session hijacking attempt.

How Push detects and prevents session hijacking

Every session created in a Push-protected browser is tagged with a unique session marker. If that session is subsequently replayed from a different browser or environment, Push detects the mismatch and alerts immediately. Session marker injection is deterministic — a session that originated in a Push browser and appears in a non-Push browser is confirmed stolen.

Push also prevents the upstream theft that leads to session hijacking. Phishing detection catches AiTM attacks before session tokens are captured. ClickFix detection stops infostealer delivery — the primary source of stolen session cookies. Extension monitoring detects malicious browser extensions that exfiltrate cookies through browser APIs.

Frequently asked questions

The theft and replay of a valid session token (browser cookie or OAuth token) to access an authenticated session without needing the user's credentials or MFA. The attacker obtains a token via infostealer malware, AiTM phishing, malicious browser extensions, or cross-site scripting, and replays it from a different browser.

Session hijacking bypasses every authentication control — the attacker never needs the password and never faces an MFA challenge. Push detects session hijacking through session marker injection, providing deterministic stolen-session detection.

A combination of stopping token theft (detecting AiTM phishing, ClickFix infostealer delivery, and malicious extensions) and detecting token replay when it occurs.

Push addresses both. Phishing detection catches AiTM before tokens are stolen. Session marker injection detects when stolen tokens are replayed from uninstrumented browsers. This is a deterministic detection — a session that originated in a Push browser and appears in a non-Push browser has been stolen. Complementary controls include CAE with strict location enforcement and short session lifetimes.

A tool that operates inside the browser session and can deterministically identify when a session token has been stolen and replayed. IdP-based anomaly detection flags suspicious logins probabilistically, but sophisticated attackers use residential proxies to defeat heuristics. Session marker injection provides deterministic detection.

Push injects unique markers into sessions from Push-protected browsers. When a marked session appears in an uninstrumented browser, the theft is confirmed — not suspected.

EDR may detect the infostealer malware that steals cookies — if it triggers behavioral or signature detections. But EDR doesn't detect the token replay: when the attacker uses the stolen cookie in a different browser, there's nothing for EDR to see. The theft and replay are different events at different layers.

EDR also misses session theft via AiTM phishing (captured by the proxy, never touching the endpoint) and via malicious extensions (inside the browser's sandbox). Push complements EDR by detecting both theft mechanisms and replay. Read about EDR blind spots.

Three main vectors: infostealer malware (harvests cookies, credentials, and saved data from the browser's local storage), AiTM phishing (captures session tokens through a reverse proxy during authentication), and malicious browser extensions (API access to cookies, can exfiltrate silently). Infostealers are delivered primarily through ClickFix attacks.

Stolen sessions are sold on dark web marketplaces or used directly for account takeover. Push detects all three theft vectors in the browser and detects replay through session marker injection.

Token Protection binds refresh tokens to the device's TPM, preventing replay from other devices. However, it does not address browser session cookie replay — the dominant session hijacking pattern. Token Protection supports Exchange Online, SharePoint Online, Teams, and certain native client apps, but browsers are not supported.

Its utility is against infostealer malware exfiltrating PRT/refresh tokens from compromised endpoints — a different threat from browser session cookie replay. Push detects browser session hijacking through session marker injection, covering the sessions Token Protection doesn't. Read about Token Protection limitations.

Credential theft steals the user's password — the attacker needs to authenticate, which MFA can block. Session hijacking steals a valid, post-authentication session token — the attacker replays it to access an already-authenticated session, bypassing both password and MFA entirely.

Remediation also differs. After credential theft, reset the password. After session hijacking, the stolen session token must be explicitly revoked — a password reset alone doesn't invalidate it. Push detects both: compromised credential detection catches stolen passwords at login, session marker injection catches replayed tokens. Compare attack types.

Infostealers (commonly delivered via ClickFix) access the browser's local storage files, extract session tokens, and exfiltrate them to attacker-controlled infrastructure — often within seconds. They harvest everything: saved passwords, session cookies, autofill data, cryptocurrency wallets, and extension data.

Stolen sessions are sold on dark web marketplaces or used directly for account takeover. Refresh tokens survive password resets, meaning a single infection can provide persistent access to multiple applications. Push detects the delivery mechanism (ClickFix) and the replay of stolen tokens (session marker injection).

Some help, but effectiveness varies. Continuous Access Evaluation with strict location enforcement rejects tokens from untrusted IPs within seconds. Without strict enforcement, tokens are accepted for up to 28 hours. Compliant Network via Global Secure Access blocks replayed tokens from outside the compliant network.

Token Protection — the control most cited for session hijacking — provides essentially zero protection against browser session cookie replay because browsers aren't supported. Push's session marker injection fills this gap with deterministic detection regardless of the attacker's evasion techniques.

Without browser-level session markers, detecting stolen sessions is extremely difficult. IdP-level signals are probabilistic and miss sophisticated attackers who use residential proxies. Application audit logs may show suspicious behavior after the fact, but the initial access looks like a normal session.

Push's session marker injection generates a confirmed stolen-session alert when a marked session appears in an uninstrumented browser — deterministic, not a heuristic or risk score.

Most breach notification services match email-password pairs without confirming active use. Push eliminates false positives by verifying that the credential is actually being used to authenticate, prioritizing the credentials that represent real, current risk.

Push's dark web credential monitoring surfaces credentials found in infostealer dumps and breach databases — but with behavioral corroboration. Instead of alerting on every match (which generates false positives from stale data), Push confirms whether the compromised credential is actively in use by correlating with observed login behavior. Read about credential monitoring.

Infostealers feed the session hijacking and credential stuffing pipelines. Stolen session cookies enable immediate account takeover without needing passwords or MFA. Stolen credentials are sold on dark web marketplaces for credential stuffing campaigns. Push breaks the chain at multiple points — detecting ClickFix delivery, identifying compromised credentials at login, and detecting stolen session replay.

AiTM phishing steals the session token during authentication — a reverse proxy or human-operated relay sits between the user and the real login page, passing everything through in real time. The user authenticates normally, completes MFA on the real IdP, and the proxy captures the resulting session token as it's issued. The attacker needs the user to visit their phishing infrastructure, and the theft happens at the moment of login.

Session hijacking is broader — the unauthorized replay of any valid session token, regardless of how it was obtained. Infostealers harvest cookies from the browser's local storage after the user has already authenticated. Malicious extensions exfiltrate session cookies silently via browser APIs. Cross-site scripting can expose tokens in vulnerable applications. In all these cases, the session was created legitimately and stolen afterward — no phishing page required.

AiTM is one method that leads to session theft, but they're different attacks at different points in the lifecycle. Push detects AiTM at the phishing page (behavioral detection of reverse proxy signatures) and detects the broader category of session hijacking through marker injection (deterministic detection when a stolen token is replayed from an uninstrumented browser) as well as malware delivery mechanisms like ClickFix and file downloads.