In July, Google rolled out a new security feature for Chrome to help protect user authentication cookies called Application-Bound Encryption, or App-Bound Encryption. This feature improved the resilience of user session cookies to token theft by infostealer malware by making it so that encrypted cookie data on Windows devices are bound to the Chrome application. Before this feature, any application running as the logged in user on a Windows device – including infostealer malware on infected devices – could access this cookie data.
While the release of this feature temporarily saw several stealer families stop their distribution, SpyCloud and public reporting sources have now observed actors claiming they have bypassed the Chrome security feature and are able to exfiltrate unencrypted cookies from the newest versions of Chrome. We have observed these claims from the maintainers of the following infostealer malware families:
- Phemedrone
- LummaC2
- Meta
- Lumar
- Meduza
- Vidar
- StealC
- Rhadamanthys
- WhiteSnake
Telegram message from a developer of the open-source infostealer Phemedrone announcing the Chrome bypass. (Automatically translated from Russian)
SpyCloud analysts have reverse-engineered the bypass deployed in Phemedrone, an open-source infostealer, and are able to independently confirm the claims of a bypass.
To avoid turning our research into an instructional manual for other actors seeking to emulate the success of the aforementioned malware families, in this blog we’ll focus on providing security teams with the information they need to minimize their risk by protecting their environments.
About the Google Chrome Application-Bound Encryption bypass
At the time of publishing this article, the Application-Bound Encryption feature is enabled in the Windows version of Chrome by default. Infostealer developers appear to have discovered that they can use Chrome’s internal API – intended for remote management and testing – as a method to bypass this cookie encryption.
Users can enable remote debugging on Chrome over a specified port. Once this is enabled, the debugging port can be interacted with to send commands, one of which allows for users to dump all cookies.
Defenders should be on the lookout for Chrome processes that are spawned with:
“--remote-debugging-port=”
- The default port is 9222, the same port Phemedrone uses in its bypass, however this port can be modified on the command line.
- Additionally look for “--profile-directory=” or “--user-data-dir=” to see what profile the cookies are stolen from.
- Phemedrone also used “--window-position=”, which could be anomalous in environments.
- Alternatively, “--headless” is common for this type of activity.
Defenders should also be on the lookout for processes that then access the remote debug port that is spawned above. Additionally, defenders should be on the lookout for any unexpected traffic to port 9222.
This bypass does not need to leverage process hollowing or memory scraping, which is normally noisier, and thus would raise more red flags for defenders. Instead, the bypass that we have observed Phemedrone using is relatively stealthy because it uses native debugging features within Chrome to capture the data. Additionally, while App-Bound Encryption is only enabled in Windows, this attack also bypassess Mac’s Keychain protections and Linux’s secret storage protections, allowing cookies to easily be stolen from all three operating systems.
While we have not specifically examined the means by which other malware families have bypassed the new Application-Bound Encryption feature, based on our review of the remote management API, it is likely that other malware is making use of the same method.
What should security teams do to protect themselves?
This Chrome Application-Bound Encryption bypass is just another development in the cat and mouse game between infostealer developers and defenders who want to protect the integrity of their IAM processes.
And it’s another great example of how quickly cybercriminals can adapt to new security features: App-Bound Encryption was released on July 30, 2024 and we first observed evidence of bypass capabilities as early as September 12, 2024, less than 45 days later.
Security teams should use a layered approach, including continuously monitoring recaptured darknet data, to make sure that bad actors aren’t able to steal or use their users’ authentication cookies. We recommend:
- Implementing cookie expiration and invalidation policies
-
Monitoring for indicators of use of the Chrome debugging processes called out above including:
- Chrome processes spawned with the “--remote-debugging-port=” switch
- The unexpected use of port 9222, which is generally used for remote debugging
- Implementing a good antivirus program
- Making sure you have comprehensive management over your devices and networks, including a strict bring-your-own-device (BYOD) policy
- Continuously monitoring for malware-exfiltrated stolen data in the criminal underground
Post-infection remediation for malware
When a malware exposure is detected, while it is still best practice to isolate, image, and wipe the device, if accessible, we recommend additionally implementing a more comprehensive post-infection remediation plan into your playbooks:
- Reset passwords and usernames for affected applications
- Invalidate the user’s web sessions to prevent session hijacking
- Review all activity and access logs for the user within affected applications to confirm that detected activity is coming from expected IP address ranges and geographies and that all behavior fits the expected profile of the user
See how SpyCloud helps teams identify compromised data and prevent session hijacking
Keep reading
