top of page
perceptive_background_267k.jpg

Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts

Published:

3 augustus 2026 om 16:24:47

Alert date:

3 augustus 2026 om 17:01:09

Source:

thehackernews.com

Click to open the original link from this advisory

Identity & Access, Web Technologies, Operating Systems, Zero-Day Vulnerabilities

Unit 42 researchers have disclosed three attack paths against Chrome's Google Password Manager cloud authenticator that allow malware running as an ordinary user on Windows to silently sign into passkey-protected accounts. The attack chains are named Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key, with the most severe targeting the master key. No fingerprint, PIN, or user interaction is required for the attack to succeed. The vulnerability undermines the security guarantees of passkeys, which are generally considered phishing-resistant. This represents a significant threat to users who rely on Google Password Manager for passkey authentication across their accounts.

Technical details

Unit 42 (Palo Alto Networks) detailed three post-compromise attack paths against Chrome's Google Password Manager cloud authenticator, collectively named 'Pass-ta-key', 'Silver Pass-ta-key', and 'Golden Pass-ta-key'. All attacks require malware already running on the victim's Windows machine with TPM present, and none break passkey cryptography directly — instead they exploit weaknesses in the surrounding implementation.

1. **Pass-ta-key**: Malware extracts Chrome's wrapped TPM device identity key blob from local storage (%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB) and uses Windows CNG (NCryptSignHash) API calls to sign attacker-controlled requests without any user interaction. The TPM key is created without a key name (preventing persistence), exported as an opaque blob, and reloaded under a flag suppressing prompts. The resulting assertion lacks the User Verified (UV) flag. Sites enforcing userVerification=required (e.g., GitHub) reject it, but those that don't (e.g., eBay, prior to fix) accepted it.

2. **Silver Pass-ta-key**: Malware forces Chrome device re-enrollment, then registers an attacker-controlled user-verification key during the window before Chrome creates its own UV key (deferred_uv_key_creation state confirmed in Chromium source). Assertions signed with this key carry the UV flag, enabling persistent logins from the attacker's environment without the victim's device. The service reportedly does not verify hardware attestation for newly registered keys.

3. **Golden Pass-ta-key**: Malware triggers re-enrollment, then reads the 32-byte Security Domain Secret (SDS) from Chrome's process memory while it briefly exists in plaintext. The SDS can decrypt all synced passkey private keys, enabling account takeover and persistence. Google reportedly removed an earlier SDS exposure from Chrome's FIDO logs, but the secret still enters Chrome process memory. No CVE identifiers were assigned, and no exploits in the wild were reported as of August 3, 2026.

Mitigation steps:

1. **Relying Parties / Website Operators**: Set userVerification to 'required' in WebAuthn configuration AND verify the returned User Verified (UV) bit server-side rather than trusting the client request setting alone. Do not accept assertions where UV is absent when verification is required.
2. **Credential Providers / Google**: Require hardware attestation before accepting newly enrolled or replacement user-verification keys. Strengthen re-registration and recovery flow checks to prevent key substitution attacks. Restrict unprivileged process access to local passkey state in Chrome profile directories. Keep master keys and Security Domain Secrets (SDS) out of client logs and memory where possible.
3. **Users**: Be aware there is currently no documented SDS-specific rotation or revocation control. Google's public support page allows changing the Google Password Manager PIN or deleting all Password Manager data, but it is unconfirmed whether this invalidates an already-stolen SDS. Users who suspect device compromise should consider deleting all Password Manager data and re-enrolling passkeys. Monitor for Google updates regarding SDS invalidation procedures.
4. **Enterprise/Security Teams**: Prioritize endpoint security to prevent initial malware compromise, as all three attack paths require malware already running on the victim machine. Monitor for suspicious access to %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB. Watch for unusual NCryptSignHash or Windows CNG API calls from non-Chrome processes. Monitor Chrome process memory access by third-party processes.
5. **Chromium/Google Development**: Address the TODO in unexportable_key_win.cc (Chromium issue 398125799) to label TPM keys instead of using unnamed exportable blobs. Implement server-side hardware attestation checks for newly registered UV keys.

Affected products:

Google Chrome (Windows
with TPM) - Google Password Manager cloud authenticator
Google Password Manager (Chrome extension/built-in
synced passkeys)
Windows systems with Trusted Platform Module (TPM)

Related links:

Related CVE's:

Related threat actors:

IOC's:

This article was created with the assistance of AI technology by Perceptive.

© 2025 by Perceptive Security. All rights reserved.

email: info@perceptivesecurity.com

Deze website toont informatie afkomstig van externe bronnen; Perceptive aanvaardt geen verantwoordelijkheid voor de juistheid, volledigheid of actualiteit van deze informatie.

bottom of page