What Is Session Hijacking?

What Is Session Hijacking?

Session hijacking is the theft or prediction of a valid session token (opens in new tab), such as a browser cookie or an OAuth access token, to take over a user's authenticated session without that user's credentials.

Credential theft attacks the login; session hijacking reuses the token the application issued after the login succeeded, so the attacker gets in without a password or an MFA prompt.

How session hijacking works

Because HTTP is stateless, applications that keep users logged in issue a session identifier and ask the browser to return it with each request.

That identifier is temporarily equivalent (opens in new tab) to the application's strongest authentication method, including one-time passwords, certificates, and biometrics, and the same logic applies at the API layer, where an OAuth bearer token (opens in new tab) is an opaque string its holder can use to reach protected resources.

A valid bearer token lets its holder act within the session. Once a session cookie moves to another machine, authentication checks no longer confirm the current holder is the employee who received it (opens in new tab). Attackers capture tokens through network sniffing, malware that reads them from disk, a script that exfiltrates them, or a proxy that copies them in transit, and each technique ends with the attacker replaying the token.

A common enterprise variant is AiTM phishing. An employee gets an email linking to a lookalike Microsoft 365 login page on a domain with a valid TLS certificate. The page is a reverse proxy: it forwards the typed password to the real identity provider, relays the genuine MFA challenge back to the employee, and forwards the response.

The identity provider then issues a session cookie to what it believes is the employee's browser, and the proxy keeps a copy. The attacker injects that cookie into their own browser and skips authentication, MFA included (opens in new tab).

The employee lands in the inbox without an obvious warning.

Why session hijacking is hard to stop

Long-lived OAuth tokens and session cookies often stay valid after logout (M-Trends 2026 (opens in new tab)), so replay triggers no new authentication event to alert on, and the technique (MITRE ATT&CK T1550.004 (opens in new tab)) can bypass MFA because authentication already established the session.

MFA protects the authentication event; a stolen token inherits that event's result without repeating it. NIST holds that verifiers should not treat an OAuth access token as presence of the subscriber (opens in new tab) "in the absence of other signals," and refresh tokens often outlive the session that issued them.

Standard incident response also misses the target: password resets alone are insufficient (opens in new tab), so responders must also revoke active session cookies and remove attacker-created inbox rules.

Mass file downloads, new MFA credentials, and forwarding rules are the indicators that usually trigger a response, yet the token theft playbook (opens in new tab) lists them as post-capture behavior, arriving only after the lure and the proxy have already finished their work.

Types of session hijacking attacks

Each technique steals the token from a different place, so defenses must layer:

• Adversary-in-the-middle (AiTM) reverse-proxy phishing. A reverse proxy on a lookalike domain relays the full login, including MFA, and captures the post-MFA session cookie. Reverse-proxy phishing kits (opens in new tab) such as Evilginx2 package the technique.
• Device code phishing. The attacker starts an OAuth device authorization flow, sends the victim the code, and receives access and refresh tokens when the victim approves it on the real identity provider. Storm-2372 campaigns (opens in new tab) escalated this to register attacker-controlled devices in Entra ID and obtain Primary Refresh Tokens.
• OAuth consent phishing. A malicious application requests permissions through a legitimate, provider-hosted (opens in new tab) consent screen, and unsuspecting users approve what looks like a routine request; the resulting tokens provide access until someone revokes them.
• Endpoint and in-browser theft. Malware copies persistent session cookies (opens in new tab) and saved browser passwords from disk that attackers can replay from infostealer logs months later, while injected code or an over-permissioned extension inherits live cookies and sessions inside the browser process (opens in new tab), including malicious Chrome extensions that have targeted enterprise applications.
• Browser-in-the-middle (BitM). The victim interacts with a real browser the attacker controls remotely, so post-login cookies and tokens from those browser-in-the-middle sessions (opens in new tab) land in the attacker's process.
• Cross-site scripting (XSS) and classic network attacks. Injected JavaScript reads document.cookie and exfiltrates the session (opens in new tab), session sniffing captures tokens from plaintext HTTP, and session fixation (opens in new tab) plants a known ID before login. HTTPS adoption has pushed these down the list, but weak session management or unfiltered input still exposes them.

How to defend against session hijacking

Effective defense layers controls across the token, login, device, response, and lure:

• Harden the token. Set session cookies with Secure, HttpOnly, and SameSite, using the __Host- prefix, and regenerate the session ID after login and after any privilege change. For OAuth, bind tokens to the client's key pair with sender-constrained tokens (opens in new tab) and use refresh token rotation (opens in new tab) after each use.
• Deploy phishing-resistant MFA. FIDO2/WebAuthn and passkeys use origin-bound cryptographic authentication, so a fake site can't complete the exchange even after tricking a user into visiting it: FIDO blocks the attempt (opens in new tab). Phishing-resistant authentication (opens in new tab) through FIDO/WebAuthn is widely available, and NIST requires verifiers to offer at least one such option at AAL2 (opens in new tab).
• Bind sessions to devices. With Chrome's Device Bound Session Credentials (opens in new tab) (DBSC), the private key stays in the TPM, so short-lived cookies can't be renewed on a different device; token binding strategies (opens in new tab) apply the same idea to authentication material on supported clients.
• Revoke faster than tokens expire. Microsoft Entra Continuous Access Evaluation (opens in new tab) lets Exchange Online, SharePoint Online, and Teams enforce account disablement, password change, and token revocation quickly. Also bind the session (opens in new tab) to signals such as client IP and User-Agent, and challenge anomalous mid-session changes with step-up re-authentication.
• Disrupt the lure upstream. Phishing-resistant authenticators secure sign-in, but security teams still need controls around token binding and revocation, endpoint security, and attacker infrastructure to close the post-authentication gap: the lookalike domain, the fake consent app, the sponsorship email carrying the infostealer.

This approach stops the attack cycle (opens in new tab) at phase one.

How Doppel helps

Doppel, the Frontier AI-native Social Engineering Defense (SED) platform that unifies Digital Risk Protection (DRP) and Human Risk Management (HRM), works at the upstream layer, dismantling the impersonation domains and login pages that hand an attacker a session before one is ever issued.

Brand Protection detects the lookalike domains and spoofed login pages that host reverse-proxy kits before an AiTM proxy or device code prompt reaches an inbox. The Doppel Threat Graph links each domain to the fake profiles, impersonated ads, and messaging infrastructure running the same campaign, so a takedown reaches the whole operation instead of one page. From there, agentic AI correlates signals, prioritizes campaigns, and executes takedowns at scale, cutting response time and analyst workload.

Request a demo to walk through how the platform maps an impersonation campaign from lure domain to token capture and dismantles it until your brand is too costly to attack.

Frequently asked questions about session hijacking

What is session hijacking?

Session hijacking exploits a web application's session control by stealing or predicting a valid session token and using it to act as the authenticated user. The token can be a browser cookie or an OAuth access or refresh token. Common methods include reverse-proxy phishing that captures the cookie after multi-factor authentication (MFA), malware that copies cookies from the browser's storage on disk, malicious in-browser scripts or extensions, and, in older applications, network sniffing or predictable session IDs. Because the application already trusts the token, the attacker can use it without the password.

What is session hijacking in cybersecurity?

Under NIST's cybersecurity glossary (opens in new tab), session hijacking occurs when an attacker inserts themselves between a claimant and a verifier after a successful authentication exchange. MITRE ATT&CK maps related activity to Steal Web Session Cookie (T1539) (opens in new tab), Use Alternate Authentication Material (T1550.004) (opens in new tab), and Steal Application Access Token (T1528) (opens in new tab). Enterprise examples include AiTM phishing against Microsoft 365, Google Workspace, or Okta; device code phishing that yields OAuth tokens; and infostealer malware that harvests cookies for resale, all sharing the same trait: the attacker uses the user's own trusted session.

What is the difference between session hijacking and account takeover?

Account takeover (ATO) is the outcome, an attacker controlling an account they don't own; session hijacking is one route there, alongside credential stuffing, password spraying, and help desk impersonation. The practical difference shows up in response: a password reset ends an ATO built on a stolen password, but an ATO built on a hijacked session persists until responders revoke the session cookie and any refresh tokens, since those stay valid independently of the password.

What is an example of a session hijacking attack?

The Tycoon 2FA phishing kit (opens in new tab) is a documented example: after a CAPTCHA challenge, victims saw a sign-in page mirroring Microsoft or Gmail branding, and the kit relayed their credentials to the real service, which triggered the genuine MFA challenge and mirrored it back to the victim. Once MFA completed, the kit captured the session cookie and gave the attacker real-time access without further authentication.