Threat reportThreat IntelligenceTL-2026-1886
Pass-ta-Key Attacks Let Malware Hijack Google Password Manager Synchronized Passkeys (Chrome on Windows)
Pass-ta-Key Attacks Let Malware Hijack Google Password (TL-2026-1886), also tracked as Pass-ta-Key Attacks, is a high-severity tracked intrusion set, first published 2026-08-05. It has no confirmed attribution, affects Google Chrome, maps to 15 MITRE ATT&CK techniques (T1005, T1055, T1057), and is covered by 9 detection rules and 10 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 15MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 10Indicators of compromise
Key facts for TL-2026-1886
- Threat ID
- TL-2026-1886
- Also known as
- Pass-ta-Key Attacks, Silver Pass-ta-Key, Golden Pass-ta-Key
- Severity
- HIGH
- Status
- ACTIVE
- Category
- THREAT_INTEL
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- FINANCIAL
- Target sectors
- all
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 10
How Pass-ta-Key Attacks Let Malware Hijack Google Password works
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.
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 techniques used in TL-2026-1886
Collection
T1005 Data from Local System; T1560 Archive Collected Data
Defense Evasion
T1055 Process Injection; T1070.004 File Deletion
Discovery
T1057 Process Discovery; T1082 System Information Discovery
Command and Control
T1071.001 Web Protocols; T1573.001 Symmetric Cryptography
Execution
T1106 Native API; T1204.002 Malicious File
Credential Access
T1528 Steal Application Access Token; T1552.001 Credentials In Files; T1555.003 Credentials from Web Browsers; T1555.005 Password Managers; T1606 Forge Web Credentials
Affected products and versions in Pass-ta-Key Attacks Let Malware Hijack Google Password
- Google — Chrome
Vulnerable versions: All versions prior to August 2026 patch cycle (no complete fix released as of publication) - Google — Google Password Manager
Vulnerable versions: All implementations with synchronized passkey functionality on Windows - Microsoft — Windows
Vulnerable versions: Windows 10; Windows 11
Remediation for Pass-ta-Key Attacks Let Malware Hijack Google Password
Immediate actions
- Change Google Password Manager PIN to invalidate cached secret access
- Review all accounts using passkeys via Google Password Manager; consider rotating credentials
- Use endpoint detection tools to monitor for Chrome process memory dumping
- Monitor for deletion or modification of passkey_enclave_state file
- Enable anti-malware with behavioral detection for CNG API abuse patterns
Workarounds
- Use platform authenticator (Windows Hello) instead of Google Password Manager for passkey storage
- Use a hardware security key (FIDO2/CTAP2) as a roaming authenticator not subject to sync layer attacks
- Disable passkey sync in Google Password Manager settings
- Remove the passkey_enclave_state file and re-enroll all devices if compromise is suspected (note: SDS may remain compromised)
Longer-term hardening
- Google must implement SDS rotation and revocation mechanisms in the cloud authenticator
- Google should never send the SDS to the client device; cryptographic operations should be server-side only
- Cloud authenticator must validate UV key attestation to ensure hardware-backed origin
- Chrome should restrict LevelDB sync database and passkey_enclave_state access to the browser process only via platform access controls
- Implement coordinated signature counters that account for multi-device sync consistency
- Relying parties must set userVerification to required AND validate the UV flag bit in authenticator data
Weaknesses (CWE) in Pass-ta-Key Attacks Let Malware Hijack Google Password
Timeline of Pass-ta-Key Attacks Let Malware Hijack Google Password
- Unit 42 (Palo Alto Networks) begins reverse-engineering Google's Cloud Authenticator architecture, including the Noise protocol, Oak execution environment, TPM key management, and SDS distribution flow
- Unit 42 discovers the full architectural details of Google's cloud authenticator, identifying key attack surfaces: device identity key accessible to unprivileged processes via CNG APIs, deferred UV key creation mechanism, attestation-free UV key registration, and SDS exposure in Chrome FIDO logs
- Unit 42 successfully demonstrates all three attack variants against live services. Pass-ta-Key succeeds against eBay (which did not validate the UV flag) and a messaging application; Silver Pass-ta-Key demonstrates persistent authenticated access from an attacker-controlled device; Golden Pass-ta-Key extracts the SDS from Chrome process memory and decrypts all synced passkey private keys
- Unit 42 responsibly discloses all three attack variants to Google's security team and to affected relying parties including eBay
- eBay addresses the UV flag validation gap after Unit 42's disclosure, now properly validates the User Verified bit in authenticator data
- Google removes the Security Domain Secret (SDS) from Chrome's FIDO logging output (chrome://device-log/FIDO) via Chromium Issue 464305542. This fixes one exposure vector but does not close the Golden Pass-ta-Key path because the SDS still reaches the client in plaintext during recovery
- BleepingComputer publishes coverage of the Pass-ta-Key attacks, noting Google did not respond to requests for comment on whether all three attack paths have been closed
- Unit 42 publishes 'Pass the Passkey: A Novel Attack Surface in Passwordless Authentication' disclosing the three attack variants, and the companion architecture deep-dive 'Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication'; no CVE assigned
- 9to5Google publishes coverage noting the attacks require pre-existing malware and that residual SDS data remains in Chrome's process memory even after the log exposure fix
- No complete patch or SDS rotation mechanism has been released by Google. No CVE assigned. Google's support documentation allows users to change their Password Manager PIN or delete all Password Manager data, but does not describe an SDS-specific rotation or revocation control. All synced passkeys protected by Google Password Manager remain affected
- Malwarebytes publishes analysis recommending that service providers stop blindly trusting the user verification flag and harden device registration and recovery processes
Sources cited for Pass-ta-Key Attacks Let Malware Hijack Google Password
- Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (Unit 42 Primary Research)
- Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication (Unit 42 Architecture Deep-Dive)
- New Pass-ta-key attacks let malware hijack Google-synced passkeys (BleepingComputer)
- Google's synchronized passkeys can be stolen in 'Pass-ta-key' attacks (Malwarebytes)
- Google Password Manager Attacks Could Let Malware Hijack Synced Passkeys (The Hacker News)
- Google passkeys put at risk by 'Pass-ta-key' attack (9to5Google)
- Chromium Issue 40274370 — Add client for Enclave-based passkey auth
- Chromium Issue 464305542 — SDS exposed in Chrome FIDO device logs (chrome://device-log/FIDO)
- Chromium Issue 465359916 — Globally consistent signature counters in synchronized passkey systems
- Chromium Issue 434977743 — Master key that encrypts all passkeys accessible in Chrome memory
- Chromium Issue 398125799 — TPM key naming TODO for Chrome identity keys
- Project Oak — Confidential computing environment for cloud authenticator (GitHub)
Detection coverage for TL-2026-1886
As of 2026-08-05, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1886 across Splunk SPL, Microsoft KQL and Sigma, covering 10 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.