Stealers evolve to bypass Google Chrome’s new app-bound encryption

With the release of Google Chrome v127, Google implemented “application-bound encryption” (a.k.a., “app-bound encryption” or ABE), a new feature aimed at stopping credential access attacks on Google Chrome cookies. This control relies on an elevated service running on Windows systems that attempts to verify an application is Google Chrome instead of stealer malware. In addition, this change is applied across the Chromium browser ecosystem, meaning that Chromium derivatives such as Microsoft Edge also inherit the control. This change has shifted the stealer landscape, forcing malware authors to implement new features to bypass the control and steal cookies.

How stealers are bypassing app-bound encryption

Multiple stealer families have already implemented bypasses to obtain cookies from newer Chromium browsers. These include Stealc, Vidar, LummaC2, Meduza, and more. You can read about detection opportunities common to many stealers in our Threat Detection Report.

Chromium remote debugging

This technique has been covered before by SpecterOps and more recently by SpyCloud in reporting on Phemedrone Stealer. In this case, malware must spawn a new instance of a Chromium browser with the command-line flags --remote-debugging-port=, and specify a port to expose for remote debugging. While performing this procedure, adversaries usually don’t want the new browser window to appear in front of an affected user, so they also use a --headless flag or --window-position while specifying negative values for the window position to make Chrome appear off-screen. This technique exposes the above process command-line details to endpoint sensors, providing several detection opportunities.

Unfortunately, this technique is not just limited to one or two malware families. This same technique has also been used in the wild by newer versions of Remcos RAT, whose browser recovery function is updated to handle ABE. In samples of Remcos sourced from VirusTotal, we’ve observed Chrome browser spawning with remote debugging enabled to recover cookies:

C:\Program Files\Google\Chrome\Application\chrome.exe --user-data-dir=C:\Users\user\AppData\Local\Temp\TmpUserData --window-position=-2400,-2400 --remote-debugging-port=9222 --profile-directory="Default"

The same can be said of Cryptbot stealer malware, which doesn’t seem to have as wide distribution as other families but still maintains new features. In the case of Cryptbot, we’ve found samples that use these command lines to spawn Chrome with remote debugging:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --profile-directory="Default"

This is notably different from Remcos and Phemedrone above, because Cryptbot does not specify a --headless or --window-position option. To achieve their objective, Cryptbot instead uses a special flag passed into the Windows API’s CreateProcess function to hide the spawned window from the victim’s view. This greatly affects detection from the command-line arguments.

Finally, we’ve observed Stealc and Vidar experiment with remote debugging alongside a second method described in the next section. This shows that malware developers may not be settled on one method of dumping cookies, and may still be trying to figure out what works best. In the case of Stealc and Vidar, we’ve found recent samples spawning Chrome for remote debugging in the same manner as Cryptbot:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9229 --profile-directory="Default"

Dumping cookies from memory

This procedure uses the methodology and details from ChromeKatz to dump the memory space of a Chromium browser, walk to specific offsets in memory, and obtain cookies from the memory dump. Malware analysis has confirmed that some versions of Stealc, Vidar, and Lumma stealers have adopted this technique to access Chromium cookies. This method does not produce telemetry visible to endpoint sensors, and it does not produce detectable behaviors. The good news is that it also doesn’t hide existing activity by the stealers implementing the technique, so process behaviors previously leading to detection of the malware families still apply. In addition, this technique is a brittle approach as it requires precise memory offset addresses that may change between Chromium versions.

Where some of the malware relies on dumping memory from already running instances of Chrome, Lumma has recently relied on spawning its own Chrome child process to dump the memory from it:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --profile-directory="Default"

As with Cryptbot, Lumma still manages to hide this window from the victim by using the Windows API’s CreateProcess function with flags to hide the process.

We have observed at least one instance of Stealc performing this technique in the wild, and Elastic Security Labs reported on Stealc using this technique as well. As no endpoint telemetry indicated the technique was used, pre-existing detection analytics identified Stealc and we subsequently identified the theft technique during malware analysis.

COM manipulation and path verification

Based on research by @AzakaSekai_, stealers can access Chromium cookies by communicating with the elevated Chromium service over COM interfaces while existing in the same folder as the browser process. Elastic observed this behavior in the wild among Metastealer samples, and recent social media posts suggest that Meduza Stealer may use this technique against newer Chromium browsers. We are exploring what additional behavioral detection opportunities may exist around this technique, especially since it requires suspicious modifications of browser application folders.

ApplicationBoundEncryptionEnabled registry settings

Adversaries also appear to be leveraging a Google Chrome policy-based solution to disable app-bound encryption, according to analysis of samples found on VirusTotal. This policy-based approach sets a specific Windows Registry key for relevant Chromium browsers. Using this technique should require administrator-level privileges, as it requires setting registry keys that affect all users on an affected system.

• Google Chrome: Software\Policies\Google\Chrome\ApplicationBoundEncryptionEnabled
• Microsoft Edge: Software\Policies\Microsoft\Edge\ApplicationBoundEncryptionEnabled

The registry keys disable app-bound encryption for their relevant browsers when the registry key is set to 0 and the web browser is restarted. We have not yet observed this behavior, but a VirusTotal Enterprise search using the term behavior:ApplicationBoundEncryptionEnabled reveals a few Exela Stealer samples that seem to try this technique. We are exploring whether this technique is being used by more malware and whether detection analytics can reliably detect malicious manipulation.

What to do now

Application-bound encryption is enabled by default with all Google Chrome and Microsoft Edge versions after v127. While this control can be bypassed, we still recommend updating web browsers to the latest version practical for your organization. Doing so brings stronger protection to data stored in the browser against stealers that have not evolved to new techniques. In addition, updated browser versions mitigate vulnerabilities that may be exploited in older versions of the browsers.

We recommend updating web browsers to the latest version practical for your organization.

If you use updated browser versions in your organization, you can audit settings to check whether app-bound encryption has been disabled. You can do so by querying ApplicationBoundEncryptionEnabled registry keys, as seen here:

• reg.exe query HKLM\Software\Policies\Google\Chrome /v ApplicationBoundEncryptionEnabled
• reg.exe query HKLM\Software\Policies\Microsoft\Edge\ /v ApplicationBoundEncryptionEnabled

If the returned values are either 1 or not found, application-bound encryption is enabled for that web browser. If the returned value is 0, application-bound encryption is disabled for that browser.

Finally, if your organization has detection capabilities in place for existing stealers, keep in mind that this evolution to bypass app-bound encryption does not aid in evading those capabilities. This change does not subtract detectable behavior from the malware.