Session hijacking is evolving. Attackers now operate the session where it renders – same device, same IP, same user. Here’s why the old detections miss it.
Key takeaways
- Attackers no longer need to steal a session and replay it elsewhere — increasingly, they operate the session where it already exists, on the authenticated device, under the authenticated user.
- Chrome’s App-Bound Encryption and Device Bound Session Credentials made stolen cookies harder to reuse, which pushed attackers to act locally: debugger abuse against live browsers, malicious extensions inside authenticated tabs, AiTM kits capturing sessions at the moment of authentication.
- Identity, network, and endpoint controls each cover a different layer — but none of them can reliably distinguish a user’s click from an attacker’s click inside the same authenticated session. That visibility has to live inside the session itself.
The model we’ve been defending against
For most of the last decade, “session hijacking” meant a specific mechanic. Malware or a malicious extension lifted a cookie off the endpoint. The attacker replayed it from their own infrastructure. Two IPs, two devices, two fingerprints. That model shaped almost everything defenders built to catch it — device posture, geo-velocity, impossible-travel alerts, and, more recently, token-binding proposals meant to tie a session to the device that authenticated it.
None of that was wrong. It described real attacks accurately, and it still catches many of them. What’s changed is that it no longer describes all of them.
What changed: the session started staying put
The emerging problem is session operation: instead of stealing an authenticated session and replaying it somewhere else, the attacker increasingly operates the session where it already exists — on the user’s device, inside the legitimate browser or application, under the user’s authenticated identity.
That changes the defensive problem. The IP may be right. The device may be right. The token may be right. The authentication event may be legitimate. What is wrong is who — or what — is operating the session after authentication.
Two developments are pushing attacks in this direction.
The first is that defenders made stolen artifacts harder to reuse. Chrome shipped App-Bound Encryption in version 127, tying cookie encryption to the application itself on Windows so that user-context malware could no longer just call DPAPI and walk away. Microsoft Edge followed with Application Bound Encryption on by default. Google reported a substantial drop in the specific hijacking class ABE was built to stop, and in 2026 moved Device Bound Session Credentials to general availability on Chrome 146 — binding sessions cryptographically to the device that established them.
The second is that attackers responded exactly the way defenders predicted they would. Google was explicit that the point of binding was never to make sessions less valuable; it was, in their own words, to “force attackers to act locally on the device.” That is happening in the open. Within months of the ABE rollout, Chrome’s own security team reported an increase in attackers abusing Chrome Remote Debugging to extract cookies from the live browser process. In March 2026, Gen Digital documented VoidStealer as the first infostealer observed in the wild using a debugger-based ABE bypass — hardware breakpoints against the running Chrome process, pulling the encryption key straight out of memory. No privilege escalation, no injection. Just conversation with a browser that was already running.
Extensions show the same shift. FreeVPN.One, a verified Chrome extension, quietly accreted permissions and by mid-2025 was silently capturing pages users were already viewing while authenticated. In 2026, Koi found five extensions with more than 500,000 combined installs performing account manipulation inside live VKontakte sessions — subscribing to groups and driving actions from within tabs the user had already logged into.
The AiTM phishing economy sits in the same architectural shift. Microsoft’s Tycoon2FA analysis from March 2026 described a kit that intercepts credentials, MFA challenges, and the resulting session cookies at authentication time — Defender for Office 365 blocked more than 13 million Tycoon2FA-linked emails in October 2025 alone. The attacker isn’t stealing a token to replay from a foreign IP later. They’re standing between the user and the identity provider while the session is being established, and holding onto what they capture with the timing intact.
Scattered Spider (UNC3944) is the same pattern with no malware at all. CrowdStrike observed that in most 2025 incidents it responded to, the group’s initial move was help-desk vishing to trigger password or MFA resets — arriving at authenticated access without a single malicious binary. The FBI/CISA advisory from July 2025 emphasizes the same tradecraft, because from the identity layer the intrusion looks exactly like a normal sign-in.
None of this means classical cookie theft is disappearing — Google wouldn’t have shipped DBSC otherwise. What it means is that the center of gravity is broadening: away from a model in which the artifact leaves the device, toward one where the attacker meets the session where it renders.
Why your detection stack was built for the wrong mode
Identity providers see the authentication event. Continuous Access Evaluation in Microsoft Entra ID and Identity Threat Protection in Okta have both extended useful controls past sign-in — Okta’s documentation now includes a configuration step literally called “Enforce Post Auth Session Monitoring,” and Duo shipped Session Token Theft Protection for its own auth cookies in mid-2025. Duo itself flags the honest limit: their control removes Duo’s authentication cookies from the flow, “although individual applications may still use their own session tokens after authentication.” Identity-layer binding hardens the door. It doesn’t necessarily see what happens inside the room.
Network and SSE layers see traffic shape. The 2026 crop of network-side AI and session inspection — Palo Alto AI Access Security, Zscaler AI Guard, Netskope AI Guardrails — genuinely can inspect prompts and responses semantically now. What they still can’t easily do is distinguish a user’s click from an actor’s click inside the same TLS-terminated session, originating from the same authenticated device on the same known IP. From outside the browser, the operating session and the real one look identical.
EDR sees the process. It catches the infostealer binary if it touches disk. It’s less useful against a legitimate signed browser being driven by a legitimate signed extension after the user has already authenticated.
Each of those layers was built for the mode it’s good at. None was built for the mode where the attacker acts as the authenticated user, on the authenticated device, inside the authenticated session.
The layer that can see the operation
If the attacker is operating the session where it renders, the vantage point that can tell the actor from the user has to be the session itself. What was typed into which form. What was uploaded, and where. Which extensions are driving DOM events on which pages. What an OAuth consent screen actually asked for before the user clicked accept. Whether a sensitive cookie leaving the browser is going somewhere the policy anticipated.
This is not a category invention. Palo Alto/Talon, Seraphic, Island, and LayerX are all now shipping language about “post-authentication” and “active session” protection, which is worth naming plainly: the industry is converging on the same layer. The differentiator is how you get there — specifically, whether that visibility depends on a managed browser, an extension, or something that sits inside the session regardless of which browser or app renders it.
For the class of intrusion this piece is about — the attacker inside the session, doing the work of the user, on the device of the user — the controls that catch it live where the work lives. Not in front of the session. Inside it.
The Monday-morning question
The useful question isn’t “can we detect session hijacking?” It’s mechanical: for the sessions that matter most — the identity provider, the CRM, the source control system, the AI tools — where do the controls actually sit? In front of the session? Around the process? At the identity gate? Or inside the tab, watching the operation?
If the answer to the last one is “nowhere,” that’s the gap. The rest of the stack isn’t wrong. The attackers have just moved on from where it’s looking.
