Malware Can Turn Synced Passkeys into Persistent Access

Unit 42 has disclosed three attacks against Google Password Manager’s synced passkeys in Chrome on Windows computers equipped with a TPM.

All three attacks begin with malware already running as the victim’s ordinary user. They do not break WebAuthn cryptography or remotely compromise an otherwise clean computer.

That raises an obvious question: if malware already has local access, why not steal browser cookies?

It probably can. The distinction is scope and persistence.

A stolen session normally provides access to one service until that session expires or is revoked. Unit 42 demonstrated ways to obtain reusable authentication across multiple passkey-protected accounts, including accounts requiring user verification. Its most serious attack extracts the master secret protecting all existing synced passkeys and any passkeys added later.

The first attack uses Chrome’s TPM-backed device identity key. Malware can copy the wrapped key material and ask the victim’s TPM to sign an attacker-controlled authentication request without administrator privileges, device unlock or user interaction. The cloud authenticator then treats the request as coming from the trusted device.

This attack generally fails when a website correctly requires and validates WebAuthn’s user-verification flag. Unit 42 found some services that did not perform that validation correctly. eBay reportedly fixed the issue after disclosure.

The second attack manipulates Chrome’s device-onboarding process and registers an attacker-controlled user-verification key. Google’s cloud authenticator accepted the replacement key without verifying that it came from secure hardware. The attacker could then authenticate remotely without continued access to the infected computer.

The third attack is the most serious. During device re-registration, Chrome temporarily exposes the security-domain secret used to encrypt synced passkeys. Google removed that secret from Chrome’s diagnostic logs after the researchers reported it, but Unit 42 says it remains available in Chrome’s process memory.

With that secret, malware can decrypt every synced passkey in Chrome’s local database. The researchers say the secret currently cannot be rotated or revoked, providing access to both existing and future passkeys protected by it.

That is why this matters even on a computer that is already compromised.

Passkeys are designed so private keys remain controlled by the authenticator and authentication requires user presence or verification. Google also tells users that passkeys cannot be copied and that using one proves access to an unlocked device.

Unit 42 found gaps between those promises and one real implementation. Hardware-backed keys provided little protection when ordinary malware could ask the TPM to sign arbitrary requests, onboarding accepted an unattested verification key and the cloud-protected master secret was returned to the client.

Passkeys remain substantially more resistant to phishing and password reuse. This research does not invalidate the standard. It demonstrates that synced passkeys depend on credential managers, recovery systems, device enrollment and websites validating every part of the authentication response correctly.

The researchers recommend strict validation of the user-verification flag, hardware attestation for newly registered device keys, stronger onboarding protections and keeping master key material out of client memory. Unexpected Google Password Manager recovery prompts may also indicate that local passkey state has been manipulated.

Read “Pass the Passkey: A Novel Attack Surface in Passwordless Authentication.”