Google Password Manager Flaw Allows Malware to Hijack Passkeys

Modern passwordless security relies on asymmetric cryptography to eliminate phishing and password reuse. Websites retain a public key while authenticators keep the private key secure. However, synchronizing passkeys across multiple authorized devices requires a complex surrounding ecosystem of encryption, cloud recovery, and device enrolment. Security researchers at Palo Alto Networks’ Unit 42 uncovered three attack techniques targeting this surrounding infrastructure in Google Chrome and Google Password Manager on Windows systems equipped with a Trusted Platform Module.

Pass-ta-key and the User-Verification Gap

The first technique, dubbed Pass-ta-key by Unit 42, extracts Chrome’s wrapped device identity key from an infected Windows computer. Malware then commands the local TPM to sign an attacker-controlled request using Windows Cryptography API: Next Generation calls. Current Chromium source code shows that Chrome creates this TPM key without a key name, which prevents it from being persisted to disk. Chrome subsequently exports the key as an opaque blob and reloads it under a flag that suppresses user prompts.

Google’s cloud authenticator returns a valid authentication assertion in response. The single distinguishing factor from a legitimate user login is the User Verified flag, which remains unset because no human touched the device. The current Web Authentication specification states that relying parties requiring user verification must fail the ceremony when that bit is missing. GitHub properly enforced this check, whereas eBay accepted test assertions until fixing the validation gap following disclosure.

Silver Pass-ta-key and Deferred Key Creation

The second attack path escalates the threat by forcing Chrome to re-enroll the compromised device. Known as Silver Pass-ta-key, this technique exploits a temporal window during device re-enrollment before Chrome creates its user-verification key. Malware can step into this gap and register an attacker-controlled user-verification key instead.

Google Launches Selfie Video Authentication for Account Recovery

Unit 42 researchers reported that the cloud service fails to verify whether newly registered keys originate from secure hardware. Consequently, assertions signed with these substituted keys carry the user-verification flag, enabling subsequent logins without physical access to the victim’s device. Current Chromium source files corroborate that newly registered devices can maintain a deferred_uv_key_creation state. However, public source code alone does not verify whether production servers remain susceptible to this key-substitution attack.

Golden Pass-ta-key and the Security Domain Secret

The most severe attack path targets the cryptographic core of Google’s synchronization architecture. Designated as Golden Pass-ta-key, this technique goes directly after the 32-byte Security Domain Secret, referred to as the SDS. Unit 42 explained that malware can trigger device re-enrollment and extract the secret out of Chrome’s process memory while it temporarily sits in plaintext.

Possession of the SDS allows attackers to decrypt existing synchronized passkey credentials and potentially future passkeys without maintaining continuous access to the victim’s computer. Current Chromium source code confirms that security domain secrets enter client-process data structures in memory. However, reliable extraction mechanics and persistence across future secret epochs remain attributed specifically to Unit 42’s findings rather than fully demonstrated in public repositories.

Post-Compromise Realities and Mitigations

Every demonstrated attack vector requires malware to be actively executing on the victim’s Windows computer before exploitation begins. Attackers typically perform local reconnaissance by scanning Chrome synchronized credential records located in LevelDB directories under local application data paths. These files contain metadata identifying relying parties, usernames, credential identifiers, and encrypted private-key material.

A search of the National Vulnerability Database found no matching CVE identifiers for the three named techniques. Furthermore, researchers found no evidence of real-world exploitation in the wild, and Unit 42 did not associate the findings with any specific threat actor group. To mitigate these risks, Unit 42 recommends that cloud authenticators enforce strict hardware attestation checks before accepting replacement user-verification keys during device re-enrollment.