Researchers at Palo Alto Networks’ Unit 42 have disclosed three distinct attack paths that allow malware already running on a Windows machine to hijack passkey-protected accounts through Chrome’s Google Password Manager, bypassing the very authentication mechanism designed to replace passwords.
The three techniques, dubbed Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key, target the code surrounding Chrome’s passkey implementation rather than breaking its underlying cryptography. Each exploits a different stage of how the browser stores device keys, re-enrolls devices, and verifies human presence at sign-in.
How the Attacks Work
In the first path, Pass-ta-key, the malware extracts Chrome’s wrapped device identity key and uses Windows CNG (Cryptography API: Next Generation) calls to ask the TPM to sign an attacker-controlled request. Chrome creates this TPM key without a key name, meaning it is not persisted to disk but remains reloadable as an opaque blob. The resulting assertion is valid except for a single missing bit, the User Verified flag, which indicates no human verification occurred. Sites that enforce userVerification at the server level, such as GitHub, can block this. eBay initially did not and only fixed the gap after disclosure.
Silver Pass-ta-key takes a different route by forcing Chrome to re-enroll the device. During re-enrollment, Chrome does not create its user-verification key immediately, leaving a window where malware can register an attacker-controlled key instead. Assertions signed with that substituted key carry the UV flag, enabling logins from the attacker’s own environment without the victim’s device.
The Strongest Path: Golden Pass-ta-key
The third and most powerful technique, Golden Pass-ta-key, targets the 32-byte Security Domain Secret used to decrypt synced passkey private keys. By triggering re-enrollment, the malware can read the secret from Chrome’s process memory while it briefly sits in plaintext, then use it to recover all synchronized passkey private keys. This grants reusable access from a completely separate environment after the initial compromise.
Unit 42 noted that Google removed an earlier SDS exposure from Chrome’s FIDO logs, and eBay now validates the UV flag after disclosure. However, the secret still reaches the client and resides in Chrome’s memory, meaning the logging change alone does not close the described path. As of the August 3 disclosure, no CVE identifiers were assigned. Google rarely assigns CVEs to issues requiring prior device compromise, said researcher Arie Olshtein.
The research is limited to Google Password Manager in Chrome on Windows systems equipped with a TPM. All three paths begin with malware already running on the victim’s device, making these post-compromise techniques rather than initial access vectors. Relying parties are advised to set userVerification to required and verify the returned UV flag. Credential providers should attest newly enrolled keys and restrict access to local passkey state.
Sources: Palo Alto Networks Unit 42; The Hacker News; W3C Web Authentication Specification
discussion