A new variant of the MaaS infostealer VoidStealer has become the first malware observed in the wild to weaponize a debugger‑based bypass for Google Chrome’s Application‑Bound Encryption (ABE), using hardware breakpoints to steal Chrome’s v20_master_key directly from browser memory.
Unlike previous ABE bypasses, this method requires neither SYSTEM‑level privilege escalation nor code injection into the browser process, significantly reducing the detection footprint while still giving attackers full access to ABE‑protected cookies and credentials.
ABE stores secrets such as cookies and, in some configurations, passwords as v20‑prefixed values encrypted with a per‑application AES‑GCM key (often referred to as the v20_master_key), which is itself protected using CryptProtectData under NT AUTHORITY\SYSTEM and decrypted via the Google Chrome Elevation Service when Chrome calls IElevator::Decrypt.
Traditional infostealers have responded with several bypasses, including running as SYSTEM and replicating the service logic or injecting into the browser to invoke IElevator::DecryptData via COM from inside the Chrome context. However, both approaches are relatively noisy in EDR telemetry.
Google introduced ABE in Chrome 127 in July 2024 to make cookie and, progressively, other secret theft attempts noisier by tying decryption to Chrome’s identity and a privileged elevation service.
VoidStealer follows this pattern by implementing the “classic” COM‑based IElevator::DecryptData injection technique as a fallback.
However, its standout feature in v2.0 is a debugger‑driven method that sidesteps both SYSTEM and injection requirements by stealing the master key at the brief moment it exists in plaintext during normal ABE decryption.
This makes the new bypass especially attractive to threat actors who want to evade behavioral detections focused on privilege escalation, process hollowing, and remote thread injection into browsers.
Debugger‑Based v20_master_key
The new technique, copied almost directly from Meckazin’s open‑source ElevationKatz project, hinges on attaching to Chrome or Edge as a debugger and leveraging hardware breakpoints to intercept the v20_master_key when Chrome decrypts it to process ABE‑protected data.
VoidStealer v2.0 begins by spawning a hidden browser instance with CreateProcessW using SW_HIDE and CREATE_SUSPENDED, then quickly resuming it and attaching as a debugger via DebugActiveProcess, capitalizing on the fact that browsers typically load and decrypt cookies during startup.
Once attached, VoidStealer waits for LOAD_DLL_DEBUG_EVENT notifications, identifies chrome.dll or msedge.dll, and scans the module’s .rdata section with ReadProcessMemory to locate the OSCrypt.AppBoundProvider.Decrypt.ResultCode string, which Chromium places immediately after a call to os_crypt::DecryptAppBoundString in the ABE decryption path.
It then scans the .text section for LEA instructions (48 8D 0D …) whose computed displacement resolves to that string, yielding a precise instruction address that is executed when the v20_master_key is resident in plaintext.
Using NtGetNextThread and SetThreadContext, VoidStealer configures a hardware breakpoint (DR0/DR7) at that address across all existing and newly created browser threads, avoiding any patching of browser memory that a software breakpoint would require.
When the browser hits this breakpoint during startup, the current builds of Chrome and Edge place a pointer to the v20_master_key in R15 (Chrome) or R14 (Edge), allowing VoidStealer to follow the register value and extract the key with a pair of ReadProcessMemory calls, without any CryptUnprotectData or CryptUnprotectMemory usage inside the victim process.
Once the v20_master_key is obtained, the infostealer can offline‑decrypt any v20‑prefixed ABE‑protected cookies and credentials from the browser SQLite databases, effectively nullifying ABE’s protection for that profile.
Detection Opportunities for Defenders
While implementation details may vary as other malware families adopt similar techniques, the bypass exhibits several stable behavioral invariants that defenders can target.
Following the cross-reference in chrome.dll, we can see that the disassembled code corresponds to the source code and that the cross-reference comes from a LEA instruction.
First, the attack requires either launching a browser under a debugger or attaching a debugger to an existing Chrome or Edge process, which is highly atypical for non‑developer software; monitoring for DebugActiveProcess, debug object handles, or unexpected parent processes for chrome.exe/msedge.exe can surface such activity.
Second, the technique depends on intensive browser memory reads, including scanning .text/.rdata sections and reading key material, so correlating ReadProcessMemory calls against browser processes from unsigned or untrusted binaries is a strong hunting signal.
In addition, most infostealers will try to conceal the helper browser instance used for the bypass, for example by creating it with SW_HIDE, running in headless mode, or placing windows off‑screen, making hidden or non‑interactive browser sessions launched by unknown parents another important indicator.
Telemetry pipelines that fuse process creation, debugger attachment, memory‑access patterns, and hidden‑window flags are well positioned to catch this new class of ABE bypass even though it avoids privilege escalation and direct code injection.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
.){kind=link}