Session cookie theft after MFA: why passkeys don't fully fix it

Passkeys are the best sign-in most sites can offer. They can't be phished, reused or sprayed, because the key never leaves the user's device and only answers the real site's origin. So why do accounts protected by passkeys and hardware keys still get taken over?

Because sign-in is one moment, and the session that follows lasts days or weeks. After the passkey check, the site hands the browser a session cookie, and from then on that cookie is the user. Anyone who copies it is signed in too, with no password, no code and no passkey prompt. Infostealer malware copies it by the thousand.

What passkeys fixed, and what they never touched

• Fixed: password reuse, credential stuffing, password spraying, and real-time phishing kits. A kit like Tycoon2FA relays your password and MFA code through a look-alike domain, then keeps the cookie the real site sets. A passkey won't sign for the look-alike domain, so that relay fails.
• Not touched: what happens after a successful sign-in. A session cookie is a bearer token. The server checks that it is valid, not which device sent it.

A passkey proves who signed in. A session cookie only proves someone has the cookie.

How the cookie leaves the machine

Step 1: the stealer gets one run

Infostealers arrive as cracked software, fake game mods, malicious ads for real tools, "sponsorship" attachments and, since 2024, fake CAPTCHA pages that ask the visitor to paste a command into the Windows Run box. They don't need to persist. One run is enough.

Step 2: the browser's cookie jar is decrypted and sent out

The stealer reads the browser profile: saved passwords, autofill, crypto wallets and every cookie, then uploads a "log" and often deletes itself. Chrome added App-Bound Encryption in Chrome 127 (2024) to tie cookie decryption to a privileged Chrome service. Stealer families advertised workarounds within months, and in 2026 researchers described VoidStealer pulling the key with a debugger technique, without admin rights. Encryption at rest raises the cost; it doesn't stop code that runs as the user.

Step 3: logs are sold, sorted and replayed

Logs are sold in bulk and searched for valuable domains: cloud consoles, email, ad accounts, payment dashboards, YouTube channels. SpyCloud reported recapturing more than 20 billion cookie records from criminal sources in 2023, around 2,000 per infected device. Markets like Genesis, taken down in April 2023 by an FBI-led operation, sold each victim as a "bot" with cookies and browser fingerprint, plus a browser plug-in that replayed both, so the session looked like it came from the victim's own browser.

Step 4: the attacker is simply signed in

The attacker loads the cookie into their browser and opens the site. No login page, so no MFA prompt, no passkey, and in many apps no new-device email. That is how the Linus Tech Tips YouTube channels were taken over in March 2023: a staff member opened what looked like a sponsorship offer, malware took the browser's session tokens, and the channels were used to stream a crypto scam. Passwords and 2FA were never needed.

The same pattern at bigger names

• Okta, 2023: support-ticket HAR files held live admin session cookies, which were replayed against customers' Okta consoles. Our write-up.
• Snowflake, 2024: years-old infostealer logs supplied the credentials for 165 customers' data warehouses. Our write-up.
• A different source of the cookie or password each time, the same weakness: whatever proves the session is portable.

The fix that is actually arriving: binding the session to the device

Device Bound Session Credentials (DBSC) changes the cookie from a bearer token into something that needs a key the device holds:

1. After sign-in, the site sends a Secure-Session-Registration header.
2. Chrome creates a key pair in the TPM (on Windows), which can't be exported, and registers the public key with the site.
3. The site swaps the long-lived cookie for a short-lived one, minutes rather than weeks.
4. When it expires, Chrome holds the request, signs a challenge from the site with the device key, and gets a fresh cookie.
5. A stolen cookie dies within minutes, and the thief can't refresh it without the TPM key.

Google turned DBSC on for Google accounts in Chrome on Windows from 25 May 2026, rolling out over about 60 days. Any site can adopt it: the protocol is a W3C Working Draft, and open-source server libraries exist (Report URI published one for PHP). Microsoft's equivalent for its own sign-ins is Token Protection in Entra Conditional Access, which binds sign-in tokens to a registered Windows device for selected apps.

What DBSC doesn't do

• Only Chrome supports it today. Other browsers fall back to normal cookies, and Chrome falls back too when the TPM or refresh endpoint fails.
• Malware still running on the device can use the session from that device. Binding forces the attacker to act on the victim's machine, in real time, which is noisier and shorter-lived than reselling a cookie, but it isn't zero.
• It protects the sessions you bind. A site that never sends the header gains nothing.

What a small site can do this month

Make a stolen cookie worth less

• Keep sessions server-side (an ID that points to a row you can delete), not a 30-day signed token you can't revoke.
• Idle and absolute timeouts: shorter for admin and money pages than for a reading app.
• Step-up on sensitive actions: changing the email address, adding a payout account, creating API keys, exporting data. Ask for the passkey or a fresh email code again. A cookie alone shouldn't be enough to take the account away from its owner.
• Rotate the session ID at sign-in and on any privilege change.

Notice when a session moves

• Record a few signals at sign-in: IP network (ASN) and country, user agent, and a device or visitor ID. When a live session shows up with all of them changed, ask for a step-up instead of carrying on.
• Our Fingerprint Lite gives a browser visitor ID you can store at sign-in and compare later. Be realistic: stealer markets ship fingerprints with the cookies, so treat a match as weak evidence and a mismatch as a strong one.
• Limit sign-in and code attempts per email, not only per IP, so a session thief can't easily mint fresh codes. Login Protection does this for osec-powered sign-ins.

Let people end it

• Show active sessions with device and location, and a sign out everywhere button.
• End every session when the password or email changes, or when a user reports a hijack.
• Send a short email when a new device signs in or a sensitive setting changes.

Adopt binding where you can

• If your users are mostly on Chrome for Windows, DBSC is worth a sprint for admin and payment sessions. Start with registration plus a short-lived cookie on one route.
• Keep the step-up and session list anyway: they cover every browser DBSC doesn't.

For people on the other side of the screen

• Don't run cracked software, or anything a web page asks you to paste into Run, Terminal or PowerShell.
• Keep high-value accounts (admin consoles, ad accounts, channels) in a separate browser profile, and sign out when done.
• If a machine ran an infostealer, changing the password isn't enough: sign out all sessions everywhere that offers it.

The lesson

Passkeys closed the front door properly. The session cookie is the window next to it. Until sessions are bound to devices everywhere, assume a cookie can be copied: keep it short-lived, ask again before anything irreversible, watch for sessions that move, and make sign-out mean something.

Sources: Google Workspace Updates: DBSC now generally available in Chrome for Windows (May 2026); Chrome for Developers: Device Bound Session Credentials; W3C: Device Bound Session Credentials (Working Draft); Scott Helme: Everything I learned shipping DBSC (Aug 2026); Microsoft Learn: Token protection in Conditional Access; BleepingComputer: Infostealer malware bypasses Chrome's new cookie-theft defenses; Dark Reading: VoidStealer bypasses Chrome's encryption protection; Security Boulevard: Criminals are easily bypassing passkeys (SpyCloud, 2024); Europol: Takedown of the Genesis Market (April 2023); Gridinsoft: Linus Tech Tips YouTube channel hacked (March 2023).