Full Report
Google has rolled out Device Bound Session Credentials (DBSC) protection in Chrome 146 for Windows, designed to block info-stealing malware from harvesting session cookies. [...]
Analysis Summary
# Tool/Technique: Device Bound Session Credentials (DBSC)
## Overview
Device Bound Session Credentials (DBSC) is a security protocol implemented in Google Chrome designed to combat session hijacking by cryptographically binding authentication sessions to a specific device's hardware. Its primary purpose is to render stolen session cookies useless to attackers by ensuring that the session can only be refreshed if the specialized hardware security module (TPM) on the original device provides proof of possession of a corresponding private key.
## Technical Details
- **Type**: Security Technique / Defensive Protocol
- **Platform**: Windows (Chrome 146+); macOS (Future release)
- **Capabilities**: Hardware-backed session binding, short-lived cookie issuance, privacy-preserving key generation.
- **First Seen**: Announced in 2024; Rolled out in April 2026 (Chrome 146).
## MITRE ATT&CK Mapping
- **[TA0006 - Credential Access]**
- **[T1539 - Steal Web Session Cookie]**: DBSC is a direct countermeasure to this technique.
- **[TA0001 - Initial Access]**
- **[T1566 - Phishing]**: Limits the impact of phishing by preventing the reuse of harvested session tokens on attacker-controlled machines.
- **[TA0004 - Privilege Escalation]**
- **[T1550.004 - Use Alternate Authentication Material: Web Session Cookie]**: Prevents attackers from using exfiltrated cookies to impersonate users.
## Functionality
### Core Capabilities
- **Hardware Binding**: Utilizes the Trusted Platform Module (TPM) on Windows and Secure Enclave on macOS to generate non-exportable public/private key pairs.
- **Cryptographic Challenge-Response**: Servers issue short-lived session cookies that can only be renewed if the browser proves possession of the private key associated with the specific device.
- **Software-Immune Protection**: Addresses the limitation where software-based browser protections cannot prevent malware with local file/memory access from reading cookies.
### Advanced Features
- **Privacy by Design**: Generates a unique key for each session. This ensures that websites cannot correlate a user's identity across different accounts or different websites using the device identifier.
- **Open Standard**: Developed as an open W3C web standard in collaboration with Microsoft and Okta.
- **Minimal Information Leakage**: The protocol only communicates the per-session public key required for proof of possession, avoiding the transmission of permanent hardware serial numbers.
## Indicators of Compromise
*Note: As DBSC is a defensive mechanism, IOCs listed below relate to the malware families it is designed to block.*
- **Behavioral Indicators**:
- Attempts by unauthorized processes to access Chrome's `Network/Cookies` SQLite database.
- Unexpected API calls to DPAPI (Data Protection API) for cookie decryption.
- High-frequency exfiltration of small `.sqlite` or `.json` files to external C2 nodes.
## Associated Threat Actors
DBSC is specifically designed to mitigate the effectiveness of threat actors using:
- **LummaC2 (Lumma Stealer)**
- **RedLine Stealer**
- **Vidar Stealer**
- **Raccoon Stealer**
## Detection Methods
- **Signature-based detection**: Antivirus/EDR signatures for infostealer variants like LummaC2.
- **Behavioral detection**: Monitoring for "Cookie Harvesting" behavior where a process unrelated to the browser attempts to read browser profile directories (`%LocalAppData%\Google\Chrome\User Data\Default`).
- **Telemetry**: Monitoring for failed "DBSC Refresh" attempts on the server side, which may indicate a stolen cookie is being used from an unauthorized device.
## Mitigation Strategies
- **Browser Updates**: Ensure Google Chrome is updated to version 146 or higher on Windows.
- **Hardware Requirements**: Ensure TPM 2.0 is enabled in the BIOS/UEFI of managed endpoints.
- **Service Provider Adoption**: Web developers and enterprise service providers should implement DBSC registration and refresh endpoints on their backend servers.
- **Endpoint Hardening**: Use AppLocker or Windows Defender Application Control (WDAC) to prevent the execution of untrusted infostealer binaries.
## Related Tools/Techniques
- **Application Bound Encryption (ABE)**: A preceding Chrome feature that encrypted cookies using an app-specific identity.
- **TPM (Trusted Platform Module)**: The underlying hardware component used for key storage.
- **FIDO2 / WebAuthn**: Related hardware-based authentication standards, though DBSC focuses specifically on session persistence rather than initial login.