Pass-the-Cookie: Forensics in the Shadow of Stolen Sessions
07.07.2026 session-hijackinginfostealeraitm-phishingtoken-theft
An employee reports a suspicious email. The sandbox comes back clean, the URL is already dead — case closed, or so it seems. That exact pattern led analysts in a real 2026 incident to miss, for three hours, that the real compromise was already live in the identity plane as a replayed session token and an attacker-created OAuth grant. Session hijacking — or “pass-the-cookie” — has become the dominant initial access vector, and it confronts DFIR practice with a fundamental problem: the classic crime scene, the authentication event itself, often no longer exists forensically.
Why MFA Doesn’t Help Here
Modern web applications maintain authenticated state through bearer tokens — session cookies, OAuth access tokens, refresh tokens. A bearer token proves possession, not identity, so the application accepts it from any device or browser that presents it. That’s precisely why MFA can succeed while the attacker still operates as the victim. Two paths lead to a stolen token: adversary-in-the-middle phishing kits like Tycoon2FA proxy the real login page and capture the token after MFA completes, while infostealers take a different route, direct local extraction, but the outcome is identical: a valid, authenticated session transferred to an attacker who never touched the login page.
The scale is substantial. Recent research found that infostealers processed 51.7 million packages in 2025, a 72% year-over-year increase, and that these packages are particularly lethal because they contain live session cookies that allow adversaries to bypass MFA entirely. Analysts at Cybercheck have documented directly that a closer examination of infostealer logs shows that the cookie folders within a single log can contain active session credentials for dozens of services simultaneously, including Google, Microsoft, and financial platforms, all extracted from one infected device in minutes.
What’s Actually Left at the Crime Scene
The critical distinction from classic credential compromise is timing: MFA is a control on the authentication event, the moment a user proves their identity. Once authentication succeeds, the session token is issued, and MFA has done its job. It has no further role in the session. An attacker with a stolen session token never triggers the authentication event. For investigators, sign-in logs will show what looks like a perfectly legitimate, MFA-compliant authentication — the real indicator of compromise lives elsewhere. Practitioners describe the shift bluntly: detection has to live in sign-in logs, conditional access telemetry, and OAuth grant analysis, because the giveaway is the context around the sign-in, and that is the only place the attack writes evidence.
There’s also a race against retention windows: all of it has to be exported to a SIEM before the 30-to-90-day retention window closes, because the evidence chain disappears on rotation. In follow-on business email compromise scenarios, additional artifacts matter: attackers create inbox rules to hide alerts or auto-forward finance emails, so mailbox configurations should be audited for hidden forwarding rules, malicious OAuth application grants checked, and access logs reviewed to spot mass file downloads from SharePoint or Drive.
Response, Evidence Preservation, and the Limits of Countermeasures
Once suspicion is confirmed, speed matters most: sever the attacker’s access immediately by triggering a “Revoke All Sessions” command to invalidate every active token, then immediately reset the user’s password and audit MFA settings to ensure the attacker hasn’t registered a backup device for persistence. In parallel, evidence must be preserved, since the relevant sign-in logs, audit trails, and mailbox rule configurations are critical for forensic analysis and potential legal proceedings.
Emerging technical countermeasures like Google’s Device Bound Session Credentials (DBSC) help, but only partially. They render stolen cookies useless on managed, modern endpoints, yet organizations that suffered ransomware last year because credentials appeared in stealer logs before the attack would not have been protected by DBSC in most cases — their credentials were harvested from personal devices, contractor laptops, unmanaged endpoints, not from managed Chrome browsers on Windows 11 with TPM 2.0. For DFIR teams, the takeaway is clear: continuous session governance, token monitoring, and treating identity logs as the primary evidence source now matter more than analyzing the original phishing link ever will.
← Back to overview