VoidStealer Bypasses Chrome Protection to Steal User Data

A newly identified VoidStealer infostealer has introduced a sophisticated debugger-based technique to bypass Google Chrome’s App-Bound Encryption (ABE), enabling silent theft of session cookies, saved passwords, and payment data without requiring elevated privileges or code injection.

Google introduced App-Bound Encryption in Chrome 127 (July 2024) to address the long-standing threat of infostealers harvesting browser credentials on Windows.

Before ABE, Chrome relied solely on Windows’ Data Protection API (DPAPI), which any malware running at user-level privileges could abuse to decrypt stored browser data.

ABE addressed this by delegating the protection of Chrome’s v20_master_key the AES-GCM key used to encrypt all sensitive browser data to a separate Google Chrome Elevation Service running as NT AUTHORITY\SYSTEM, which validates the requesting application before releasing the key.

VoidStealer Bypasses Chrome Protection

ABE’s protections began breaking down almost immediately after launch. Within months, developers behind Meduza Stealer, Lumma Stealer, Whitesnake, and Lumar all claimed successful bypasses.

In October 2024, researcher Alex Hagenah published the open-source Chrome-App-Bound-Encryption-Decryption tool, confirming that viable techniques were already in circulation.

Since then, the cat-and-mouse cycle between Google patches and stealer authors has continued, with each fix prompting new workarounds.

First advertised on dark web forums in mid-December 2025, VoidStealer is a Malware-as-a-Service (MaaS) platform that rapidly iterated through 11 versions before introducing its breakthrough ABE bypass in version 2.0 on March 13, 2026.

Researchers (parent company of Norton, Avast, and Avira) confirmed that it is the first infostealer observed in the wild to use this technique.

The attack flow works as follows:

• VoidStealer spawns a hidden, suspended Chrome or Edge process using CreateProcessW with SW_HIDE flags, then immediately attaches as a debugger via DebugActiveProcess
• It listens for LOAD_DLL_DEBUG_EVENT and waits for chrome.dll or msedge.dll to load into memory
• It scans the DLL’s .rdata section for the string OSCrypt.AppBoundProvider.Decrypt.ResultCode — the exact location in the Chromium source code where the v20_master_key is briefly present in plaintext
• Using hardware breakpoints (not software, to avoid writing to browser memory), VoidStealer sets a trap across all browser threads via DR0/DR7 registers
• When the breakpoint triggers during startup decryption, it reads the plaintext key from the R14 (Edge) or R15 (Chrome) register using just two ReadProcessMemory calls

Gen Digital confirmed VoidStealer’s implementation was directly adapted from the open-source ElevationKatz project, part of the ChromeKatz toolset that has been publicly available for over six months.

While VoidStealer currently targets Chrome and Microsoft Edge, the technique is readily extensible to all Chromium-based browsers, including Brave, Opera, and Vivaldi, Kaspersky said in a report shared with Cyberpress.

The MaaS model means criminal affiliates can deploy the stealer without writing any code themselves, dramatically expanding its potential reach.

Mitigation

Researchers note that legitimate applications never debug browsers autonomously, making debugger attachment a high-fidelity detection signal. Defenders should monitor for:

• Processes attaching to browser instances via DebugActiveProcess
• Hidden browser launches using SW_HIDE or headless flags
• Unprompted ReadProcessMemory calls against chrome.exe or msedge.exe

Users are advised to avoid downloading software from untrusted sources, keep browsers and Windows fully updated, and use a dedicated password manager rather than relying on Chrome’s built-in credential storage.

Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyberpress as a Preferred Source in Google.