Researchers known as Unit 42 say they bypassed Google’s Chrome-based passkeys with a set of methods they call Pass-ta-key, pointing to buried flaws in Google Password Manager that they say can undercut what makes a passkey hard to attack.
The work is framed as endpoint abuse after malware is already on a Windows PC. A clean machine is not described as vulnerable when passkeys are used, yet the group says malicious software can still hit passkeys at the authentication stage even if those passkeys were created on a healthy device.
Several methods sit under the same Pass-ta-key label, including tricks the researchers say make certain sites treat a hijacked Chrome-based passkey as authentic.
One path, according to the researchers, exports an identity key to disk instead of the TPM and lets malware authenticate with Google Password Manager without user consent. The so-called silver method is reported to go further by tricking the password manager into assuming the user unlocked the device with biometrics, leaving verification in a pending state so the malware can register its own keys and have future keys approved.
Another approach is described as making Google trust the attacker’s device, so the victim’s computer is no longer required.
In a third line of work, the researchers say they stole a master secret Google Password Manager uses when it syncs passkeys across devices, a secret that protects those synced credentials. Related detail in the same research describes dumping Chrome process memory after an encryption process the researchers refer to only as SDS leaks into logs and memory, then collecting the synced passkey database.
Unit 42 casts its last method as the most serious, saying any future passkeys generated through Google Password Manager could be easily decrypted by the attacker unless a new SDS is generated.
The group says it disclosed the findings to Google and notes other passkey providers use a similar cloud authenticator model. Passkeys still remove whole classes of password weaknesses. The exposure Unit 42 describes sits in the credential-sync setup flow and in what Chrome leaves in process memory, and it only comes into play once malware is already running on the machine.
