# Google Password Manager — Three Post-Compromise Attack Paths Against Chrome Cloud Authenticator (Pass-ta-key / Silver Pass-ta-key / Golden Pass-ta-key)

> Unit 42 (Palo Alto Networks) disclosed three attack paths (Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key) targeting Chrome's Google Password Manager cloud authenticator on Windows with TPM. The strongest path recovers the 32-byte Security Domain Secret (SDS) from Chrome process memory to decrypt synced passkey private keys. All paths require prior device compromise. No in-the-wild exploitation observed.

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

## Description

Unit 42 (Palo Alto Networks) published research disclosing three novel attack paths collectively called the 'Pass-ta-key' family, targeting Google Password Manager's cloud authenticator implementation in Chrome on Windows devices with a Trusted Platform Module (TPM). The attacks were responsibly disclosed to Google prior to publication via issues.chromium.org and issuetracker.google.com.

Architecture Background: Google Password Manager on Chrome uses a cloud authenticator service at enclave.ua5v.com that establishes encrypted WebSocket sessions via the Noise_NK_P256_AESGCM_SHA256 protocol. Devices maintain two TPM-backed key pairs: an identity key ('something you have') for device authentication, and a User Verification (UV) key ('something you are') gated by Windows Hello biometrics/PIN. All synced passkey private keys are encrypted under a 32-byte Security Domain Secret (SDS), a symmetric master key generated during first-device onboarding and stored wrapped per-device. The cloud authenticator runs under AMD SEV-SNP using the Oak framework with reproducible builds.

Attack Path 1 — Pass-ta-key (Device Identity Impersonation): Malware extracts the TPM-wrapped identity private key from Chrome's passkey_enclave_state file (stored at %LocalAppData%\Google\Chrome\User Data\<Profile>\passkey_enclave_state) or from Chrome's process memory. It then uses standard Windows CNG APIs — NCryptOpenStorageProvider, NCryptImportKey, and NCryptSignHash — to sign authentication request hashes using the victim's TPM, all without elevated privileges or user interaction. The cloud authenticator returns a valid authentication assertion signed with the device identity key, which differs from a user-verified assertion only by the UV flag (a single bit in WebAuthn authenticator data). Relying parties that set userVerification to 'preferred' rather than 'required' accept this assertion. eBay initially accepted test assertions without the UV flag and fixed the validation gap after disclosure; GitHub correctly enforced the UV check from the start.

Attack Path 2 — Silver Pass-ta-key (Persistent UV-Bypassing Takeover): Rather than skipping UV verification, the attacker invalidates the legitimate UV key and registers their own. The attacker sends a device/forget command (signed with the stolen identity key) to the cloud authenticator, or simply deletes the passkey_enclave_state file — both methods force Chrome to re-onboard with the cloud service. During re-onboarding, Chrome enters a uv_key_pending state that defers UV key creation to avoid presenting two PIN prompts back-to-back. The attacker exploits this gap by generating their own asymmetric key pair and sending a device/add_uv_key command to the cloud authenticator. Critically, the cloud authenticator does not validate hardware attestation of newly registered UV keys, accepting arbitrary public keys. The attacker can then authenticate from their own environment without the victim's device being online, producing assertions fully indistinguishable from legitimate user-verified responses (UV flag = 1). This enables persistent, reusable access across all victim accounts.

Attack Path 3 — Golden Pass-ta-key (Master Key Extraction): The most severe attack targets the 32-byte Security Domain Secret (SDS) — the symmetric master key protecting all synced passkey private keys for the victim's Google account. Unit 42 discovered that the SDS was exposed in plaintext in Chrome's device log at chrome://device-log/FIDO during registration, simply by opening the diagnostic page. After disclosure (issuetracker.google.com/issues/464305542), Google removed the SDS from logging output, but the fundamental exposure remains: the SDS is still sent to the client in accessible form via Google's Trusted Vault service during device join/recovery, and it briefly resides in plaintext within Chrome's process memory. By forcing re-onboarding (via state file deletion), dumping Chrome's process memory to extract the SDS, then reading WebauthnCredentialSpecifics records from the Chrome sync database at %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, an attacker can decrypt all current and future synced passkey private keys. Critically, Google's implementation provides no mechanism to rotate or revoke the SDS, meaning a stolen SDS grants permanent access to all passkeys past, present, and future.

Chromium source code corroboration: The current Chrome source confirms that newly registered devices can retain a deferred_uv_key_creation state (enclave_local_state.proto) and that 32-byte security domain secrets are created in client-process memory data structures (enclave_manager.cc). A TODO in Chromium source references issue 398125799 proposing that TPM keys be labelled rather than created without names.

Remediation Status: Google removed the SDS from Chrome's device logs. eBay fixed its UV flag validation. Chromium has a pending fix for labelling TPM keys (issue 398125799). However, the SDS still reaches client memory, no SDS rotation mechanism exists, and the cloud authenticator still does not validate UV key attestation. No CVE was assigned as of publication, and no Chrome patch version has been confirmed to fully address all three paths.

## MITRE ATT&CK

- T1555 Credentials from Password Stores
- T1649 Steal or Forge Authentication Certificates
- T1003 OS Credential Dumping
- T1552 Unsecured Credentials
- T1685 Disable or Modify Tools
- T1098 Account Manipulation
- T1078 Valid Accounts
- T1556 Modify Authentication Process
- T1572 Protocol Tunneling
- T1606 Forge Web Credentials
- T1005 Data from Local System

## Sources

- [Pass the Passkey: A Novel Attack Surface in Passwordless Authentication](https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/)
- [The Hidden Mechanisms of Passwordless Authentication](https://unit42.paloaltonetworks.com/passwordless-authentication/)
- [Google Password Manager Attacks Could Let Attackers Decrypt Your Passkeys](https://thehackernews.com/2026/08/google-password-manager-attacks-could.html)
- [Chromium Issue — SDS Exposure in Chrome Device Logs](https://issuetracker.google.com/issues/464305542)
- [Chromium Issue — Enclave Authenticator Design Response](https://issues.chromium.org/issues/464996836)
- [Chromium Issue — Signature Counter Challenges in Synced Passkey Systems](https://issues.chromium.org/issues/465359916)
- [Chromium Source — enclave_manager.cc (Cloud Authenticator Client Manager)](https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/webauthn/enclave_manager.cc)
- [Chromium Source — enclave_local_state.proto](https://chromium.googlesource.com/chromium/src/+/main/chrome/browser/webauthn/proto/enclave_local_state.proto)
- [Chromium Source — webauthn_credential_specifics.proto](https://chromium.googlesource.com/chromium/src/+/main/components/sync/protocol/webauthn_credential_specifics.proto)
- [Chromium Issue — TPM Key Naming/labelling (TODO ref)](https://issues.chromium.org/issues/398125799)
- [Pass-the-Passkey Family of Attacks — SpecterOps Analysis](https://posts.specterops.io/pass-the-passkey-family-of-attacks/)
- [Vaultjacking: Phishing the Google Password Manager Vault](https://phishu.net/blogs/blog-vaultjacking-phishing-the-google-password-manager-vault-in-the-phishu-framework.html)

## 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-1843