# Pass-ta-key Attacks Enable Malware to Hijack Google-Synced Passkeys via Chrome/TPM/Google Cloud Authenticator Weaknesses

> Unit 42 (Palo Alto Networks) disclosed three novel post-compromise attacks collectively called 'Pass-ta-key' targeting Google Password Manager (GPM) in Chrome on Windows devices with a Trusted Platform Module (TPM). The attacks — Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key — allow unprivileged malware on an already-compromised device to impersonate a trusted device (bypassing user verification), register attacker-controlled keys with the cloud authenticator, and extract the Security Domain Secret (SDS) master key from Chrome process memory to decrypt all synced passkey private keys. The SDS has no rotation or revocation mechanism, exposing all current and future synced passkeys. eBay was confirmed vulnerable (UV flag validation bypass, since fixed); GitHub properly validated the flag and was not vulnerable. No CVEs were assigned as of publication.

- **Published:** 2026-08-03T00:00:00Z
- **Last reviewed:** 2026-08-03T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1852
- **ID:** TL-2026-1852
- **Severity:** HIGH
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 8 (full data via the Threadlinqs MCP server — Purple tier)

## Description

On August 3, 2026, Palo Alto Networks' Unit 42 published 'Pass the Passkey: A Novel Attack Surface in Passwordless Authentication,' the third installment in a research series examining the security of passwordless authentication. The research identifies three attack classes against Google's synced passkey ecosystem, specifically targeting Google Password Manager in Chrome on Windows platforms with TPM-equipped devices. All three attacks are post-compromise techniques requiring malware already running on the victim's device with no elevated privileges needed.

The first attack, Pass-ta-key (device identity impersonation), exploits the Google Cloud Authenticator's inability to distinguish between requests signed with the TPM-backed identity key versus the user verification (UV) key. Chrome creates the TPM identity key via NcryptCreatePersistedKey without a key name (pszKeyName == NULL, Chromium issue #398125799), making the key ephemeral and exportable. Chrome exports the key as an opaque blob via NcryptExportKey (NCRYPT_OPAQUE_KEY_BLOB, encrypted by a TPM-resident key) and stores it as wrapped_identity_private_key in the passkey_enclave_state file. Malware extracts this blob from disk or Chrome process memory and invokes standard Windows CNG APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign authentication requests — all without privilege escalation, mimicking Chrome's own API pattern. The cloud authenticator returns a valid assertion regardless of whether the identity key or UV key signed it; the only difference is the UV flag bit in the authenticator data (0 for identity key, 1 for UV key). Relying parties that fail to validate the UV flag accept the assertion. The researchers demonstrated this against eBay, which configured userVerification=required but did not validate the UV flag in the authenticator data, allowing full account takeover without user interaction, biometrics, or device unlock. eBay fixed the issue after disclosure. GitHub properly validates the UV flag and rejects such assertions with an error message.

The second attack, Silver Pass-ta-key (user verification bypass), exploits gaps in the device re-registration workflow. The attacker forces Chrome to re-onboard the device by either issuing a device/forget command to the cloud authenticator (signed with the identity key the attacker already controls) or directly deleting the victim's passkey_enclave_state file — which has no built-in protections against removal. On Windows, device onboarding completes in two stages: the first passkey use creates TPM keys and starts background onboarding while prompting for the GPM recovery PIN, but Chrome defers UV key creation to avoid confusing users with back-to-back PIN prompts, entering a uv_key_pending state. The cloud authenticator accepts a UV key registration without hardware attestation during this window. The attacker generates an asymmetric key pair in their own environment and sends a device/add_uv_key command to the cloud authenticator, registering their own public key. The cloud authenticator does not validate whether the new UV key originates from secure hardware; it simply stores the attacker's public key. After registration, the attacker can sign assertion requests with their forged UV key, setting the UV flag to 1, and authenticate from their own environment without further access to the victim's device. This enables full automated account takeover across all passkey-protected accounts.

The third and most severe attack, Golden Pass-ta-key (master key extraction), targets the Security Domain Secret (SDS) — a 32-byte symmetric master key used to encrypt all synced passkey private keys. When a device joins or rejoins an account's security domain, Chrome retrieves the SDS from Google's Trusted Vault service. The cloud authenticator includes a mechanism allowing Chrome to facilitate recovery where the key cannot be decrypted on the client device, but Chrome does not use this mechanism — it recovers the SDS in accessible form. The researchers initially found the SDS in plaintext in Chrome's FIDO logs at chrome://device-log/FIDO (Chromium Issue #464305542). After disclosure, Google removed the SDS from logging output. However, the SDS still reaches the client during device onboarding and remains in Chrome's process memory. An attacker who forces re-registration by deleting passkey_enclave_state can monitor the filesystem for recreation, dump Chrome's process memory, and extract the SDS. With the SDS, the attacker reads WebauthnCredentialSpecifics proto-encoded records from Chrome's sync database at %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB and decrypts the encrypted private key fields. This recovers all passkey private keys. Critically, Google's implementation provides no mechanism to rotate or revoke the SDS — all current and future synced passkeys remain protected by the same master key. Even if compromise is detected, remediation is limited. The attacker can authenticate from any device as a fully verified user to any service where the victim uses passkeys.

Root cause analysis spans multiple layers: the cloud authenticator's trust model does not validate UV key attestation (Silver); the SDS is unnecessarily exposed to the client environment (Golden); Chrome stores sensitive passkey state in files accessible to unprivileged processes (all attacks); Chrome's TPM identity key is created without a persistent name, enabling opaque blob extraction (Pass-ta-key); and the cloud authenticator does not enforce user verification at the cryptographic level, relying on a single UV flag bit whose validity depends on the relying party's validation. The Chromium source code reference for the enclave manager is at chrome/browser/webauthn/enclave_manager.h. The cloud authenticator operates at enclave.ua5v.com over WebSocket (wss://enclave.ua5v.com/enclave) using the Noise_NK_P256_AESGCM_SHA256 protocol, with OAuth2 tokens scoped to https://www.googleapis.com/auth/secureidentity.action. The protocol uses the NK pattern (client unauthenticated, server has a known static public key hard-coded in Chrome), P256 ECDH, AES-GCM encryption, and SHA256 hashing. No evidence of in-the-wild exploitation was found at publication.

## MITRE ATT&CK

- T1078 Valid Accounts
- T1098 Account Manipulation
- T1556 Modify Authentication Process
- T1055 Process Injection
- T1528 Steal Application Access Token
- T1555 Credentials from Password Stores
- T1552 Unsecured Credentials
- T1550 Use Alternate Authentication Material
- T1005 Data from Local System
- T1071 Application Layer Protocol

## Sources

- [Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (Unit 42)](https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/)
- [Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication (Unit 42)](https://unit42.paloaltonetworks.com/passwordless-authentication/)
- [New Pass-ta-key attacks let malware hijack Google-synced passkeys (BleepingComputer)](https://www.bleepingcomputer.com/news/security/new-pass-ta-key-attacks-let-malware-hijack-google-synced-passkeys/)
- [Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts (The Hacker News)](https://thehackernews.com/2026/08/google-password-manager-attacks-could.html)
- [Google Authenticator's Hidden Passkey Architecture Could Open New Passwordless Attack Paths (CyberSecurity News)](https://cybersecuritynews.com/google-authenticators-hidden-passkey-architecture/)
- [Google Cloud Authenticator & Passkey Attack — Detection Guidance (cyfar.ca)](https://cyfar.ca/posts/google-authenticator-the-hidden-mechanisms-of-passwordless-authentication)
- [Chromium Issue #464305542 — SDS exposure in Chrome FIDO device logs](https://issues.chromium.org/issues/464305542)
- [Chromium Issue #398125799 — Labeled TPM keys (unexportable_key_win.cc TODO)](https://issues.chromium.org/issues/398125799)
- [Chromium Source — enclave_manager.h (enclave/cloud authenticator manager)](https://chromium.googlesource.com/chromium/src/+/d38f5261e5518f1d2d49c3968164ce0f9a02d4d7/chrome/browser/webauthn/enclave_manager.h)
- [Chromium Source — webauthn_credential_specifics.proto](https://chromium.googlesource.com/chromium/src/+/main/components/sync/protocol/webauthn_credential_specifics.proto)
- [Microsoft NCryptCreatePersistedKey function (CNG API)](https://learn.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptcreatepersistedkey)
- [Advancing Key Protection in Windows Using VBS (Microsoft Tech Community)](https://techcommunity.microsoft.com/blog/windows-itpro-blog/advancing-key-protection-in-windows-using-vbs/4050988)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1852