Golden Pass-ta-key attack steals all Google-synced passkeys, research shows
Research shared on r/netsec details the Golden Pass-ta-key attack: malware already on the computer forces a new Chrome onboarding and extracts the Security Domain Secret (SDS), a 32-byte master key encrypting all passkeys synced through Google Password Manager, from process memory. With the SDS, the attacker decrypts the private keys for every account (Amazon, Apple, Microsoft, Binance, GitHub, among others) and signs valid WebAuthn assertions offline. Unit 42 described the Pass-ta-key family in August 2026; the sources cite no CVE, affected versions, fix, or in-the-wild exploitation, so the defense today is keeping malware off endpoints and monitoring accounts.
What happened
Researchers detailed the Golden Pass-ta-key attack, which lets malware already on a computer steal every passkey synced through Google Password Manager. With the master key extracted from Chrome's memory, the attacker takes over accounts at services such as Amazon, Microsoft, and GitHub without the victim's device or any interaction. Unit 42 (Palo Alto Networks) described the attack family in August 2026.
Why it matters
Passkeys replace passwords and second-factor checks; once the private key is stolen, no SMS code or push notification stops the attacker, because the signature is cryptographically valid. The attack requires malware on the machine, but runs with standard user rights, no privilege escalation, and no reliance on the TPM. Employees using this feature could see accounts on services like GitHub and Amazon compromised offline and persistently.
What to do
Prioritize detecting and removing malware on Chrome workstations, since the attack depends on it. Monitor accounts with Google-synced passkeys for suspicious logins and unknown devices. Await Google guidance, as the sources cite no fix.
For the technical team
- Affected
- Google Password Manager (passkeys sincronizadas) · Passkeys synced by Google Password Manager in Chrome (Windows). The sources cite no Chrome versions and no CVE.
- Exploitation
- Disclosed in research (r/netsec post detailing Golden Pass-ta-key); the Pass-ta-key family was described by Unit 42 (Palo Alto Networks) in August 2026. The sources report no in-the-wild exploitation and no public PoC.
- Fix
- The sources cite no vendor fix, patch, or mitigation.
- Vector
- Malware with standard user rights on a Windows workstation running Chrome; no privilege escalation, no user interaction, and no device unlock required. In Golden, the malware deletes passkey_enclave_state to force re-onboarding; Chrome retrieves the SDS in plaintext from the Trusted Vault and holds it briefly in process memory, where it is exfiltrated.
- More details
- The SDS is a 32-byte master key encrypting all GPM passkeys; only the Cloud Authenticator (enclave.ua5v.com) can decrypt the wrapped SDS. Passkeys are stored as WebauthnCredentialSpecifics protobuf records in the Sync Data\LevelDB folder, containing rp_id, username, user handle, and the ECDSA key encrypted with the SDS, readable without elevated privileges. Three variants: base (impersonates the device using the identity key extracted from the file or Chrome memory via Windows CNG APIs; assertions lack the UV flag and are rejected by services that verify it), Silver (deletes the state and, during the uv_key_pending window, registers its own UV key via device/add_uv_key because the Cloud Authenticator does not validate attestation of new UV keys; persists even after password change or session revocation), and Golden (extracts the SDS and all private keys; offline compromise with no TPM, no victim device, and no interaction).
Indicators (IoCs)
- enclave.ua5v.com
- passkey_enclave_state
- %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB
- device/add_uv_key
Timeline
Incident opened.
