Chrome DBSC Now Protects All Users Against Session Cookie Theft

Google is rolling out Device Bound Session Credentials (DBSC) — a new security mechanism that cryptographically binds browser authentication sessions to a user's physical device using TPM (Trusted Platform Module — a hardware security chip embedded in modern computers and laptops) — to all Chrome users, having first launched the feature in Chrome 146 for Windows in April 2026. DBSC addresses one of the most damaging attack techniques used by infostealer malware (malicious software designed to silently harvest credentials and sensitive data): the theft of session cookies to bypass multi-factor authentication (MFA) and gain persistent access to accounts long after a user has logged out or changed their password.

// 01 Chrome DBSC: Technical Details

The attack that DBSC defends against is known as pass-the-cookie — a technique used extensively by infostealer malware families including LummaC2 (a prominent credential-stealing malware sold as a subscription service to cybercriminals), Redline, Raccoon Stealer, and dozens of others. The attack works as follows:

• Infostealer malware infects the victim's computer (via phishing, malicious downloads, or drive-by compromise)
• The malware reads Chrome's local SQLite database, where session cookies are stored in plaintext after decryption
• Stolen session cookies are exfiltrated to the attacker
• The attacker imports the stolen cookies into their own browser — they are now authenticated to the victim's accounts (email, cloud storage, banking, corporate SaaS) as if they were the legitimate user
• This authentication persists even if the victim changes their password — session cookies are separate from passwords
• This authentication bypasses MFA entirely — the cookie was issued after the victim authenticated with their second factor; the attacker inherits that authenticated state

DBSC breaks this attack chain by introducing a challenge-response mechanism that ties session validity to a cryptographic key stored in the device's TPM hardware:

How DBSC works:

• When Chrome establishes an authenticated session with a DBSC-supporting website, it generates a public/private key pair using the device's TPM
• The public key is registered with the website as part of session establishment
• The TPM-generated private key never leaves the TPM chip — it cannot be exported, copied, or stolen by software
• Periodically, the website issues a cryptographic challenge to the browser, requiring it to sign the challenge with the private key
• Only Chrome on the device with the matching TPM can respond correctly to the challenge
• If an attacker imports the session cookie to their own device, it fails the challenge — the attacker's device has no TPM with the matching private key
• The website invalidates the session, denying the attacker access

DBSC requires implementation on both the browser side (Chrome, now rolling out to all users) and the server side (websites must implement the DBSC protocol to issue challenges). Google has implemented DBSC for its own services (Gmail, Google Workspace, Google Cloud), and the protocol is published as an open standard for other websites to adopt.

// 02 Exploitation Status and Threat Landscape

The timing of DBSC's general availability rollout is directly responsive to the explosion in infostealer-enabled account takeovers over the past two years. LummaC2 (also written as LummaC2 — a malware-as-a-service infostealer available to cybercriminals on a subscription basis starting at approximately $250/month) has been linked to thousands of corporate account compromises through session cookie theft. The pattern — infostealer infection → cookie theft → authenticated access to corporate SaaS, email, and cloud platforms — has become the predominant initial access technique for ransomware gangs and data extortion groups.

The significance of DBSC against MFA bypass cannot be overstated: session cookie theft has been the primary technique by which threat actors defeated MFA — the most widely recommended defensive control of the past decade. If DBSC is universally adopted by both browsers and websites, it would substantially raise the cost of infostealer-based account takeover.

Current limitations:

• Server-side implementation required: DBSC only protects sessions with websites that have implemented the protocol. Google's own services now support it; adoption by third-party services will follow the same slow trajectory as other web security standards
• TPM requirement: Users without a TPM (older hardware, some virtualized environments) do not receive DBSC protection
• macOS expansion pending: The Chrome 148 rollout includes Windows users with DBSC; macOS support is documented as coming in a future Chrome release

// 03 Who Is Affected

Windows Chrome users with TPM hardware gain immediate protection for sessions with DBSC-implementing websites, starting with Google's own services, as Chrome 148 rolls out.

Enterprise users in Google Workspace environments benefit most immediately, as Google has enabled DBSC for Workspace sessions — protecting the corporate email, Drive, and Docs access that are among the highest-value targets for credential thieves.

Infostealer operators face a degraded attack return: stolen cookies from DBSC-protected sessions are now significantly less valuable, as they cannot be "replayed" from a different device.

// 04 What You Should Do Right Now

• Update Chrome to 148+. DBSC is available in Chrome 148 — the same update that patches 151 security vulnerabilities. Update immediately through Help → About Google Chrome.
• Verify TPM is enabled. DBSC requires a functioning TPM. On Windows, check via Device Manager → Security devices → Trusted Platform Module 2.0. If absent, contact your hardware vendor or BIOS settings.
• For web developers and enterprise administrators: review the DBSC specification on GitHub and evaluate implementing server-side DBSC support for your applications. Google has published reference implementations. Adoption by your web properties extends DBSC protection to your users.
• Pair DBSC with hardware security keys. DBSC prevents cookie replay attacks after authentication; hardware security keys (FIDO2/WebAuthn, such as YubiKey) prevent initial authentication bypasses. Together they address the full MFA bypass threat model.
• Continue endpoint protection. DBSC makes stolen cookies less useful — it does not prevent infostealer infection or initial credential theft. Maintain endpoint protection, monitor for infostealer indicators, and address the infection vector (phishing, malicious downloads) independently.

// 05 Background: Understanding the Risk

The session cookie theft attack has thrived because of a fundamental mismatch in the security model: MFA protects the authentication event (the moment of login), but does nothing to protect the authenticated state that persists afterward. Once a user logs in with their password and TOTP code, the resulting session cookie represents authenticated access with no ongoing cryptographic anchor to the legitimate user's device.

DBSC repairs this mismatch by creating an ongoing cryptographic binding between the session and the hardware. It's conceptually similar to how modern encrypted file systems bind data to a specific hardware encryption key — the data (session cookie) becomes meaningless without the hardware (TPM private key).

The broader significance of DBSC is that it represents a fundamental shift in how browser authentication sessions are secured — from stateless shared secrets (cookies) to device-bound cryptographic attestations. If the protocol achieves the adoption of earlier web security standards like HSTS or Content Security Policy — measured in years, not months — it could eliminate pass-the-cookie attacks as a viable attack class.

The open standards approach (DBSC is published as a WICG proposal, not a Google-proprietary protocol) increases the likelihood of cross-browser adoption and broad website implementation over time.

// 06 Conclusion

Chrome's rollout of Device Bound Session Credentials to all Windows users addresses one of the most damaging and widely exploited attack techniques in current cybercrime: session cookie theft by infostealer malware that bypasses MFA entirely. By binding sessions to non-exportable TPM private keys, DBSC ensures that stolen cookies are cryptographically unusable on any other device. Update Chrome to 148+ now to receive this protection, verify TPM availability, and — if you're a web developer — evaluate implementing the DBSC server-side protocol to extend this protection to your application's users.