Security
Google passkeys face new Pass-ta-key attack
Unit 42 says malware-infected Windows PCs can bypass Google Password Manager passkeys through attacks dubbed Pass-ta-key.
Google Password Manager passkeys can be bypassed on malware-infected Windows PCs, according to security researchers at Palo Alto Networks' Unit 42. The group has dubbed the attack series “Pass-ta-key.”
Passkeys replace reusable passwords with cryptographic credentials protected by a device’s biometrics or local authentication. That design removes many password-based attack paths, but Unit 42 found weaknesses in how Chrome-based passkeys are created, verified, and synchronized through Google Password Manager.
The attacks require a major precondition: the Windows computer must already be infected with malware. A clean PC is not vulnerable to these techniques. However, malware can target the authentication process even when the passkey itself was originally created on a healthy device.
How the Pass-ta-key attacks work
Unit 42 identified several methods, each targeting a different part of Google’s passkey protection:
- The first method takes control of a protected account from an infected device. The identity key is exported to disk rather than remaining inside the computer’s TPM, the hardware component normally intended to protect it. Malware can then authenticate to Google Password Manager without the user’s consent.
- The “silver” attack tricks the password manager into believing that biometric verification has completed. The compromised Windows machine remains in a pending state while user verification is not properly marked as finished. Malware can use that gap to register its own keys, allowing future keys to be accepted.
- The “golden” attack extracts the most valuable information. Google’s encryption process, called SDS, can leak into Chrome’s logging system. Even after Google removes the data from the log, traces can remain in Chrome’s process memory. Malware can dump that memory and retrieve the database containing the user’s synchronized passkeys.
The final method is the most serious because the stolen SDS can function as a blueprint for decrypting future passkeys generated through Google Password Manager. Until a new SDS is created, the account’s passkeys remain exposed, according to the researchers.
A narrow exploit with broad implications
The first attack worked only against eBay, because the site did not validate the flag indicating whether user verification had actually taken place. Unit 42 did not name the other services it tested, although it said the affected providers had been contacted. The remaining methods bypassed user verification entirely.
Unit 42 also contacted Google to disclose the findings. The researchers said other passkey providers use the same cloud-authenticator model, suggesting the underlying design issue may not be unique to Google Password Manager. The report does not establish that every provider using that model is vulnerable, however.
The findings do not make passkeys equivalent to passwords. They still eliminate the reusable password strings and many of the attacks that depend on stealing or reusing them. But they do show that the security boundary has shifted: an infected endpoint can attack passkeys during enrollment and authentication, even if the credential began life on a secure device.
That endpoint risk matters because malware remains the required first step. As we reported in the ClickLock Stealer campaign targeting macOS password data, credential theft increasingly focuses on the device and the sign-in workflow rather than just the password itself. Google has not said in the report when it will issue a fix or whether all of Unit 42's methods have been addressed.