{"id":30546,"date":"2026-05-06T12:53:46","date_gmt":"2026-05-06T11:53:46","guid":{"rendered":"https:\/\/www.kaspersky.co.uk\/blog\/?p=30546"},"modified":"2026-05-06T12:53:46","modified_gmt":"2026-05-06T11:53:46","slug":"chrome-application-bound-encryption-bypass-voidstealer","status":"publish","type":"post","link":"https:\/\/www.kaspersky.co.uk\/blog\/chrome-application-bound-encryption-bypass-voidstealer\/30546\/","title":{"rendered":"New VoidStealer Trojan bypasses Chrome’s stored data protection"},"content":{"rendered":"

Malicious actors have developed a new way to steal data stored by Chrome for Windows. Researchers discovered the technique while analyzing a fresh build of an infostealer known as VoidStealer. The new method allows the malware to bypass Chrome\u2019s Application-Bound (App-Bound) Encryption (ABE), a mechanism intended to protect session cookies<\/a> and other valuable information stored in the browser.<\/p>\n

Google hoped this mechanism would secure the master key Chrome uses to encrypt all sensitive data. Unfortunately, this isn\u2019t the first time malware authors have found a workaround for this defense \u2014 leaving secrets stored in Chrome vulnerable once again.<\/p>\n

How App-Bound Encryption works in Chrome<\/h2>\n

Google introduced<\/a> App-Bound Encryption in July 2024 with the release of Chrome version 127. The company\u2019s announcement mentioned infostealers snatching cookies from Chrome users on Windows as the primary problem ABE was intended to solve. We\u2019ve already covered in detail what these files are and the consequences of their theft<\/a>, so we\u2019ll only briefly recap the main facts here.<\/p>\n

Cookies are small files that the browser saves to the user\u2019s device at a website\u2019s request to remember various site settings. Of particular value to attackers are session cookies, which are used for automatic authentication on websites. It\u2019s thanks to these files that we don\u2019t have to enter a username and password every time we revisit a site.<\/p>\n

But this convenience carries a risk: stealing these files allows an attacker to use an already-authenticated session without entering a username or password. This allows them to impersonate the user, which can lead to account hijacking, theft of personal or financial data, and other adverse consequences.<\/p>\n

Infostealer Trojans are particularly dangerous for Chrome users on Windows. This is because, on this OS, Chrome previously relied solely on the standard built-in Data Protection API (DPAPI)<\/a>. With this system encryption mechanism, applications don\u2019t need to create and store encryption keys to protect data.<\/p>\n

The limitation of DPAPI is that it doesn\u2019t protect data from malware that\u2019s already successfully compromised the system and is capable of executing code on behalf of the logged-in user. This is exactly what stealers exploit: since they typically run with the user\u2019s privileges, they can simply request DPAPI to decrypt the browser\u2019s protected data.<\/p>\n

The ABE mechanism was designed to solve that specific problem. The core idea is right in the name: App-Bound Encryption means the encryption is tied to a specific application. To achieve this, a separate service running with system privileges is responsible for protecting the key used to encrypt Chrome\u2019s data. It verifies which application is requesting access to the key, and denies the request if it doesn\u2019t originate from Chrome.<\/p>\n

\"How<\/a>

Chrome\u2019s App-Bound Encryption (ABE) was designed so that only Chrome itself could retrieve the master key needed to decrypt the browser\u2019s stored data. Source<\/a><\/p><\/div>\n

As a result, the architects of this feature assumed that to access ABE-protected browser data, an infostealer would either need to escalate its privileges to system-level, or inject malicious code directly into Chrome. In theory, this should have made attacking Chrome significantly harder and reduced the effectiveness of mass-market infostealers. As you might have guessed, things didn\u2019t go quite that smoothly in practice.<\/p>\n

Previous successful bypasses of Chrome\u2019s ABE<\/h2>\n

Just a couple of months after Google announced the implementation of App-Bound Encryption in Chrome, many infostealer developers<\/a> claimed they\u2019d already bypassed the protection. Among them were the creators of Meduza Stealer, Whitesnake, Lumma Stealer, and Lumar (also known as PovertyStealer).<\/p>\n

\"Announcement<\/a>

Lumma stealer developers announce a bypass for Chrome\u2019s App-Bound Encryption in a new version of the malware<\/p><\/div>\n

Of course, you shouldn\u2019t take malware developers at their word, but legitimate security researchers were able to confirm at least some of the claims. Bypasses for Google Chrome\u2019s new data protection feature did become available almost immediately after its release.<\/p>\n

A month later, in October 2024, tech enthusiast Alex Hagenah published a tool on GitHub called Chrome-App-Bound-Encryption-Decryption<\/a> to bypass Google\u2019s new security mechanism. Analysis of the tool\u2019s code revealed that its author used roughly the same methods that attackers were already heavily exploiting.<\/p>\n

What followed was a game of cat and mouse: security researchers<\/a> and stealer developers<\/a> came up with new tricks to circumvent App-Bound Encryption, while Google patched the newly discovered loopholes with varying degrees of success.<\/p>\n

VoidStealer \u2014 a new data-nabbing menace<\/h2>\n

This brings us to recent events: in March 2026, news broke about a stealer named VoidStealer<\/a>, which utilizes a brand-new and, by all accounts, highly effective method for bypassing ABE.<\/p>\n

\"Announcement<\/a>

VoidStealer developers advertising a new method for bypassing ABE. Source <\/a><\/p><\/div>\n

The malware authors developed an attack technique that targets the brief moment when the master key sits in the browser\u2019s memory in plaintext. This occurs because, at a certain point, the browser inevitably has to decrypt its data to actually use it \u2014 for instance, to automatically sign in to a website with the relevant session cookie or to access saved credentials.<\/p>\n

To exploit this window of opportunity, the malware attaches itself to the Chrome process as a debugger \u2014 a tool that allows one to control a program\u2019s execution, pause it, and inspect its memory. In legitimate scenarios, these tools are used by developers to find and fix bugs, analyze application behavior, and test performance.<\/p>\n

The malware identifies the specific section of code where data decryption takes place. It then sets a breakpoint at that location; when the program\u2019s execution reaches that point, the browser effectively freezes. This is how the malware catches the exact moment the master key is sitting in RAM in plaintext; it then reads the key directly from memory.<\/p>\n

It\u2019s worth noting that everything mentioned above also applies to other Chromium-based browsers that use ABE, including Microsoft Edge, Brave, Opera, Vivaldi, and others.<\/p>\n

How to avoid falling victim to infostealers<\/h2>\n

The scale of VoidStealer\u2019s reach could be significant, as its developers operate under the malware-as-a-service (MaaS) model. This means they rent out the ready-made tool to other attackers, so they don\u2019t need to develop custom malware from scratch.<\/p>\n

This situation demonstrates that relying solely on built-in security mechanisms isn\u2019t enough. Unfortunately, stealer developers are coming up with new workarounds faster than browser and operating system developers can roll out patches.<\/p>\n

Here\u2019s what users can do about it:<\/p>\n