Session hijacking is when an attacker steals the session token your browser holds after you log in, then replays it to take over your account. Because that token is proof of an already-completed login, the attacker skips the password and the multi-factor prompt entirely. They were never asked for either.
This is the part of the attack chain most multi-factor rollouts do not cover. MFA guards the door. The session behind the door runs on a token that any device can present, and that is exactly what gets stolen. For IT managers across Belgium, the Netherlands and the UK, this has moved from edge-case to a routine cause of account takeover and business email compromise.
What is session hijacking?
Session hijacking is the theft and reuse of an active session token, the cookie or bearer token a server issues after a successful login, so an attacker can impersonate the user without re-authenticating. The server accepts the token because its signature is valid, ignoring that it now comes from a different device.
The main routes are:
- Cookie theft via infostealer malware, which copies session cookies straight from the browser on an infected or unmanaged device.
- Adversary-in-the-middle (AiTM) token capture, where a reverse proxy relays a real login and lifts the session cookie after MFA passes.
- Cross-site scripting (XSS), where a malicious script reads a token from a vulnerable web application.
All three end the same way. The attacker holds a valid session and the application has no reason to challenge it again.
Why this is what happens after MFA
Multi-factor authentication validates the login event. It does not validate the session that login produces. Once you pass the prompt, the identity provider issues a token that acts as bearer proof of identity, and that token keeps you logged in so you are not challenged on every click.
That design is the weak point. A bearer token works for whoever presents it. Steal the token and you inherit the authenticated session, password and MFA already satisfied. The check ran once, at the start, and the attacker arrived after it finished.
This is why a password reset does not fix a hijacked session on its own. Resetting credentials changes future logins but does nothing to a token already registered as valid. The attacker keeps access until an administrator explicitly revokes active sessions, which for long-lived refresh tokens can mean days or weeks of standing access.
The scale is not theoretical. According to Verizon’s Data Breach Investigations Report, summarised in Deepstrike’s April 2026 analysis, 86 percent of documented breaches involve compromised identity assets. The same analysis, drawing on Vectra AI telemetry, counted around 1.8 billion credentials harvested from 5.8 million endpoints. Guardz reported in 2026 that session hijacking was the fastest-growing identity attack vector, up 23 percent over 180 days.
How AiTM phishing kits harvest tokens in real time
Adversary-in-the-middle phishing is the technique that turns a normal login into a stolen session. Instead of a static fake page, the attacker runs a reverse proxy between the victim and the genuine identity provider. The victim authenticates against the real service, MFA included, and the proxy captures the session cookie in transit.
The flow is simple from the victim’s side. They click a link, see what looks like the real Microsoft or Google login, type their password, approve the MFA prompt, and reach their actual dashboard. Nothing looks wrong. Behind the scenes, the proxy has already copied the live session and handed it to the attacker, who replays it from their own machine.
Delivery has adapted to slip past email security. QR code phishing, or quishing, hides the link inside an image and pushes the victim onto an unmanaged personal phone where corporate controls do not reach. Push-based MFA fatigue wears the user down until they approve a prompt themselves. Both funnel toward the same outcome: a session the attacker can ride. Obsidian Security has estimated that AiTM reverse-proxy kits sit behind roughly 15 percent of phishing attacks, though that figure comes from a single vendor and is best read as directional.
What actually stops a stolen session
No single control covers this, so it helps to separate two jobs. Prevention stops the token being stolen in the first place. Containment makes a stolen token useless. A mature setup runs both, because each one fails in cases the other catches.
| Defence | Type | Stops a stolen live session? |
|---|---|---|
| FIDO2 / WebAuthn passkeys | Prevention | No. Blocks the AiTM proxy before theft, but does nothing once a token is out |
| Cookie hardening (HttpOnly, Secure, SameSite) | Prevention | Partly. Blocks script-based theft, not infostealer or proxy capture |
| Short access-token lifetimes | Containment | Partly. Shrinks the replay window, does not close it |
| Token binding (sender-constrained tokens) | Containment | Yes. A bound token fails on a device without the matching key |
| Step-up re-authentication | Containment | Partly. Protects sensitive actions, not the whole session |
| Conditional access + device posture | Containment | Yes. Blocks replay from an unmanaged or non-compliant device |
| Continuous evaluation + revocation | Containment | Yes. Cuts the session when context shifts mid-stream |
On the prevention side, FIDO2 and WebAuthn passkeys bind the login to the real domain, so a proxy on a lookalike domain never gets a usable credential. Cookie flags such as HttpOnly and SameSite block scripts from reading tokens, which closes the XSS route but not malware or proxy capture.
Containment is where a hijacked session gets neutralised. Token binding, standardised as OAuth 2.0 DPoP, ties the token to a private key held in the legitimate browser, so a stolen copy cannot be replayed elsewhere. Short token lifetimes force frequent renewal and give the identity provider regular checkpoints to sever a bad session. Step-up re-authentication demands a fresh phishing-resistant check before sensitive actions like changing recovery settings or moving money.
The two controls that matter most for mid-market teams are conditional access tied to continuous device posture. Even with a valid token, access is refused when the request comes from a device the platform does not recognise or one that has drifted out of compliance. A stolen cookie replayed from an attacker’s unmanaged laptop fails that test on arrival.
The real weakness is point-in-time trust
Strip away the individual techniques and one design flaw sits underneath all of them. Traditional access models verify a device and a user once, at login, then trust the session until it expires. During that window the identity provider is blind to what changes.
The endpoint can drift out of compliance after the check passes. A firewall gets switched off, disk encryption is disabled, malware lands. An administrator can revoke a user’s rights, and the live session keeps working anyway. Or a cookie gets stolen and replayed from an unrecognised network, and nothing re-examines it because the one check already succeeded.
Continuous evaluation closes that gap. Rather than a single gate at login, the platform keeps scoring the session against live signals: device state, location, behaviour. The moment a posture signal changes or a session appears from an impossible location, access is cut and the session terminated, ideally across every connected application at once. The exploit window for a hijacked token shrinks from hours to seconds.
This is the honest framing for MFA. It secures the door but not the room behind it, so the answer is to keep checking after login rather than trusting one successful prompt. This is also where a consolidated SASE platform earns its place for a small team. Jimber evaluates device posture continuously and ties conditional access to it, so a hijacked session running from an unmanaged endpoint loses access when the posture mismatch shows, not at the next morning’s sign-in. The same continuous logging produces the access-control evidence that NIS2, DORA and Belgium’s CyberFundamentals framework expect. There is a real caveat worth stating: revocation is not instant, since some applications take time to honour a cut session, which is exactly why device-bound access matters alongside it.
For a fuller treatment of detection after access is granted, see why standalone ZTNA leaves identity exposed, and for the proxy mechanics specifically, how AiTM phishing works and what stops it.
Frequently asked questions
Does multi-factor authentication stop session hijacking?
No. MFA verifies the user only at login. Once that passes, the server issues a session token to keep the user signed in. An attacker who steals that token replays it directly and is never asked for the password or a fresh MFA prompt, because the requirement was already met.
What is the difference between an access token and a refresh token here?
Access tokens are short-lived, usually valid for 60 to 90 minutes, and reach specific resources. Refresh tokens are long-lived and silently mint new access tokens. Stealing a refresh token grants persistent access that can survive a password reset, which is why explicit session revocation matters.
Does resetting the password end a hijacked session?
Not on its own. A password reset changes credentials for future logins but leaves active tokens valid until an administrator explicitly revokes all sessions at the identity provider. Until then, the attacker keeps access through the stolen token.
How does token theft via infostealer differ from AiTM phishing?
Infostealer malware copies cookies from an already-infected device, often unmanaged or personal. AiTM phishing captures the token live during a fake login through a reverse proxy. Vectra AI found 46 percent of corporate infostealer infections originate on BYOD endpoints, outside corporate EDR.
Can device posture checks block a stolen token?
Yes, in most cases. Conditional access tied to continuous device posture refuses a replayed token when it arrives from an unmanaged or non-compliant device. The token may be valid, but it fails the device check, so the session never establishes.
Multi-factor authentication is still worth enforcing. It just is not the finish line. If you want to see how continuous posture scoring and conditional access cut a hijacked session in your own environment, book a Jimber demo and walk the chain through with your team.
