What is session hijacking?
Session hijacking is the theft and reuse of a valid session token, the artifact that keeps a user logged in after they authenticate. Credential theft targets the inputs to authentication; session hijacking targets its output, so it sidesteps MFA entirely. A stolen password can be stopped by a second factor. A stolen session token has already passed it.
How session hijacking works
After login, the app issues a session cookie — and in SSO environments, a refresh token — that your browser replays on every request so you don’t sign in again. Whoever holds a valid token holds the session. Attackers get them four ways:
- Infostealer malware reads cookies from browser storage and bundles them into stealer logs sold within hours.
- AitM phishing proxies the real login and grabs the cookie after MFA completes.
- OAuth/token theft takes access and refresh tokens for persistent cloud access.
- XSS injects scripts that read tokens off the page.
There’s no failed login, no MFA prompt, no password anomaly. To the application, a hijacked session is just the real user continuing their day.
How do I check if my organization’s session cookies have been stolen?
Run Check Your Exposure to see whether session cookies tied to your domain have been stolen and exposed. Stolen session cookies let attackers resume an authenticated session without a password and without triggering MFA, and SpyCloud surfaces exposed cookies tied to your users.
Why session hijacking matters for enterprises
It’s now the primary way attackers beat MFA, and the standard password-reset response does nothing to a live token. What that means in practice:
- MFA isn’t the backstop you think. SpyCloud recaptured 8.6 billion stolen session cookies in 2025, each one able to bypass MFA and passkeys without ever touching the password.
- One device, dozens of breaches. Each SSO-connected app issues its own session, so a single infection can expose authenticated access across your whole stack.
- Resets don’t revoke sessions. A token stays valid until the app explicitly kills it so remediation has to invalidate sessions, not just rotate passwords.
- The fix is exposure monitoring + auto-invalidation. SpyCloud Session Identity Protection recaptures exposed cookies and refresh tokens and kills them across connected apps before they’re used.
Session hijacking vs. account takeover
The two overlap but aren’t the same, and the distinction changes how you respond:
- Account takeover (ATO) is the outcome – an attacker controlling an account, however they got in.
- Session hijacking is one path to it – skipping the login entirely by reusing a stolen session token, so no credential is ever submitted.
- Why it matters for response: ATO from a stolen password is closed by a reset; ATO via a hijacked session is not, because the token is still valid. Confirming which path was used tells you whether to reset credentials, invalidate sessions, or both.
A stolen session cookie skips the password and MFA entirely.
See whether yours are exposed.
Frequently Asked
Yes. MFA verifies identity at the moment of login. Session hijacking attacks after that point, reusing the token that proves login already happened, so no MFA challenge is ever triggered. A 2025 Microsoft analysis found 80% of MFA-bypass incidents involved session token abuse rather than stolen passwords.
Credential theft targets the username and password used to start authentication; it can be blocked by MFA. Session hijacking targets the session token issued after authentication succeeds, which has already cleared MFA. The two frequently co-occur, because infostealer malware captures passwords and session cookies from the same device at once.
Detection requires signals beyond the login flow: token reuse from unexpected IPs or device fingerprints, impossible-travel session activity, and – most directly – monitoring criminal markets for your organization’s stolen session cookies. Prevention combines short session lifetimes and device-bound tokens with automated invalidation of any session confirmed exposed.