"Unlike passwords, passkeys can't be shared, copied, written down, or accidentally given to someone else. This makes them more secure against phishing," reads Google's passkey documentation.
Unit 42's three Pass-ta-key techniques
Palo Alto Networks' Unit 42 disclosed three related attacks — collectively named "Pass-ta-key" — that let malware on already-compromised Windows devices abuse Google Password Manager's synced passkeys. The report describes three distinct techniques: Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. All three require an attacker to have malware running on the victim's machine; none break the underlying passkey cryptography. Instead, the techniques exploit implementation and workflow weaknesses in Chrome and Google's cloud authenticator for TPM-equipped Windows devices.
How the attacks exploit Chrome, the TPM, and Google's cloud authenticator
The basic Pass-ta-key technique lets unprivileged malware impersonate a trusted device and obtain a valid authentication response (an assertion) for a victim's passkey. The malware abuses Chrome's TPM-backed device identity key to sign a request to Google's cloud authenticator. Because the cloud authenticator treats the signed request as coming from the user's trusted computer, it returns an assertion that can be used to sign into the targeted account. That assertion contains a User Verified flag meant to indicate whether a biometric or PIN check occurred; when a relying service properly verifies that flag, the attack fails.
Built by Nubivance.
OSINTSights' secure edge-first architecture, AI content pipeline, and serverless ops are designed by Nubivance. We do this for clients too.
Talk to us →Silver and Golden Pass-ta-key: registering verification keys and stealing the master key
Silver Pass-ta-key escalates the problem by allowing attackers to register a user-verification key they control with Google's cloud authenticator. Unit 42 explains that malware can force Chrome to re-register the device — for example, by invalidating an existing verification key or deleting the local passkey state — and then register the attacker's verification key because the cloud authenticator does not validate whether the new key actually came from trusted hardware. Once accepted, Google will treat requests signed with that malicious key as evidence the user completed verification, enabling sign-ins to services that do check the User Verified requirement.
Golden Pass-ta-key is the most severe of the three: malware can extract the master key, called the security domain secret (SDS), which encrypts a user's synced passkeys. Unit 42 found that the SDS is temporarily sent to Chrome during device registration or recovery and was exposed in plaintext in Chrome's internal FIDO logs. Google removed the secret from the logging output after being notified, but Unit 42 reported the SDS is still sent to the client and remains accessible in Chrome's process memory. If an attacker forces a re-registration and knows the memory pattern to search for, they can extract the SDS, decrypt synced passkey records, recover private keys, and move those keys to another system to impersonate the victim. Unit 42 also warned the stolen SDS could decrypt future passkeys synced to the account because Google's current implementation reportedly provides no way to rotate or revoke the secret.
Real-world tests and responses: eBay, GitHub, and disclosure
Unit 42 tested the techniques against real services. The initial Pass-ta-key attack failed against GitHub because GitHub properly validated the User Verified flag. Unit 42 reported success against eBay: although eBay required user verification, it did not properly validate that flag. Unit 42 notified affected services, and eBay has since fixed the issue the researchers reported. The researchers disclosed the Google Password Manager attacks to Google and reported related user-verification flaws to affected services before publishing their findings.
BleepingComputer contacted Google for comment on Unit 42's findings and to ask whether the described attacks have been fully addressed, but a response was not immediately available.
What this means for websites, credential managers, and end users
- Websites and relying services: Require and properly validate user verification requirements such as the User Verified flag; services that check verification correctly (Unit 42 cites GitHub as an example) can block one class of Pass-ta-key exploitation.
- Credential manager vendors and browser teams: Validate newly registered device keys, harden recovery and device re-registration flows, and prevent master secrets (the SDS) from becoming accessible in browser process memory. Unit 42 explicitly recommends these changes to reduce the attack surface.
- End users: Passkeys remain, in Unit 42's assessment, significantly safer than traditional passwords, but these attacks demonstrate they do not remove the risk posed by malware already running on a compromised device; malware presence on a device remains the enabling condition for all three techniques.
Passkeys shift many risks away from passwords, but the Pass-ta-key research draws a clear line: implementation and workflow vulnerabilities — not the cryptography itself — are the weakest link when an attacker already controls a device. Unit 42's disclosures prompted at least one service (eBay) to fix a validation gap and prompted Google to remove the SDS from Chrome's logging output; the researchers' remaining concerns about SDS exposure in process memory and the absence of SDS rotation or revocation leave concrete technical questions for browser and cloud-authenticator implementers to answer.
