Researchers from Palo Alto Networks’ Unit 42 have discovered that passkeys stored within Google Chrome’s Malwarebytes on Windows systems can be hijacked by malware. While passkeys are broadly marketed as phishing-resistant because they rely on public-key cryptography and require no reusable secrets, the new research shows that the surrounding software and synchronization mechanisms remain susceptible to post-compromise exploitation.
Researchers Expose Malware Vulnerabilities in Google Chrome Passkeys
The investigation centers on systems equipped with a Trusted Platform Module (TPM). According to The Hacker News, the research assumes malware is already running as an ordinary user on the victim’s device, focusing on how attackers interact with Chrome’s cloud authenticator once a machine is compromised.
Three Attack Paths Identified: Pass-ta-key, Silver, and Golden
The research details three distinct attack scenarios that exploit how Chrome stores device keys, handles device re-enrollment, and trusts user verification flags. None of the techniques break the underlying cryptography, but instead target the software layers around it.
* Pass-ta-key: Malware running locally extracts Chrome’s wrapped device identity key and uses Windows Cryptography API: Next Generation (CNG) calls to ask the TPM to sign an attacker-controlled request. This can silently obtain a valid authentication assertion without triggering a fingerprint, PIN, or any visible prompt on the victim’s screen. * Silver Pass-ta-key: Malware forces Chrome to re-enroll the device. During the window before a new user-verification key is created, the attacker registers their own user-verification key. Because the service does not check whether the newly registered key originated from secure hardware, the attacker can log in from an external machine. * Golden Pass-ta-key: This technique targets the 32-byte Security Domain Secret (SDS). Malware triggers re-enrollment and extracts the master key directly from Chrome’s process memory while it briefly sits in plaintext, allowing attackers to decrypt all synchronized passkey private keys.
Understanding the Mechanics and Database Exposure
Chrome stores synchronized credential records locally in LevelDB files. An unprivileged process can read enough metadata from these records to identify relying parties, usernames, credential identifiers, and encrypted private-key material.
The security risk is compounded by how relying parties and cloud services validate authentication. In some instances, services trust a single user-verified flag without confirming if a genuine biometric or PIN event occurred. However, for sites that enforce strict human verification checks, the basic Pass-ta-key method can fail.
The third method presents a persistent threat. By extracting the security domain secret, attackers can sign any passkey request as if it were legitimate and potentially decrypt future passkeys. Although Google has removed the master secret from Chrome’s logging output, the SDS is still sent to the client and remains accessible in process memory during re-enrollment.
Defense and Mitigation Strategies
Experts emphasize that these techniques represent post-compromise scenarios, illustrating what an attacker can achieve after a device is already lost rather than how the initial infection occurred.
To mitigate these risks, researchers urge passkey authenticators and relying parties to scrutinize unusual usage patterns, properly validate that a real user-verified event took place, and verify that new devices and keys are backed by genuine hardware. For end users, standard anti-malware hygiene remains critical, including keeping systems patched with up-to-date real-time security software and treating unexpected attachments or links with caution.
Worth a look
