Researchers from Palo Alto Networks Unit 42 have published a study of three post-exploitation techniques that allow malware running with regular user rights on a Windows system with TPM to authenticate into a victim’s accounts protected with a passkey—without biometrics, a PIN code, or any on-screen prompts. The attacks target Google Password Manager in the Chrome browser and do not break WebAuthn cryptography; instead, they exploit how keys are stored, the logic of device re-enrollment, and how web services validate the user verification flag. No exploitation in real-world attacks has been observed so far, no CVE identifiers have been assigned, and the full patch status remains unknown.
Architectural prerequisites for the attacks
All three methods — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — require that malicious code be run on the victim’s device beforehand. These are post-exploitation techniques: they describe what an attacker can do on a machine that is already compromised, not how to gain initial access.
According to the researchers, Chrome stores synchronized credentials in the directory %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, and an unprivileged process can read metadata, including relying party identifiers, usernames, credential IDs, and encrypted private key material.
A key architectural detail is confirmed by the Chromium source code: Chrome creates a TPM key without a name (which, according to a code comment, prevents it from being stored on disk), exports it as an opaque blob, and then reloads it. When signing, it uses the NCryptSignHash flag, which suppresses any user prompts. The same file contains a TODO comment referencing Chromium issue 398125799, proposing to mark such keys.
Three attack vectors
Pass-ta-key: bypassing user verification
The first method extracts the wrapped Chrome device identification key and, via the Windows CNG API, requests a signature from the same TPM for a request controlled by the attacker. Google’s cloud authenticator returns a valid assertion that differs from a legitimate one in only a single bit — the User Verified (UV) flag remains unset.
According to the Web Authentication Level 3 specification, if a service sets the userVerification parameter to “required”, it must reject authentication if the UV bit is not set. According to Unit 42, GitHub correctly enforced this check, whereas eBay accepted such assertions until it fixed the issue after disclosure.
Silver Pass-ta-key: verification key substitution
The second method targets the device re-enrollment process. The malware forcibly initiates Chrome re-enrollment, and in the resulting temporary window — when the browser has not yet created a user verification key — the attacker registers their own key. The Chromium source code confirms the existence of a deferred_uv_key_creation state for newly registered devices.
According to the researchers, the server side does not verify whether the newly registered key was obtained from a hardware security module. Assertions signed with the substituted key have the UV flag set, which reportedly allows the attacker to authenticate from their own device without access to the victim’s machine. However, the public Chromium code does not allow independent verification of the server side of this attack for the current stable version of Chrome.
Golden Pass-ta-key: extraction of the master secret
The most serious third method targets the 32-byte Security Domain Secret (SDS), the master key used to decrypt synchronized passkey private keys. According to Unit 42, the malware initiates re-enrollment and reads the secret from Chrome’s process memory at the moment when it briefly exists there in plaintext.
The Chromium source code confirms that Chrome creates or obtains 32-byte security domain secrets within client-process data structures. However, the reliability of extraction, the possibility of account takeover, and the persistence of access across secret epoch changes remain unconfirmed by independent sources.
The researchers report that Google removed a previously existing SDS leak through Chrome FIDO logs, but the secret still ends up in client memory, which does not close the described attack vector.
Uncertainty around patch status
The disclosure does not establish whether all three attack vectors have been closed. The study does not include CVE identifiers, a list of affected Chrome versions, or a full patch status. Google’s public documentation allows users to change the Google Password Manager PIN or delete all password manager data, but does not describe any mechanism for rotating or revoking the SDS. A critical question remains open: does changing the PIN or deleting the data invalidate a secret that has already been extracted by an attacker.
Impact assessment
The impact scope is limited to Chrome users on Windows with TPM who use Google Password Manager to synchronize passkeys. Two of the three methods (Silver and Golden Pass-ta-key), according to the researchers, provide renewed access from the attacker’s environment after the initial compromise — turning a one-time incident into a persistent access channel to the victim’s accounts.
It is important to keep the context in mind: all techniques require prior code execution on the device. This is not a remote attack on passkeys as a technology, but an extension of the capabilities of an attacker who has already established a foothold in the system. Nevertheless, for organizations considering passkeys as a password replacement with higher resistance to compromise, these findings show that the post-exploitation landscape is more complex than previously assumed.
Recommendations
For web service operators (relying parties):
- Set the userVerification parameter to required and verify the presence of the UV bit in the returned assertion — this is the only measure fully controlled on the service side that blocks the first attack vector.
- Do not rely solely on the request configuration — validate the authenticator’s actual response.
For credential providers:
- Verify hardware attestation when registering new verification keys.
- Strengthen checks during device re-enrollment and recovery.
- Restrict access to local passkey state and prevent master secrets from ending up in logs or otherwise accessible memory.
For end users:
- Ensure endpoint protection against malware — this is a prerequisite for all three attacks.
- If device compromise is suspected, change the Google Password Manager PIN and consider deleting password manager data, although Google’s documentation does not confirm how effective these measures are against an already extracted SDS.
The Unit 42 study highlights a systemic issue: the security of passkeys depends not only on cryptography but on the entire chain — from key storage on the device to server-side validation. Until Google publishes an official response confirming patch status and the SDS rotation mechanism, organizations should at a minimum ensure their web services strictly validate the UV flag, and users should keep Chrome up to date and maintain strong endpoint protection.
