A stolen session cookie skips your login and your MFA entirely. See how the attack works, what Google's DBSC fixes, and what it still leaves open.
Session cookie theft lets an attacker skip your login entirely. They need no password and no multi-factor code, because a stolen session cookie proves you already passed both. Google’s Device Bound Session Credentials, or DBSC, closes that gap. It ties the cookie to the device that issued it. It is a real improvement, and it does not end the problem.
Session cookie theft starts with an ordinary convenience. After you log in, the site sends your browser a small file that says you are already authenticated. That file is the session cookie. It exists so the site does not ask for your password on every page.
The problem is what that file stands for. It proves a finished login, and it keeps no memory of how that login happened. A password, a hardware key, a passkey, or a fingerprint all end in the same kind of cookie.
So an attacker who copies that file holds the same proof you hold. MITRE catalogues this as stealing web session cookies. Most people call it a pass-the-cookie attack.
MFA protects the login. A session cookie exists after the login.
That single sentence explains why firms with strong MFA still suffer this breach. MFA bypass techniques in modern phishing kits work on the same principle. The attacker never triggers the authentication step, so there is nothing for MFA to challenge. They arrive holding a token that says the challenge already happened.
Infostealer malware turned this into a business. Rather than cracking passwords, many strains scrape cookie files from browser profiles on infected machines, and the stolen sessions get sold. A buyer loads the cookie into their own browser and inherits the session.
Discover how Threatcop protects your workforce from modern cyber threats.
Google made DBSC generally available in Chrome on Windows in 2026, and enabled it by default for Google Workspace users. That announcement covers Chrome on Windows, so confirm what your Mac and other platforms actually support.
Chrome’s own announcement describes the mechanism, and it is simple. When you authenticate, Chrome generates a key pair. It stores the private key in the device’s hardware security chip, the TPM on Windows or the Secure Enclave on macOS. Chrome then binds the session to that key, and proves it still holds the key to keep the session alive.
| Without DBSC | With DBSC |
|---|---|
| Cookie is portable proof of login | Cookie is tied to one device’s hardware |
| Copying the file transfers access | Copying the file transfers nothing usable |
| Attacker replays it anywhere | Replay fails without the private key |
| MFA never re-triggers | Session cannot be revived elsewhere |
The private key never leaves the hardware. So a stolen cookie, loaded on an attacker’s machine, cannot prove possession of the key and the session refuses to resume.
That is a genuine structural fix for one specific attack, which is more than most security features achieve.
Treating DBSC as a solved problem is where firms will get caught.
It does not stop the malware. DBSC beats cookie replay on another machine. It does nothing about the infostealer already running on yours, which can still log keystrokes, capture screens, and steal files.
It does not stop on-device abuse. An attacker with code execution on the victim’s machine is inside the device the session is bound to. The binding is irrelevant to them.
Coverage is partial. It covers supported browsers on supported platforms with the right hardware. Other browsers, older devices, and unsupported sites stay exactly as exposed as before.
Infostealer logs hold more than cookies. Saved passwords, autofill data, crypto wallets, and local files all still sell. Removing one item from the list does not close the shop.
Phishing still works. If an attacker persuades someone to authenticate on a page they control, credential harvesting needs no cookie theft at all. The victim hands over the login directly, and the attacker creates a fresh session on their own terms.
That last point matters most for defenders. DBSC raises the cost of stealing a session. It does not raise the cost of asking someone to log in.
Worth knowing, because the entry points are where defence is still possible.
Infostealer malware is the main route. It arrives through a malicious download, a cracked software bundle, a fake installer, or a ClickFix-style page that asks the user to paste a command. Once running, it reads browser profile directories and ships the contents out.
Malicious browser extensions are the second route. An extension with broad permissions can in some cases reach session tokens directly, and users grant those permissions without much thought.
Reverse-proxy phishing is the third. Rather than stealing a stored cookie, the attacker relays a real login through their own server and captures the session as it is issued. DBSC binding helps here, but only on platforms where it applies.
Notice that all three need a human action first: a download, an install, or a login on the wrong page. That is the layer worth defending, and it is the one security awareness training actually reaches.
As cookie replay gets harder, attackers shift toward getting people to log in for them. That means phishing, reverse-proxy pages that relay a real login, and voice calls walking someone through an approval.
None of those tricks care about hardware binding. They produce a real, properly bound session, made by the real user on the real device, at the attacker’s direction.
Threatcop Security Awareness Training (TSAT) addresses that remaining path. It runs simulations across several attack types, including voice and QR codes alongside email. That matters, because credential-harvesting attempts increasingly arrive outside the inbox. Its Employee Vulnerability Score separates the people who entered credentials from those who only clicked. That difference decides whether a session exists at all. Average breach time then shows how long an attacker would have between the lure and a working login.
DBSC fixes something real, and that is rare. A stolen cookie that fails on another machine is a real loss for the infostealer economy, and switching DBSC on costs most firms nothing. Just do not mistake it for a finished job, and keep fast reporting in place for when something slips through. The malware still runs. The coverage is partial. And the simplest attack of all still works: persuade someone to log in for you. So harden the session, then keep working on the person who creates it.
Session cookie theft is when an attacker copies the file your browser stores after you log in, then loads it into their own browser to take over your session. It needs no password and triggers no multi-factor prompt, because the cookie proves the login already happened.
MFA guards the moment of login. The browser creates a session cookie after that moment, so an attacker holding one never reaches the authentication step. There is nothing for MFA to challenge.
DBSC is a Chrome feature that ties a session cookie to the hardware of the device where you logged in, using the TPM on Windows or Secure Enclave on macOS. The private key never leaves the device, so a copied cookie fails everywhere else.
No. It strips the value from stolen session cookies on another machine. But the malware still runs, still takes saved passwords and files, and still works on the device the session is bound to.
Yes, and arguably more. DBSC makes stealing a session harder, which pushes attackers toward convincing people to log in on pages they control. That creates a real bound session, so the defense has to be the person spotting the lure.
Arpit Rao is a Product Manager at Kratikal, bringing a strong technical foundation and experience in building and managing cybersecurity products. His work spans product strategy, technology, user experience, and solving complex customer challenges. With a focus on translating technical capabilities into practical solutions, Arpit is interested in cybersecurity, AI, product innovation, and user-centric technology. He works on creating products that address evolving security and business needs.
How many days pass between a new attack and training that covers it? Learn to measure security training time...
Security nudges prompt people at the moment of risk. See what 25 million real browser warnings reveal about design,...
Short lessons are not enough on their own. See what two field studies found about microlearning in cybersecurity, and...
