# Pass-ta-Key Attacks Let Malware Hijack Google Password Manager Synchronized Passkeys (Chrome on Windows)

> Unit 42 (Palo Alto Networks) disclosed three attack variants — Pass-ta-Key, Silver Pass-ta-Key, and Golden Pass-ta-Key — that allow unprivileged malware on a Windows device with TPM to compromise Google Password Manager synchronized passkeys in Chrome. The Golden variant extracts the 32-byte Security Domain Secret (SDS) master key from Chrome process memory, enabling decryption of all current and future synced passkey private keys with no rotation or revocation mechanism available. The attacks undermine the phishing-resistant promise of passkeys by attacking the synchronization layer and device-trust architecture rather than breaking the underlying WebAuthn/FIDO2 cryptography.

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

## Description

Passkeys are phishing-resistant cryptographic credentials based on the WebAuthn and FIDO2 standards in which a per-account asymmetric key pair (P-256 ECDSA) is generated on the user's device and the private key never leaves the authenticator. Google Password Manager (GPM) extends this model with a cloud authenticator that synchronizes passkeys across devices: passkey private keys are encrypted under a 32-byte symmetric Security Domain Secret (SDS) master key, the SDS itself is encrypted per-device as a wrapped_secret using a device-specific wrapping key held only by the cloud authenticator, and encrypted passkey records are stored as WebauthnCredentialSpecifics protobuf entries in Chrome's LevelDB sync database at %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. Device identity is established via two TPM-backed keys — a device identity key (represents 'something you have') and a user verification (UV) key (gated by Windows Hello biometric or PIN) — accessed through Windows CNG API calls (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash with MS_PLATFORM_CRYPTO_PROVIDER). Chrome communicates with the cloud authenticator at wss://enclave.ua5v.com/enclave via the Noise_NK_P256_AESGCM_SHA256 protocol over an OAuth2-authenticated WebSocket, with the cloud authenticator running in Google's Oak confidential computing environment with attestation signatures.

Pass-ta-Key (Basic Account Takeover): Malware running at standard user privilege reads the wrapped_identity_private_key from the passkey_enclave_state file on disk, loads it into the TPM via NCryptImportKey, and calls NCryptSignHash to sign a WebSocket authentication request to the cloud authenticator. The cloud authenticator accepts the signed request as coming from a trusted device, returning a valid WebAuthn assertion — without requiring device unlock, biometrics, PIN entry, or any user interaction. The only difference from a legitimate user-verified assertion is a single unset bit: the User Verified (UV) flag in the authenticator data. Relying parties that set userVerification to 'required' but fail to validate the UV flag in the returned assertion are vulnerable. Unit 42 demonstrated this against eBay, which accepted the assertion despite requesting userVerification:required; GitHub correctly validated the UV flag and rejected the attack. eBay fixed the validation gap after responsible disclosure.

Silver Pass-ta-Key (UV Key Bypass): This variant targets the deferred UV key creation mechanism. During device re-onboarding, Chrome enters a uv_key_pending state — the GPM recovery PIN satisfies user verification for the first passkey use, and actual UV key creation is deferred to the next passkey use. Malware forces device re-onboarding by either sending a device/forget command signed with the device identity key or by directly deleting the passkey_enclave_state file (no platform access controls prevent this). The attacker then registers their own asymmetric key pair as the device's UV key by sending a device/add_uv_key command to the cloud authenticator. Critically, the cloud authenticator does not validate attestation or verify that the new UV key originates from secure hardware-backed TPM storage. The device record becomes {hw: identity_public_key, uv: attacker_controlled_public_key}, allowing the attacker to obtain assertions with the UV flag set from any machine, without needing the victim's device to be online.

Golden Pass-ta-Key (Master Key Extraction): The most severe variant. Malware forces Chrome to re-onboard (same mechanism as Silver) then monitors for recreation of the passkey_enclave_state file. During the recovery flow, the SDS is temporarily present in plaintext in Chrome's process memory. The attacker dumps Chrome's process memory and extracts the 32-byte SDS by pattern matching. With the SDS in hand, the attacker reads all WebauthnCredentialSpecifics records from Chrome's LevelDB sync database and decrypts every encrypted passkey private key. The recovered private keys can be used from any system to sign relying party challenges, enabling full account takeover of every passkey-protected service. Crucially, Google's current implementation provides no mechanism to rotate or revoke the SDS — all current AND future synchronized passkeys remain decryptable with the same extracted master key. The recovered private keys can also be shared or sold on credential black markets, representing a permanent compromise.

Google removed an earlier exposure of the SDS in plaintext from Chrome's FIDO device logs (chrome://device-log/FIDO) after Unit 42 disclosed it (Chromium Issue 464305542), but this does not close the attack path because the SDS still reaches the client during recovery and remains accessible in Chrome's process memory. Google acknowledged that globally consistent signature counters are difficult to implement in synced passkey systems (Chromium Issue 465359916). As of publication, no CVE has been assigned and no complete remediation has been released. The attacks do not break passkey cryptography itself but exploit weaknesses in how Chrome and the cloud authenticator handle device trust, onboarding, recovery, and synced credentials — all without requiring elevated privileges, user interaction, biometrics, or device unlock.

## MITRE ATT&CK

- T1555.003 Credentials from Web Browsers
- T1555.005 Password Managers
- T1552.001 Credentials In Files
- T1528 Steal Application Access Token
- T1606 Forge Web Credentials
- T1106 Native API
- T1204.002 Malicious File
- T1070.004 File Deletion
- T1055 Process Injection
- T1057 Process Discovery
- T1082 System Information Discovery
- T1005 Data from Local System
- T1560 Archive Collected Data
- T1573.001 Symmetric Cryptography
- T1071.001 Web Protocols

## Sources

- [Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (Unit 42 Primary Research)](https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/)
- [Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication (Unit 42 Architecture Deep-Dive)](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's synchronized passkeys can be stolen in 'Pass-ta-key' attacks (Malwarebytes)](https://www.malwarebytes.com/blog/news/2026/08/googles-synchronized-passkeys-can-be-stolen-in-pass-ta-key-attacks)
- [Google Password Manager Attacks Could Let Malware Hijack Synced Passkeys (The Hacker News)](https://thehackernews.com/2026/08/google-password-manager-attacks-could.html)
- [Google passkeys put at risk by 'Pass-ta-key' attack (9to5Google)](https://9to5google.com/2026/08/04/google-password-manager-passkeys-could-be-at-risk/)
- [Chromium Issue 40274370 — Add client for Enclave-based passkey auth](https://issues.chromium.org/issues/40274370)
- [Chromium Issue 464305542 — SDS exposed in Chrome FIDO device logs (chrome://device-log/FIDO)](https://issuetracker.google.com/issues/464305542)
- [Chromium Issue 465359916 — Globally consistent signature counters in synchronized passkey systems](https://issues.chromium.org/issues/465359916)
- [Chromium Issue 434977743 — Master key that encrypts all passkeys accessible in Chrome memory](https://issues.chromium.org/issues/434977743)
- [Chromium Issue 398125799 — TPM key naming TODO for Chrome identity keys](https://issues.chromium.org/issues/398125799)
- [Project Oak — Confidential computing environment for cloud authenticator (GitHub)](https://github.com/project-oak/oak)

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