Chrome Just Made Your Stolen Cookies Useless to Hackers

You've probably heard the advice "always use multi-factor authentication" so many times it's become background noise. It's good advice. But here's the uncomfortable truth that doesn't get said enough: attackers have a way to walk right past your MFA without ever touching your password or your phone. They steal your cookies.

Google just shipped a fix for that in Chrome, and it's now rolling out to everyone. Let's break down what it does and why it's a bigger deal than it sounds.

What Happened?

Google announced that a security feature called Device Bound Session Credentials (DBSC) is now generally available and rolling out to all Chrome users. It first showed up in beta back in April and was originally announced in 2024, so this is the "okay, it's ready for everyone now" milestone.

The rollout starts with Chrome 146 on Windows, with macOS support coming in a later release. The short version of what it does: even if malware steals your login session from your browser, that stolen session becomes useless on the attacker's machine.

Concepts Explained

Before we go further, let's define a few terms, because the whole story hinges on them.

Session cookie. When you log into a website, you don't re-enter your password on every single page. The site hands your browser a small file called a session cookie that basically says "this person already proved who they are, let them through." Your browser shows that cookie on each request, and the site trusts it.

Bearer token. This is the core problem. A session cookie is what security folks call a bearer token, meaning whoever holds it gets access, no questions asked. Think of a movie ticket. The usher doesn't check that the ticket belongs to you; they just check that you're holding a valid ticket. If someone swipes your ticket, they get into the movie. Session cookies work the same way, which is exactly why attackers want them.

Session hijacking (a.k.a. cookie theft!). This is the attack where someone steals your session cookie and uses it to impersonate you. Because the cookie already represents an authenticated session, the attacker can skip the login screen entirely! No password needed. No MFA prompt. They're in … just like that.

Infostealer malware. This is the delivery mechanism for most cookie theft. Infostealers are a category of malware built to quietly rummage through an infected device and exfiltrate (a fancy word for "secretly send out") valuable data: saved passwords, crypto wallets, and yes, even session cookies straight out of your browser's storage. Malware operations like LummaC2 and Rhadamanthys are well-known names in this space and have gotten very good at it.

TPM and Secure Enclave. These are tiny security chips built into modern computers. Windows machines have a Trusted Platform Module (TPM), and Macs have a Secure Enclave. Their job is to generate and store cryptographic keys in hardware in a way that software (including malware) can't pull them out. That last part is the magic ingredient here.

Why It Matters

For years, the standard attacker playbook for cookie theft has looked like this: get infostealer malware onto a victim's device, scrape the session cookies out of the browser, send them to a server the attacker controls, then load those cookies into their own browser and stroll into the victim's accounts. Because cookies often stay valid for a long time, attackers could sit on stolen sessions and access accounts without ever needing the password.

This is the part worth understanding: MFA doesn't stop this attack. Multi-factor authentication protects the login. But cookie theft happens after login. The attacker isn't logging in; they're reusing a session you already authenticated. It's like locking your front door with three deadbolts then leaving your back door open.

DBSC attacks the problem at its root. When a website starts a device-bound session (logging into your banking app on your laptop for example), your browser asks the TPM or Secure Enclave to generate a unique public/private key pair. The private key stays locked inside the hardware chip on your device and never leaves it. To keep your session alive, Chrome has to periodically prove it still controls that private key. An attacker who steals your cookies doesn't have the private key, can't prove possession, and the stolen cookies expire fast and can't be renewed. The cookie becomes a dead ticket.

Google has been running an earlier version of this across its own services for about a year and reported a measurable drop in session theft for protected sessions. So this isn't theoretical.

What Defenders Would See

If you're working in a SOC (Security Operations Center) or thinking about cookie theft from a defender's seat, here's how this shifts the picture.

Historically, detecting session hijacking has been a reactive game. You'd look for the tell-tale signs after a cookie was already stolen and used: a session suddenly active from a new country, an impossible-travel scenario (logged in from Ohio and Romania eight minutes apart), a known-good session token showing up on an unfamiliar device or with a mismatched user-agent string. You're hunting for the symptoms of a theft that already happened.

DBSC changes the framing from detection to prevention. Google described it as shifting from reactive detection to proactive prevention. In defender terms, you're moving a control further "left," stopping the attack from succeeding rather than catching it after the fact.

It's worth being clear about the limits, though. DBSC only helps on the sites and services that actually implement it on their backend, and only on devices that have a TPM or Secure Enclave. If the hardware isn't there, Chrome quietly falls back to normal cookie behavior. And it doesn't touch the initial infection, the infostealer is still on the machine and still grabbing other things. So from an operations standpoint, DBSC raises the cost of cookie theft significantly, but endpoint detection, malware removal, and good logging all still matter.

Lessons Learned

A few practical takeaways from this one:

Authentication isn't a single moment, it's a session. Most people picture security as "the login." But the session that follows is just as much of a target, and historically a softer one. The most interesting defenses are increasingly about protecting the session, not just the front door.

Bearer tokens are inherently risky. Anything that grants access purely by being held, cookies, API keys, some access tokens, is a theft magnet! The long-term fix is to bind those credentials to something an attacker can't easily copy, like device hardware. DBSC is one concrete example of that broader idea, often called proof of possession.

MFA is necessary but not sufficient. This is worth repeating because it's a common blind spot. MFA is one of the best controls you can deploy, but it protects login, not the session afterward. Understanding what a control actually protects is a core analyst skill.

Hardware-backed keys are quietly powerful. That little TPM chip a lot of people ignore (or grumbled about when Windows 11 required it) is doing real work here. Keys that physically can't leave the chip defeat an entire category of "copy the secret and run" attacks.

Plain English Summary

When you log into a website, your browser gets a cookie that acts like a wristband proving you already got in. The problem is that anyone wearing the wristband gets access, so malware that steals your cookies can impersonate you, no password or MFA required.

Chrome's new DBSC feature ties that wristband to your specific computer using a security chip that hackers can't copy. Steal the cookie now and it's worthless on any other machine, because the thief can't prove they own the matching key locked inside your hardware. It runs automatically in the background, you don't have to set anything up, and it's now rolling out to everyone.

It's not a silver bullet, it only works where websites support it and where your device has the right chip, but it shuts down one of the sneakiest ways attackers slip past modern logins.

Sources & Further Reading:

BleepingComputer – “Google Chrome adds session cookie theft protection for all users”