"The (cloud) enclave authenticator’s primary function is to make it difficult to steal passkey private data, which would be an obvious target for malware if it were locally available." — Google
Three new account-takeover classes: Pass‑ta‑key, Silver, Golden
Palo Alto Networks Unit 42 describes three novel attack classes that enable account takeover of passkey-protected accounts when an attacker controls malware on a victim’s endpoint. The core findings: malware running as a standard user (no elevation required) can (1) authenticate without user interaction by abusing Chrome and the Google Cloud Authenticator (Pass‑ta‑key); (2) register attacker-controlled user‑verification keys and obtain assertions that set the user‑verified (UV) bit, enabling fully automated logins even when biometric or PIN verification is required (Silver Pass‑ta‑key); and (3) extract the account master key — the security domain secret (SDS) — to decrypt all synced passkey private keys and sustain persistent, reusable access (Golden Pass‑ta‑key).
How Chrome, TPM keys, and the cloud authenticator are misused
Unit 42 documents specific implementation details on Windows. Chrome stores synced passkey records as proto‑encoded WebauthnCredentialSpecifics within its sync database at:
- %LocalAppData%\Google\Chrome\User Data\\Sync Data\LevelDB
Chrome creates a TPM-backed device identity key in an ephemeral form (using NcryptCreatePersistedKey without a name), exports it as an NCRYPT_OPAQUE_KEY_BLOB (NcryptExportKey), and saves the resulting wrapped_identity_private_key inside passkey_enclave_state. Malware can extract that wrapped blob and invoke NCrypt APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to produce signatures that the cloud authenticator will accept — all without elevated privileges or device unlock.
Built by Nubivance.
OSINTSights' secure edge-first architecture, AI content pipeline, and serverless ops are designed by Nubivance. We do this for clients too.
Talk to us →Where validation fails: the UV flag, onboarding, and SDS exposure
Unit 42 highlights three practical gaps. First, relying parties sometimes do not validate the UV flag in authenticator data. Assertions signed with the identity key leave UV=0; those signed with a UV (user‑verification) key set UV=1. When sites fail to check UV, a single‑factor assertion can be accepted even when userVerification was declared required. Unit 42 demonstrated this behavior in a recording on eBay; eBay later corrected the validation.
Second, Chrome’s onboarding and recovery flows create a uv_key_pending state on Windows: Chrome defers creating the UV key during the first re‑onboard and relies on the Google Password Manager recovery PIN, creating a window an attacker can exploit to add a forged UV key (device/add_uv_key) that the cloud authenticator stores without attestation validation.
Third, and most consequential, Unit 42 found the SDS exposed to the client during registration flows. The SDS — the 32‑byte symmetric master key that protects all synced passkey private keys — appeared in chrome://device-log/FIDO and is transmitted to the client as part of device join/recovery. Although Unit 42 reports Google removed the secret from Chrome’s logging output after disclosure, the SDS still reaches the client and is present transiently in Chrome process memory; an attacker forcing a re‑onboard can dump memory, extract the SDS, decrypt synced passkeys, and recover private keys for reuse.
What this means for technologists, relying parties, and end users
Technologists and security teams: assume endpoint compromise is part of the threat model. Unit 42 recommends limiting access to Chrome sync storage and passkey state files, hardening onboarding and recovery flows, and preventing exposure of master keys to client memory or logs.
Relying parties and credential managers: require and enforce userVerification = required, validate the UV flag in authenticator data, and verify attestation and origin when device keys are added. The report also urges implementing coordinated signature‑counter mechanisms for synchronized passkey systems, since many synchronized assertions contain a constant signCount and provide little reuse visibility.
End users and enterprise procurement: malware on an endpoint remains a decisive risk. Unit 42’s demonstrations rely on an initial compromise on the victim device; preventing and detecting that compromise — including monitoring unexpected re‑onboarding or recovery prompts — is critical.
Remediation levers and a pragmatic conclusion
Unit 42’s analysis does not break passkey cryptography; it exposes gaps between design assumptions and real‑world implementations: trust placed in clients, inconsistent UV validation by relying parties, and fragile onboarding/recovery flows that surface sensitive material. Shorter term mitigations in the report include: strict UV checks by relying parties, attestation and origin verification by credential managers when registering device keys, minimizing client exposure to master keys (avoid logging or placing them in process memory), restricting access to Chrome’s sync database and passkey_enclave_state, and monitoring for abnormal re‑onboarding activity.
The essential lesson is practical rather than theoretical: hardware-backed keys and cloud enclaves raise the bar, but when an attacker already controls a user device they can manipulate onboarding, recovery, and device trust workflows in ways that defeat intended protections. Unit 42’s disclosure and the subsequent fixes (for example, removal of SDS from logs and eBay’s UV validation fix) show the path from discovery to mitigation — and also how implementation details can become the new attack surface as passkeys scale to billions of accounts.
