Google Password Manager Passkey Flaws Allow Silent Account Hijacking

Passkey technology was designed to eliminate phishing and credential theft, but implementation weaknesses in client authenticators can still leave synced accounts vulnerable to endpoint compromise. Security researchers at Palo Alto Networks Unit 42 have detailed three distinct post-compromise attack techniques targeting the Google Password Manager passkey implementation in Chrome on Windows systems equipped with a Trusted Platform Module (TPM).

The findings showcase how local malware running under an ordinary user account can bypass user verification prompts, register unauthorized verification keys, or extract master secrets to achieve persistent access to passkey-protected accounts. Dubbed Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key, these Chrome passkey attacks exploit architectural gaps in how local credential state is managed, how device re-enrollment is validated, and how WebAuthn assertions are verified by web services.

Local Reconnaissance and the Pass-ta-key Vector

Every path begins after malware has already gained execution rights on a victim’s Windows endpoint. The malware conducts local reconnaissance by reading Chrome’s sync database located at %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. Although the passkey private keys stored here are encrypted, an unprivileged process can read enough metadata to identify relying party domains, target usernames, credential identifiers, and encrypted private key structures.

The first technique, Pass-ta-key, targets Chrome’s wrapped device identity key. To avoid persisting TPM key names to disk, Chrome creates its TPM key without a key name—a design detail tracked in Chromium issue 398125799—and exports it as an opaque blob. When reloading this key, Chrome suppresses user prompts.

Malware can extract this key blob and issue standard Windows Cryptography API: Next Generation (CNG) calls to request that the local TPM sign a WebAuthn assertion payload. Because no biometric scanning or PIN entry occurred, the assertion returned by Google Cloud Authenticator has its User Verified (UV) flag set to false.

Whether this vector succeeds depends on how strictly the target service enforces the WebAuthn standard:

• Compliant Services: Web services that require user verification (userVerification: "required") must reject assertions lacking the UV bit. During testing, GitHub strictly enforced this requirement and successfully blocked forged logins.
• Non-Compliant Services: Services that fail to validate the UV flag accept the assertion despite the missing human check. Testing showed that eBay initially accepted test assertions produced without user interaction until fixing its validation logic following vulnerability disclosure.

Out-of-Band Persistence via Key Substitution

The second vector, Silver Pass-ta-key, elevates the attack from local assertion forgery to remote, out-of-band persistent access. Malware triggers a forced device re-enrollment within Chrome. During re-enrollment, Chrome enters a temporary state (deferred_uv_key_creation) before generating its official user-verification key.

Malware can exploit this window to register an attacker-controlled user-verification key with Google Cloud Authenticator. Because the cloud authentication service does not enforce hardware attestation checks on newly registered keys, it accepts the attacker’s key.

Assertions signed using this substituted key carry a valid UV flag. As a result, the attacker can sign into the victim’s passkey-protected accounts directly from their own external infrastructure, bypassing both the victim’s physical device and any requirement for local user presence.

Theft of the Security Domain Secret

The third and most dangerous vector, Golden Pass-ta-key, targets the underlying master secret protecting synchronized credentials across the user’s Google account. Chrome uses a 32-byte Security Domain Secret (SDS) to decrypt synced passkey private keys.

When malware forces Chrome through a re-enrollment routine, the SDS briefly passes through client process memory in plaintext. By scanning Chrome’s process memory during this re-enrollment window, malware can scrape the 32-byte secret directly.

With the SDS extracted, an attacker gains offline decryption capabilities for the user’s entire vault of synchronized passkey private keys. While Google previously updated Chrome to prevent the SDS from being written to client FIDO logs, the secret still enters client memory during active decryption operations, leaving it exposed to process-scraping techniques.

Realistic Blast Radius and Enterprise Risk

Passkeys significantly raise the bar against remote credential harvesting, but these research findings highlight a critical risk for enterprise defense teams: post-compromise persistence.

In a traditional session-hijacking scenario, clearing cookies or revoking an active session token terminates an attacker’s access. Under the Silver and Golden Pass-ta-key techniques, an endpoint infection allows attackers to establish persistent credential access that outlasts the initial malware cleanup:

1. Key Substitution Persistence: Silver Pass-ta-key gives attackers valid, user-verified key pairs that persist independently of the host machine.
2. Master Secret Compromise: Golden Pass-ta-key compromises the SDS. Current public documentation for Google Password Manager allows users to change their PIN or wipe local data, but it remains unconfirmed whether changing a PIN invalidates an SDS that an attacker has already extracted.

For organizations relying on passkey deployment for zero-trust access, the blast radius of a single compromised endpoint expands from temporary browser session theft to long-term account takeover across all relying parties synced to that Google account.

Defensive Guidance and Mitigation

Remediating these vulnerabilities requires coordinated controls across web application developers, credential providers, and enterprise security operations.

For Relying Parties (Web Developers)

• Strictly Enforce UV Verification: WebAuthn server implementations must set userVerification to "required" for sensitive authentication flows.
• Validate Returned Assertions: Ensure server-side authentication handlers explicitly check that the returned assertion’s UV bit is set to 1. Relying solely on client-side prompt requests is insufficient.

For Credential Providers and Platform Vendors

• Enforce Hardware Attestation: Cloud authenticators must mandate hardware attestation when enrolling or updating user-verification keys to block remote key-substitution attacks.
• Harden Local Memory and State: Protect transient client process memory containing master keys like the 32-byte SDS, and restrict unprivileged process access to local browser profile databases.
• Provide Master Secret Revocation Controls: Enable explicit rotation mechanisms for master encryption keys so users can invalidate compromised SDS tokens when changing account credentials or responding to an endpoint breach.

For Enterprise Security Teams

Because all three attack paths depend on executing local code, enterprise defenses should focus on preventing initial execution on Windows endpoints through application control, prompt endpoint detection and response (EDR) isolation, and limiting local unprivileged process capabilities.