What is session hijacking?
By Identra · Updated
Session hijacking is an attack in which an adversary steals or forges a valid session token, cookie, or other authentication artifact issued after login and uses it to impersonate the authenticated user. Because the token is minted after multi-factor authentication completes, the attacker inherits a fully verified session without ever facing an MFA challenge.
Key numbers
- 146% year-over-year increase in adversary-in-the-middle phishing attacks (Microsoft Entra blog, 2024)
- 276 million infostealer-sourced credentials indexed in 2025 included active session cookies, 31% of all malware-sourced credentials (Recorded Future Identity Threat Landscape Report, 2025)
- Nearly 94 billion stolen browser cookies found circulating on the dark web, with 20.55% still active (NordVPN research, 2025)
How does session hijacking work?
When a user or workload authenticates, the identity provider issues a session artifact: a browser cookie, an OAuth access or refresh token, a SAML assertion, or a JWT. From that moment on, the application trusts the artifact, not the person. Session hijacking targets that artifact directly. The attacker never needs the password, and never needs to answer an MFA prompt, because the artifact is portable proof that authentication already happened.
The theft itself happens through a handful of well-worn channels. Each one ends the same way: the attacker replays the stolen artifact from their own infrastructure and the application treats them as the legitimate, fully authenticated principal.
| Technique | How the session is taken |
|---|---|
| Adversary-in-the-middle (AitM) phishing | A reverse proxy sits between victim and real login page, relays credentials and MFA, and captures the resulting session cookie |
| Infostealer malware | Malware on the endpoint exfiltrates cookies, tokens, and saved credentials straight from browser storage |
| Cross-site scripting (XSS) | Injected script reads session cookies or tokens accessible to the page |
| Session fixation | The attacker plants a known session identifier before login, then rides it after the victim authenticates |
| Malicious browser extensions | An extension with broad permissions reads cookies and tokens across sites |
Why doesn't MFA stop a stolen session?
MFA is a gate on the login event. Once a user passes it, the identity provider mints a token that encodes the outcome, and every subsequent request is judged on that token alone. Steal the token and you inherit the MFA claim baked into it. The application has no reason to re-challenge, because from its point of view the session already proved itself.
This is why session hijacking has become the preferred answer to widespread MFA adoption. Attackers stopped fighting the second factor and started stealing what it produces. Token lifetimes make the problem worse: a refresh token that stays valid for days or weeks gives an attacker a long, quiet window of authenticated access, and many applications never re-evaluate a session after issuance. The stolen artifact keeps working from a new country, a new device, and a new network, because nothing downstream is checking.
What are adversary-in-the-middle kits?
AitM kits industrialized session theft. Tools like Evilginx and phishing-as-a-service platforms such as Tycoon 2FA and Mamba 2FA run a transparent reverse proxy in front of the real login page. The victim sees the genuine sign-in flow, enters real credentials, and approves a real MFA prompt. The proxy forwards everything to the legitimate identity provider and captures the session cookie the provider sends back. The attacker imports that cookie and is signed in, MFA and all.
The economics explain the growth. Kits are rented by subscription, come with hosting and templates, and require no exploit development. Microsoft reported a 146% year-over-year increase in AitM phishing attacks in 2024, evidence that accounts protected by conventional MFA are being compromised through session capture rather than credential guessing. Phishing-resistant methods such as FIDO2 passkeys defeat the proxy at login time because the credential is bound to the real origin, but they do nothing for a session artifact stolen after a legitimate login.
The browser as the theft surface
The browser is where sessions live, which makes it where sessions are stolen. Cookies, tokens, and saved credentials sit in browser storage on the endpoint, and infostealer malware families like RedLine, Lumma, and Vidar are built to harvest them in seconds. NordVPN research in 2025 found nearly 94 billion stolen browser cookies circulating on the dark web, with 20.55% of them still active. Recorded Future indexed 276 million infostealer-sourced credentials in 2025 that included active session cookies, 31% of everything the malware ecosystem captured that year.
A stolen cookie is often more valuable than the password it accompanies. The password may be gated by MFA; the cookie is not. Stealer logs are sold in bulk, sorted by domain, and imported into anti-detect browsers that mimic the victim's fingerprint, so the replayed session looks unremarkable to basic checks. Browser vendors are responding with app-bound encryption and device-bound session credentials, but adoption is uneven and malware authors adapt quickly.
Does session hijacking affect non-human and AI-agent identities?
Yes, and often more severely. Service accounts, CI pipelines, and API integrations hold OAuth tokens and session credentials that tend to be long-lived, broadly scoped, and unwatched. There is no human behind them to notice a suspicious prompt or an unfamiliar device notification, so a hijacked non-human session can run for months.
AI agents raise the stakes again. An agent that browses, calls APIs, or connects to MCP servers accumulates live session material: cookies in its browsing context, bearer tokens in its environment, refresh tokens in its credential store. A prompt-injected or compromised agent can be induced to leak that material, and an attacker who steals an agent's session inherits every permission the agent was delegated. The same post-authentication blind spot that lets a stolen human cookie sail past MFA lets a stolen agent token sail past whatever approval gated the agent's creation.
How do you defend against session hijacking?
No single control closes the gap, because the weakness is structural: authentication is a moment, while a session is a lifetime. Defense means shrinking the value of a stolen artifact and re-checking trust after issuance.
- Bind tokens to the device or TLS channel so a replayed artifact fails off the original machine, using mechanisms like Device Bound Session Credentials and token binding
- Shorten token lifetimes and rotate refresh tokens on every use, so a stolen artifact expires before it is monetized
- Adopt phishing-resistant authentication such as passkeys to shut down AitM capture at login
- Re-evaluate sessions continuously, revoking on signals like impossible travel, new ASN, or fingerprint drift rather than trusting the login event forever
- Harden the endpoint and browser against infostealers and audit extension permissions
- Inventory non-human and agent sessions with the same rigor as human ones, including token scopes, lifetimes, and where session material is stored
How Identra thinks about it
Session hijacking is not a login problem; it is a runtime problem. The industry spent a decade hardening the moment of authentication while leaving everything after it on the honor system, and attackers moved accordingly. Identra treats session artifacts, human cookies, workload tokens, and AI-agent credentials alike, as live identity material to be continuously verified: watching how each session behaves after issuance, detecting replay from infrastructure that does not match the principal, and revoking in real time when a session stops acting like its owner. A token should be a claim that is constantly re-earned, not a key that works until it expires.
Go deeper: The Non-Human Majority
Frequently asked questions
What is the difference between session hijacking and account takeover?
Account takeover is the broader outcome: an attacker controlling a legitimate account by any means, including stolen passwords. Session hijacking is one specific route: stealing the cookie or token minted after login and replaying it. It is especially dangerous because the artifact already encodes a completed MFA check, so the attacker inherits a fully verified session.
Does MFA stop session hijacking?
No. MFA gates the login event, and the session artifact is minted after that gate is passed. Steal the cookie or token and the MFA claim comes with it; the application has no reason to re-challenge. This is why attackers shifted from fighting the second factor to stealing what it produces, through AitM proxies and infostealer malware.
How are session tokens stolen?
The main channels are adversary-in-the-middle phishing proxies that capture cookies during a relayed login, infostealer malware that exfiltrates tokens straight from browser storage, cross-site scripting that reads session material in the page, session fixation, and malicious browser extensions with broad permissions. Stolen cookies are then sold in bulk and replayed from anti-detect browsers.
How do you prevent session hijacking?
Shrink the value of a stolen artifact and re-check trust after issuance: bind tokens to the device or TLS channel, shorten lifetimes and rotate refresh tokens on every use, adopt passkeys to block AitM capture at login, re-evaluate sessions continuously on signals like impossible travel or fingerprint drift, and harden endpoints and browsers against infostealers.