VoidStealer Steals Chrome Master Key Using a Debugger Trick

Chrome keeps saved passwords locked behind one master key. VoidStealer steals that key using a tool Chrome cannot block. It does not need administrator rights, does not touch the browser’s code, and when it is done, saved passwords, open login sessions, and stored payment cards are all readable. The technique had been sitting on GitHub as open-source research for over six months. Nobody had used it in the wild until now.

When a browser saves a password, it does not store it in plain text. It locks it with an encryption key, so anyone who grabs the file from disk gets scrambled data that is useless without the key. The problem is that the key has to live somewhere on the machine too. Windows has a built-in system for handling those keys called the Data Protection API, or DPAPI. The way DPAPI works, any program running as the same Windows user can ask for those keys and get them back, and that includes malware. Password-stealing tools, called infostealers, were built around exactly this. They run as a normal user, ask DPAPI for the browser’s key, and walk away with everything saved in the browser.

Google tackled this in July 2024 with Chrome 127 by introducing something called App-Bound Encryption, or ABE. The way it works: a separate Windows service running with the highest system privileges holds the encryption key and only hands it over after checking that the request is genuinely coming from Chrome. A piece of malware running as a normal user cannot fake that check well enough to get through. Google’s goal was to make life significantly harder for infostealers and to push anyone trying to bypass the protection into actions that security tools would more easily spot.

It worked, and then it did not.

Within months, the developers behind Lumma Stealer, Meduza Stealer, Whitesnake, and Lumar all said they had found ways around it. In October 2024, a security researcher named Alex Hagenah published a working open-source tool on GitHub called Chrome-App-Bound-Encryption-Decryption that confirmed bypasses were already out there and available to anyone who wanted them. Google patched what it could find, developers found new paths around the patches, and that cycle has not stopped since.

VoidStealer came out of that same cycle, and the technique it brought in March 2026 is the most advanced ABE bypass seen in the wild so far.

The malware first showed up on an underground hacking forum called HackForums on December 12, 2025, sold as a malware-as-a-service platform. That means the people who built it rent it out to other criminals who do not want to write their own code. The buyers set up campaigns, infect machines through fake software or cracked programs, and the stolen credentials come back automatically. VoidStealer went through twelve versions in about three months, from v1.0 on December 12, 2025 to v2.1 on March 18, 2026. Version 2.0, released on March 13, introduced the technique that set it apart.

Before v2.0, VoidStealer got past ABE the same way other infostealers did: it injected itself into the Chrome process and used Chrome’s own internal verification system to request the decryption key from inside the browser. That works, but injecting code into another running process is noisy and security software catches it regularly.

Version 2.0 skips the injection completely.

When a program runs, Windows gives it a block of memory called RAM to work with. Chrome needs to decrypt its master key at some point because the whole reason for saving passwords is to fill them in on websites. At that moment, for a very short window, the key is sitting in that RAM block in plain readable form. Chrome tries to keep that window as small as possible, but it cannot avoid it entirely. The key has to be there for the decryption to happen.

Developers use a tool called a debugger to look inside programs while they are running. A debugger can attach to a running process, pause it at any point, and read what is in memory right at that moment. It is a normal development tool that developers use to troubleshoot their code. VoidStealer uses it as a weapon.

The malware starts a new hidden Chrome window in the background using a Windows function called CreateProcessW, with a flag called SW_HIDE so the user sees nothing on screen. It then immediately attaches to that Chrome process as a debugger. As Chrome starts up, it loads its saved cookies from disk. Those cookies are ABE-protected, so Chrome has to request and decrypt the master key during startup. That decryption is the moment VoidStealer is waiting for.

While Chrome is loading, VoidStealer scans through Chrome’s core code file, chrome.dll, looking for a specific text string baked into the compiled code: OSCrypt.AppBoundProvider.Decrypt.ResultCode. That string sits in Chrome’s source code at the exact point right after the master key has been decrypted. The string remains present across Chrome versions, allowing the malware to locate the right code path even when memory addresses change.

Once it finds that spot in memory, VoidStealer places what is called a hardware breakpoint there across all running browser threads. The difference between a hardware breakpoint and a software breakpoint matters here. A software breakpoint works by actually modifying the code in the target process, writing a new instruction into it. That modification is something security tools can detect. A hardware breakpoint is set through the CPU’s own debug registers, DR0 and DR7, using a Windows call called SetThreadContext. Nothing gets written to the browser process at all, so there is nothing for security tools scanning for memory writes to find.

When Chrome hits that point in its startup sequence, it pauses. The master key, called the v20_master_key, is sitting right there in that RAM block in plain text. For Chrome it is in the R15 register. For Edge, it is in R14. VoidStealer reads it with two calls to ReadProcessMemory. Chrome then continues loading normally, the user sees nothing, and the malware now has the key that opens everything the browser has ever saved.

With that key, VoidStealer can decrypt the entire browser database without Chrome even running: saved passwords, session cookies, autofill data, payment card numbers, and authentication tokens. Session cookies are worth looking at separately because the risk they carry is different from a stolen password. When someone logs into a website, the site hands back a session cookie that keeps them logged in. Stealing that cookie gives an attacker a working logged-in session without ever needing the password and without triggering a new login that might send an alert. Two-factor authentication does not help here because the session was already verified before the cookie was taken.

VoidStealer also has a backup method. If the debugger approach runs into a problem, it falls back to the older injection technique, calling the decryption function from inside the Chrome process. That fallback is noisier and more likely to get caught, but having both means the malware has a second route when the first one does not work.

VoidStealer did not come up with the debugger technique on its own. Researchers at Gen Digital, the company behind Norton, Avast, AVG, and Avira, confirmed after analyzing version 2.0 that the code was taken almost directly from an open-source project called ElevationKatz, part of a toolkit called ChromeKatz that a security researcher going by the handle Meckazin had put on GitHub. That project had been sitting there publicly for more than six months before VoidStealer used it. ElevationKatz even comes packaged with a Beacon Object File for Cobalt Strike, so the technique was already part of legitimate red team toolkits used in authorized security testing long before criminals picked it up. VoidStealer is the first infostealer confirmed in the wild to actually use it against real targets.

VoidStealer currently goes after Chrome and Microsoft Edge specifically, looking for chrome.dll and msedge.dll. The technique itself works on any Chromium-based browser that uses App-Bound Encryption, so Brave, Opera, and Vivaldi are also in range. Firefox is not affected by this attack because it handles stored credentials in a completely different way.

1
2
3
4
5

Tactic:    Credential Access
Technique: T1555.003 — Credentials from Web Browsers
Platform:  Windows
Condition: User-level access | malware already running on machine
Tool:      VoidStealer v2.0 (MaaS, advertised on HackForums since December 2025)

The clearest signal to hunt for is debugger attachment to browser processes. Legitimate software does not attach a debugger to Chrome or Edge on its own. Any process doing this without the user starting it is worth investigating straight away. Security teams should also watch for:

• → Processes attaching to chrome.exe or msedge.exe via DebugActiveProcess
• → Hidden browser instances launched with the SW_HIDE flag or in headless mode
• → ReadProcessMemory calls from unknown processes aimed at browser processes
• → Chrome or Edge processes showing up with unexpected parent processes

SHA-256 hash for VoidStealer v2.0:

1

f783fde5cf7930e4b3054393efadd3675b505cbef8e9d7ae58aa35b435adeea4

The most direct fix is to stop keeping sensitive passwords in the browser. A dedicated password manager stores the vault encrypted separately and only decrypts it when actively opened, completely outside the browser process. Tools like Bitwarden and 1Password work this way. Whatever an infostealer does to the browser process, the passwords are simply not there to take.

Beyond that:

• → Keep Windows and Chrome updated. Google responds to these techniques as researchers find and document them.
• → Avoid installing software from sources that cannot be verified. Infostealers have to be running on the machine first before any of this is possible.
• → Learn to recognize ClickFix attacks. Infostealers are often spread through fake browser update prompts and copy-paste instructions that get people to run the malware themselves.
• → Run endpoint protection that watches process behavior, not just file signatures. Behavioral detection catches this kind of attack where signature scanning does not.

How attackers escalate privileges, dump credentials from Windows systems, and move through a network after getting in is what the ethical hacking course covers hands-on from the start:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Source: Gen Digital