Vercel deploys Device Bound Session Credentials (DBSC) against infostealer session cookie theft

Key facts for Vercel DBSC session binding

Detection coverage for Vercel DBSC session binding

As of 2026-11-04, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-5272 across Splunk SPL, Microsoft KQL and Sigma, covering 13 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Non-Browser Process Reading Chromium Memory - ChromeKatz-Style Session Cookie Theft (Lumma/Vidar/StealC)

Detects a non-browser process opening chrome.exe, msedge.exe or brave.exe with memory-read access rights (Sysmon EventCode 10). This is the ChromeKatz-style in-memory cookie extraction used by Vidar, StealC and Lumma Stealer to bypass Chrome App-Bound Encryption and steal session cookies (T1539). DBSC makes stolen cookies non-replayable off-device but does not stop local theft, so the endpoint behaviour must still be detected.

• Languages: Splunk SPL, Microsoft KQL, Sigma
• ATT&CK: T1539, T1555.003, T1005
• Data sources: sysmon, index=windows XmlWinEventLog:Microsoft-Windows-Sysmon/Operational EventCode 10, DeviceEvents
• Severity: high
• Confidence: high

Splunk SPL

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=10 earliest=-24h (TargetImage="*\\chrome.exe" OR TargetImage="*\\msedge.exe" OR TargetImage="*\\brave.exe") GrantedAccess IN ("0x1010","0x1410","0x1438","0x143a","0x1fffff","0x1f3fff") NOT SourceImage IN ("*\\chrome.exe","*\\msedge.exe","*\\brave.exe","*\\MsMpEng.exe","*\\csrss.exe","*\\WerFault.exe","C:\\Program Files\\Windows Defender\\*","C:\\ProgramData\\Microsoft\\Windows Defender\\*")
| stats count min(_time) as first_seen max(_time) as last_seen values(GrantedAccess) as granted_access values(TargetImage) as browsers_targeted by host SourceImage SourceUser
| convert ctime(first_seen) ctime(last_seen)

Microsoft KQL

DeviceEvents
| where Timestamp > ago(24h)
| where ActionType == 'ReadProcessMemoryApiCall'
| where FileName in~ ('chrome.exe', 'msedge.exe', 'brave.exe')
| where InitiatingProcessFileName !in~ ('chrome.exe', 'msedge.exe', 'brave.exe', 'MsMpEng.exe', 'MsSense.exe', 'csrss.exe', 'WerFault.exe')
| summarize Events = count(), FirstSeen = min(Timestamp), LastSeen = max(Timestamp), TargetBrowsers = make_set(FileName) by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath, InitiatingProcessSHA256, InitiatingProcessAccountName

Sigma

title: Non-Browser Process Reading Chromium Browser Memory (ChromeKatz-Style Cookie Theft)
id: 7c1a3e52-4b8d-4f6a-9c21-5d0e8a1b3f01
status: experimental
description: Detects a non-browser process opening a Chromium-based browser with memory-read access rights, the technique used by ChromeKatz and by Vidar, StealC and Lumma Stealer to extract session cookies and bypass App-Bound Encryption.
references:
    - https://www.bleepingcomputer.com/news/security/infostealer-malware-bypasses-chromes-new-cookie-theft-defenses/
    - https://redcanary.com/blog/threat-intelligence/google-chrome-app-bound-encryption/
author: AII-Detector — ThreadLinqs Intelligence
date: 2026/11/04
tags:
    - attack.credential-access
    - attack.t1539
    - attack.t1555.003
    - attack.collection
    - attack.t1005
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith:
            - '\chrome.exe'
            - '\msedge.exe'
            - '\brave.exe'
        GrantedAccess:
            - '0x1010'
            - '0x1410'
            - '0x1438'
            - '0x143a'
            - '0x1fffff'
            - '0x1f3fff'
    filter_browsers:
        SourceImage|endswith:
            - '\chrome.exe'
            - '\msedge.exe'
            - '\brave.exe'
            - '\csrss.exe'
            - '\WerFault.exe'
    filter_defender:
        SourceImage|startswith:
            - 'C:\Program Files\Windows Defender\'
            - 'C:\ProgramData\Microsoft\Windows Defender\'
    condition: selection and not 1 of filter_*
falsepositives:
    - EDR, AV or DLP agents that inspect browser processes
    - Accessibility, screen-capture or password-manager tooling
level: high

Known false positives:

• EDR, AV or DLP agents that open browser processes with read access
• Accessibility, screen-capture or password-manager software

Tuning notes: Allowlist your EDR/AV agent SourceImage paths after a 7-day baseline. Sysmon must log ProcessAccess for browser targets. Raise priority when SourceImage runs from user-writable paths (AppData, Temp, Downloads) or is unsigned.

• 🔒 Non-Browser Process Accessing Chromium Cookie and Login Data Stores via Command Line · unlock with TL Creds
• 🔒 Browser Profile Archiving - Cookies, Login Data or Local State Packaged for Exfiltration · unlock with TL Creds
• 🔒 Community-Observed Infostealer and Google Phishing Infrastructure Contact (5tr.org, lestvnas.icu, 37.27.4.20) · unlock with TL Creds
• 🔒 Chromium Launched with Remote Debugging for Cookie Extraction over DevTools Protocol · unlock with TL Creds
• 🔒 Compromised Context.ai Google OAuth App Client ID Observed in Workspace Telemetry · unlock with TL Creds
• 🔒 Community-Reported Infostealer File Hash Executed or Written (TL_OSINT_Scan SHA256) · unlock with TL Creds
• 🔒 Chrome/Edge App-Bound Encryption Disabled via Registry Policy (Exela Stealer Behaviour) · unlock with TL Creds
• 🔒 Stolen Session Cookie Replay - Same Session ID from Multiple IPs and Countries (DBSC Gap Hunt) · unlock with TL Creds

Indicators of compromise for Vercel DBSC session binding

As of 2026-11-04, Threadlinqs Intelligence tracks 13 indicators of compromise for TL-2026-5272.

How Vercel DBSC session binding works

Vercel announced (reported by BleepingComputer on 2026-11-04) that it is deploying Device Bound Session Credentials (DBSC) for dashboard logins. At login, Chrome generates a key pair and stores the private key in secure hardware (TPM where available). The session then moves to short-lived cookies that must be periodically renewed by signing a server challenge with the device-bound key; the login response carries a Secure-Session-Registration header that points Chrome at the registration endpoint. A cookie exfiltrated by an infostealer expires within minutes and cannot be refreshed from a different machine. Vercel CTO Malte Ubl said the private key can never be retrieved again, not by Vercel, the user, or malware. Rollout is gradual to address OAuth edge cases and covers Chrome on macOS and Windows. Vercel is also deploying DPoP (Demonstration of Proof-of-Possession) for the Vercel CLI to protect OAuth tokens, a complementary control to DBSC for browser cookies.

The control targets a well-documented attack pattern. Chrome's App-Bound Encryption (introduced in Chrome 127, July 2024) was bypassed by multiple stealer families (Lumma, Vidar, Meduza, Lumar, WhiteSnake, StealC), some by reading cookies from Chromium process memory using ChromeKatz-style techniques and others (Exela Stealer) by manipulating registry policy to disable ABE. Stolen session cookies allow account takeover that bypasses passwords and MFA (MITRE T1539 / T1550.004). Chrome 146 introduced DBSC as the follow-on protection.

Context: Vercel disclosed a security incident on 2026-04-19/20 that began with compromise of the third-party AI tool Context.ai, whose Google Workspace OAuth app was compromised; the attacker took over a Vercel employee's Google Workspace account, then their Vercel account, and enumerated and decrypted non-sensitive environment variables. BleepingComputer reports a threat actor claiming to be ShinyHunters tried to sell allegedly stolen data; Vercel's bulletin does not mention ShinyHunters. Vercel closed the incident on 2026-10-16. The DBSC rollout is a defensive hardening item, not a vulnerability or active campaign: no CVEs, malware hashes or network IOCs are published.

Limitations documented in the W3C editor's draft and Chrome documentation: DBSC does not stop an attacker who is resident on the device and can use the browser session locally; malware present at session registration may extract the key or bind the session to a non-TPM key; it works only over HTTPS, does not support partitioned cookies, and falls back when secure key storage is unavailable. Defenders should treat DBSC as raising the cost of remote cookie replay, keep endpoint infostealer detection, and monitor for sessions that fail to register or refresh binding.

MITRE ATT&CK techniques by tactic:

Collection

T1005 Data from Local System

Initial Access

T1078.004 Valid Accounts: Cloud Accounts; T1199 Trusted Relationship

Credential Access

T1528 Steal Application Access Token; T1539 Steal Web Session Cookie; T1552 Unsecured Credentials; T1555.003 Credentials from Password Stores: Credentials from Web Browsers

lateral-movement

T1550.004 Use Alternate Authentication Material: Web Session Cookie

Lateral Movement

T1550.004 Use Alternate Authentication Material: Web Session Cookie

Remediation for Vercel DBSC session binding

Immediate actions

• Enable MFA (authenticator app or passkeys) on all Vercel accounts
• Rotate non-sensitive environment variables and enable the sensitive environment variables feature
• Review Vercel account activity logs and recent deployments for suspicious activity
• Audit Google Workspace third-party OAuth apps and revoke unrecognized ones, including client ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Workarounds

• Set Deployment Protection to Standard at minimum and rotate Deployment Protection tokens
• Keep Chrome updated so App-Bound Encryption and DBSC protections are present

Longer-term hardening

• Use Chrome on Windows or macOS with DBSC-capable TPM hardware for Vercel sessions as rollout reaches your account
• Keep endpoint infostealer detection and browser-credential-access monitoring in place, since DBSC does not stop local malware
• Adopt DPoP/sender-constrained tokens for CLI and OAuth workflows where supported

Affected and fixed versions

• Vercel — Vercel dashboard sessions and Vercel CLI
  Vulnerable versions: Sessions without device binding (browsers other than Chrome on macOS/Windows during gradual rollout)
  Fixed in: DBSC-bound sessions in Chrome on macOS and Windows; DPoP for Vercel CLI
• Google — Chrome
  Vulnerable versions: Pre-DBSC session cookies protected only by App-Bound Encryption (Chrome 127+)
  Fixed in: Chrome 146+ with DBSC support

Timeline of Vercel DBSC session binding

• 2024-07-23 Chrome 127 releases App-Bound Encryption to protect cookies and credentials from infostealers on Windows
• 2024-09-15 Mid-September 2024: developers of Lumma, locked-ioc-13, Meduza, Lumar and locked-ioc-9 stealers announce versions that bypass App-Bound Encryption (day approximated from 'mid-September' reporting)
• 2026-04-19 locked-ioc-11 publishes its security incident bulletin with the locked-ioc-8-related Google OAuth app client ID as an IOC
• 2026-04-20 locked-ioc-11 discloses unauthorized access to internal systems originating from compromise of third-party AI tool locked-ioc-8 and an employee's Google Workspace account
• 2026-04-22 locked-ioc-11 publishes investigation findings; attacker enumerated and decrypted non-sensitive environment variables
• 2026-09-08 W3C WebAppSec publishes DBSC Editor's Draft with malware cookie-exfiltration threat model and stated limitations
• 2026-10-16 locked-ioc-11 marks all remediation actions complete and closes the April 2026 incident
• 2026-11-04 BleepingComputer reports locked-ioc-11 rolling out DBSC (Chrome on macOS and Windows, gradual) and DPoP for the locked-ioc-11 CLI

Sources cited for Vercel DBSC session binding

• Vercel April 2026 security incident (bulletin) vercel.com · Vendor report · 2026-04-19
• Device Bound Session Credentials (DBSC) - Chrome for Developers developer.chrome.com · Vendor report
• Device Bound Session Credentials - W3C WebAppSec editor's draft w3c.github.io · Research · 2026-09-08
• Google Chrome App-Bound Encryption - Red Canary redcanary.com · Research
• FIDO Alliance white paper: DBSC and DPoP as complementary technologies to FIDO authentication fidoalliance.org · Research
• Hackers beat Chrome's App-Bound Encryption for session hijacking - Packetlabs packetlabs.net · Blog
• Vercel rolls out new protection against stolen session cookie attacks BleepingComputer · News · 2026-11-04
• Infostealer malware bypasses Chrome's new cookie-theft defenses BleepingComputer · News
• Chrome 146 deploys Device Bound Session Credentials vs malware ctrlaltnod.com · News
• Third-party AI hack triggers Vercel breach, internal environments accessed - Security Affairs securityaffairs.com · News · 2026-04-20

More in threat intel

• Rehub: Russian-Language Cybercrime Forum Emerging as Primary Ransomware Marketplace (Post-XSS/RAMP Takedowns)
• NCSC Annual Review 2026: AI-enabled malware and exploitation of legacy technology expected to target UK critical national infrastructure by 2028
• Industrialized Cybercrime Economy: Commoditized Stealer Logs, Phishing Kits, Identity Fraud and Ransomware Services (Group-IB)
• ShinyHunters Post-Arrest Brand Fight: Rival Factions, Shared Extortion Infrastructure and Impersonation (SLSH / Aegis / ShinyEquationCartel)
• Russian MVD Arrests 3 Suspected VasyGrek (Fluffy Wolf) Members; Financially Motivated Phishing/Golang Backdoor Campaigns Continue to be Tracked