# Pass-ta-key: Novel Attack Surface in Google Password Manager Synced Passkey Authentication

> Unit 42 (Palo Alto Networks) disclosed the 'Pass-ta-key' attack family — three novel variants exploiting design flaws in Google Password Manager's cloud authenticator architecture for synced passkeys in Chrome on Windows with TPM. All three variants enable malware on a compromised device to silently extract and replay passkey credentials without privilege escalation, user interaction, or device unlock. The Golden variant extracts the 32-byte Security Domain Secret (SDS) master key from Chrome's process memory, enabling offline decryption of all synced passkeys past and future with no rotation mechanism available.

- **Published:** 2026-08-03T00:00:00Z
- **Last reviewed:** 2026-08-10T13:20:01.549Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1842
- **ID:** TL-2026-1842
- **Severity:** CRITICAL (CVSS 6.5)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 18 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-34348

## Description

Unit 42 researchers identified a class of attacks against Google Password Manager's cloud-based passkey synchronization architecture in Chrome on Windows (TPM-equipped systems). The attacks exploit fundamental design gaps in how the Google Cloud Authenticator handles device identity keys, user verification (UV) key registration, and the Security Domain Secret (SDS) master key lifecycle. All three variants operate without elevated privileges — standard Windows CNG API calls from an unprivileged process suffice.

**Architecture Background:** Google Password Manager syncs passkeys across devices via a cloud authenticator running in an Oak execution environment. Chrome establishes a Noise_NK_P256_AESGCM_SHA256 encrypted WebSocket to wss://enclave.ua5v.com/enclave, authenticated via OAuth2. The local device holds two TPM-backed keys: an identity key (proving device possession) and a UV key (proving user verification via Windows Hello biometric/PIN). A 32-byte Security Domain Secret (SDS) master key encrypts all synced passkey private keys, stored on-device as a cloud-authenticator-wrapped opaque blob.

**Attack 1 — Pass-ta-key (Identity Key Exploitation):** Chrome creates the TPM identity key without a key name, causing Windows to treat it as ephemeral. Chrome then calls NcryptExportKey to export it as an NCRYPT_OPAQUE_KEY_BLOB, stored as wrapped_identity_private_key in the passkey_enclave_state file. Malware extracts this blob from disk or Chrome memory and replays standard Windows CNG API calls (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign authentication requests to the Cloud Authenticator. The cloud authenticator returns a valid assertion — the sole difference being the User Verified (UV) flag bit is unset. Relying parties that fail to validate the UV bit (eBay was confirmed vulnerable; GitHub properly enforced it) accept the forged assertion, enabling silent account takeover. eBay fixed the UV validation gap after coordinated disclosure.

**Attack 2 — Silver Pass-ta-key (UV Key Substitution):** Malware forces device re-onboarding by deleting passkey_enclave_state or issuing a device/forget command to the cloud authenticator (no access control on this operation). During re-onboarding, Chrome on Windows defers UV key creation to avoid back-to-back PIN prompts, registering the device in a uv_key_pending state. The attacker generates their own asymmetric key pair and sends a device/add_uv_key command to the cloud authenticator with the attacker-controlled public key. Critically, the cloud authenticator does not validate attestation for newly registered UV keys — it accepts any key as legitimate. This gives the attacker a permanent, reusable authentication mechanism from their own environment, even for accounts where relying parties properly enforce user verification. Unlike the basic Pass-ta-key, this bypass works regardless of UV flag validation.

**Attack 3 — Golden Pass-ta-key (SDS Master Key Extraction):** The most severe variant. The attacker triggers device re-onboarding (same mechanism as Silver), then monitors Chrome's process memory for the SDS — a 32-byte symmetric master key that decrypts all synced passkey private keys. The SDS reaches Chrome's process memory in plaintext because Google Password Manager must obtain the master key locally on iOS and Android (where no cloud authenticator is used), and Chrome follows the same recovery model on desktop. Additionally, Unit 42 found the SDS was exposed in plaintext in Chrome's device logs accessible at chrome://device-log/FIDO. Google removed this log exposure after disclosure (Issue 464305542), but the SDS remains accessible in Chrome's process memory during device onboarding. With the SDS in hand, an attacker decrypts the encrypted_private_key fields from WebauthnCredentialSpecifics records in Chrome's sync LevelDB database, recovering all passkey private keys. These keys can authenticate from the attacker's own environment without any further access to the victim's device. Critically, Google's current implementation provides no mechanism to rotate or revoke the SDS — all existing and future passkeys for the account remain decryptable.

**Related Research — CVE-2026-34348 (Windows WebAuthN Logging):** SpecterOps independently disclosed a related vulnerability where Windows 11 (and other versions) wrote complete WebAuthn assertion payloads including challenge, authenticatorData, signature, userHandle, and credential ID to the Windows Event Log (Event ID 2106, Microsoft-Windows-WebAuthN/Operational). An attacker with local log access could replay these assertions against relying parties without replay detection (including Microsoft Entra ID/login.microsoft.com). Microsoft patched on July 14, 2026, truncating logged signatures to 6 bytes. This research, presented at Black Hat USA 2026, is part of the broader 'Pass-the-Passkey' family of attacks on passkey authentication systems.

**Current Status:** As of August 3, 2026, Google has addressed the SDS log exposure but the core design vulnerabilities remain unfixed: TPM identity keys remain exportable, UV key registration lacks attestation validation, and there is no SDS rotation mechanism. The three Pass-ta-key attacks have no CVE identifiers assigned.

## MITRE ATT&CK

- T1555 Credentials from Password Stores
- T1555.003 Credentials from Web Browsers
- T1552.001 Credentials In Files
- T1552.004 Private Keys
- T1528 Steal Application Access Token
- T1212 Exploitation for Credential Access
- T1098.005 Device Registration
- T1548 Abuse Elevation Control Mechanism
- T1055 Process Injection
- T1005 Data from Local System
- T1119 Automated Collection
- T1572 Protocol Tunneling
- T1566.001 Spearphishing Attachment
- T1204.002 Malicious File
- T1531 Account Access Removal
- T1496 Resource Hijacking
- T1111 Multi-Factor Authentication Interception
- T1556.006 Modify Authentication Process: Multi-Factor Authentication
- T1078.004 Valid Accounts: Cloud Accounts
- T1106 Native API
- T1550.001 Use Alternate Authentication Material: Application Access Token

## Sources

- [Pass the Passkey: A Novel Attack Surface in Passwordless Authentication](https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/)
- [Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication](https://unit42.paloaltonetworks.com/passwordless-authentication/)
- [Malware Can Steal Your Google Synced Passkey Without Asking for Your Password or Fingerprint](https://cybersecuritynews.com/google-synced-passkey-malware-attack/)
- [Google Password Manager Attacks Could Let Malware Steal Synced Passkeys](https://thehackernews.com/2026/08/google-password-manager-attacks-could.html)
- [CVE-2026-34348 - Windows Event Logging Service Information Disclosure Vulnerability](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-34348)
- [NVD Detail - CVE-2026-34348](https://nvd.nist.gov/vuln/detail/CVE-2026-34348)
- [SpecterOps - Pass-the-Passkey Family of Attacks (Black Hat USA 2026)](https://specterops.io/wp-content/uploads/sites/3/2026/07/Pass-the-Passkey_A4_v2.pdf)
- [Chromium Issue 464305542 - SDS Exposure in chrome://device-log/FIDO](https://issuetracker.google.com/issues/464305542)
- [Chromium Issue 464996836 - Cloud Authenticator UV Key Attestation](https://issues.chromium.org/issues/464996836)
- [Chromium Issue 465359916 - Signature Counter Limitations in Synced Passkey Systems](https://issues.chromium.org/issues/465359916)
- [Chromium Commit cbf35bf - GPM Enclave Controller State Changes](https://github.com/chromium/chromium/commit/cbf35bf0d598cc329da274bda68ee02afcfa7074)

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