Session hijacking: why a stolen cookie beats a stolen password
A stolen password still has to survive the login form: if the account sits behind multi-factor authentication, the door usually holds. A stolen session cookie is a different object — it is issued after a login has already succeeded, and everything the account does afterwards is authenticated by the cookie alone. That asymmetry explains why session theft has quietly become the preferred path into protected accounts.
The mechanics are simple: on sign-in, the server hands the browser a session cookie, and from that moment every subsequent request is authenticated by the cookie alone. MITRE's entry for technique T1539, Steal Web Session Cookie, notes that these cookies can sit “on disk, in the process memory of the browser, and in network traffic”, and that holding one lets an attacker use the application “as an authenticated user without needing credentials”. The companion technique for reuse, T1550.004, records that a replayed session “bypasses some multi-factor authentication protocols since the session is already authenticated” and that cookies “are often valid for an extended period of time”.Why a cookie beats a password
Three properties make the cookie more valuable than the credential it replaced. It is already past the MFA wall, because the legitimate user presented the second factor when the session was created. Its use generates no failed-login noise — the attacker arrives looking like a normal, authenticated browser. And changing the password does not necessarily end the session. Detection leans on behavior rather than the request itself: MITRE flags cookie reuse “from unusual user agents or locations” and “impossible travel scenarios and anomalous behavior”. State actors work the same seam. MITRE records APT29 stealing Chrome cookies by copying browser profile directories during the SolarWinds compromise and later using a forged duo-sid cookie to bypass MFA, while Star Blizzard used session cookies harvested through an Evilginx-style proxy to reach victim mailboxes. None of this required breaking a cipher or defeating a factor — only a copy of something the browser already holds.AiTM kits proxy the login wall
The industrial version is the adversary-in-the-middle kit. A fake login page that merely harvests a password dies at the second factor. An AiTM site instead proxies the real login: the victim authenticates normally through the attacker's relay, the code is entered, and the kit collects the session cookie issued at the end of the flow. Microsoft documented such a campaign in July 2022, built around office-document and voice-message lures, which it said had affected roughly 10,000 organizations since September 2021 — a campaign designed, in Microsoft's words, to “steal passwords, hijack signed-in sessions (steal session cookies), and perform MFA bypass”. The model now runs as a subscription. In September 2026, BleepingComputer reported on BigBear 2.0, a phishing-as-a-service framework built on Evilginx2 that had bypassed MFA at 258 organizations. A CloudSEK report cited there put the operator panel at 5,137 credential records — including 474 completed MFA-bypassed authentications, 1,032 plaintext passwords and 4,148 session cookies — tied to 3,331 unique victim IP addresses across more than 40 countries. Replays route through residential proxies matched to each victim's country, and the kit's JavaScript interferes with FIDO2/WebAuthn prompts to steer victims toward weaker factors.Stealer logs are cookie inventories
The quieter pipeline is infostealer malware, and its market has visibly pivoted. BleepingComputer's April 2026 report on a stealer marketed as Storm describes a rental panel — $300 for a seven-day demo, up to $1,800 per month for a team tier — whose centerpiece is not a password dump but a cookie-restoration dashboard that rebuilds authenticated sessions server-side:Feed in a Google Refresh Token and a geographically matched SOCKS5 proxy, and the panel silently restores the victim's authenticated session.The researchers behind the report noted that session cookie theft has been replacing password theft as the primary objective of stealer development. That reframes what a stealer log is: less a list of credentials to test than an inventory of doors that are already open, each valid until the session expires.
What actually reduces the risk
The countermeasures are unglamorous, which is part of why they get skipped. They map closely to what Microsoft and MITRE have recommended since the first AiTM waves:- Shorten session lifetimes and delete persistent cookies regularly — MITRE's mitigation note says exactly that. Long-lived “remember me” sessions are this trade's raw material.
- Bind sessions to device or network context: conditional-access rules requiring a managed device make a raw cookie replay fail even when the cookie is genuine.
- Watch for the replay: impossible-travel checks and session-anomaly alerts catch most cookie reuse.
- Move sensitive accounts to phishing-resistant authentication. Hardware-bound passkeys (FIDO2/WebAuthn) are tied to the domain being logged into, so an AiTM proxy cannot relay them — which is why kits like BigBear try to suppress those prompts.
- Log out. Ending a session server-side invalidates the cookie; closing the tab does not.