VoidStealer Bypasses Chrome Encryption With Remote Debugger Attack
Security researchers have identified a new information stealer called VoidStealer that uses a novel technique to bypass Chrome's Application-Bound Encryption (ABE) — a key protection introduced in Chrome 127 to prevent credential theft from the browser's local data store. Rather than attacking the encryption scheme directly, VoidStealer exploits Chrome's own remote debugging interface to extract the master key in plaintext, sidestepping ABE entirely.
Background: Application-Bound Encryption
Google introduced ABE in Chrome 127 specifically to counter the surge of infostealers targeting Chrome's password store. Prior to ABE, Chrome encrypted sensitive data (passwords, cookies, payment tokens) with DPAPI — a Windows API that any process running as the logged-in user could call. This allowed infostealers to dump Chrome credentials without any browser interaction.
ABE tied the encryption keys to Chrome's application identity, requiring that key-decryption operations happen within a Chrome process itself. This raised the bar for credential theft significantly — until VoidStealer found a way around it.
The Debugger Trick
VoidStealer's ABE bypass relies on Chrome's remote debugging capability — a legitimate developer feature that allows external tools to inspect and control a running Chrome instance via the Chrome DevTools Protocol (CDP).
Attack Flow
1. VoidStealer launches on the victim machine
2. Malware identifies a running Chrome process
3. VoidStealer attaches to Chrome's remote debugging endpoint
(typically localhost:9222 or spawns Chrome with --remote-debugging-port)
4. Using CDP, VoidStealer executes JavaScript within Chrome's privileged
renderer context — the same context that has access to ABE-protected data
5. The JavaScript payload instructs Chrome to decrypt and return the
Application-Bound master encryption key
6. With the master key, VoidStealer decrypts Chrome's encrypted
Local State file, recovering all stored credentialsWhy This Works
Chrome's ABE protection validates that decryption requests originate from within a Chrome process — but the remote debugger operates as an extension of the Chrome process itself. When JavaScript executes via CDP inside Chrome's renderer, it runs with Chrome's full permissions, satisfying ABE's validation checks. The encryption scheme has no way to distinguish a legitimate Chrome operation from one injected via the debugger protocol.
Data at Risk
Once VoidStealer extracts the master key, it can decrypt the full contents of Chrome's encrypted data store:
| Data Type | Storage Location | Exposure |
|---|---|---|
| Saved Passwords | Login Data (SQLite) | Full plaintext |
| Session Cookies | Cookies (SQLite) | Enables account hijack |
| Authentication Tokens | Various encrypted entries | Full plaintext |
| Payment Card Data | Web Data (SQLite) | Card numbers, CVVs |
| Autofill Data | Web Data (SQLite) | Addresses, form fills |
This positions VoidStealer as one of the more capable Chrome-targeting infostealers to emerge since Google's ABE rollout.
Why Chrome's ABE Isn't Defeated — Yet
It is important to note that VoidStealer's technique requires the attacker to already be executing code on the victim's machine. ABE was never designed to prevent attacks from code running with user-level privileges — it was designed to prevent credential theft from other user-level processes that don't have legitimate Chrome access.
Google's next line of defense is expected to involve stricter controls over which applications can attach to Chrome's debugging interface, and potential detection of unauthorized CDP connections. In the meantime, users and organizations remain exposed to any malware that achieves initial code execution.
Detection and Mitigation
For End Users
- Avoid executing untrusted software — VoidStealer requires initial code execution on the host
- Use hardware security keys (FIDO2/WebAuthn) for critical accounts — stolen session cookies cannot bypass hardware MFA
- Enable Chrome's Enhanced Safe Browsing to block known malware distribution
- Monitor for unexpected Chrome processes with debugging flags (
--remote-debugging-port)
For Security Teams
# Detect Chrome processes with remote debugging enabled (Windows)
Get-Process chrome | ForEach-Object {
$cmdline = (Get-WmiObject Win32_Process -Filter "ProcessId=$($_.Id)").CommandLine
if ($cmdline -match "remote-debugging-port") {
Write-Warning "Chrome with debugging enabled: PID $($_.Id)"
Write-Output $cmdline
}
}# Linux: detect Chrome debugger port usage
ps aux | grep chrome | grep remote-debugging-port
lsof -i :9222EDR Detection Signals
- Processes spawning
chrome.exewith--remote-debugging-portflags - Non-Chrome processes opening TCP connections to
localhost:9222 - File access to
%LOCALAPPDATA%\Google\Chrome\User Data\Local Statefrom non-Chrome processes
Broader Threat Context
VoidStealer joins a growing list of infostealers that have developed ABE bypass techniques since Chrome 127's release. The broader trend reflects the infostealer ecosystem's rapid adaptation to browser security improvements — each new protection layer is typically countered within weeks by threat actors motivated by the high value of browser-stored credentials.
The credential theft market remains extremely active in 2026, with stolen credentials from infostealers fueling downstream attacks including account takeovers, BEC campaigns, and ransomware initial access.
Key Takeaways
- VoidStealer bypasses Chrome's ABE by abusing the remote debugging interface (CDP) to extract the master key from within Chrome's own process context
- The technique defeats ABE's core protection model — application-identity-bound decryption — by executing from inside Chrome via the debugger
- All Chrome-stored sensitive data (passwords, cookies, payment data) is exposed once the master key is obtained
- Mitigation requires preventing initial code execution — ABE is not a defense against user-level malware
- Organizations should monitor for Chrome processes with debugging ports enabled and implement EDR rules for CDP abuse patterns