Pass-ta-key: unprivileged malware forges Chrome synced-passkey assertions, registers its own user-verification key, and can steal the master secret that decrypts every passkey

Passkeys remove the shared secret, which removes phishing, replay and credential stuffing from the attacker's toolkit. Unit 42's research, published 2026-08-03, is about what replaces them: three attacks that leave the cryptography intact and instead abuse the trust a cloud-synced passkey system places in the client device, its onboarding flow and its recovery flow. The scope is specific — Google Password Manager in Chrome on Windows on machines with a TPM — and the precondition is unremarkable: malware already running as the logged-in user, with no elevation (Unit 42, 2026-08-03).

Reconnaissance. Chrome stores synced passkeys as proto-encoded WebauthnCredentialSpecifics records in its sync database under %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, and Unit 42 states plainly that "Accessing these records does not require elevated privileges." Reading them tells an attacker which services the victim protects with passkeys, the associated usernames and credential identifiers, and the encrypted private key — a target list before any authentication is attempted.

Pass-ta-key — forging the assertion. Chrome proves device possession to Google's cloud authenticator with a hardware-backed identity key, and the way Chrome handles that key is what the attack turns on. Chrome creates the TPM key without a name so it is never persisted inside the TPM, then exports it as an NCRYPT_OPAQUE_KEY_BLOB — encrypted by a TPM-resident key — and stores the result as wrapped_identity_private_key in the passkey_enclave_state file. Malware reads that blob from disk or Chrome's memory and re-imports it through the ordinary Windows CNG interfaces (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign whatever it likes on the same physical TPM. Unit 42's own framing of the consequence: "Unlike a legitimate user flow that requires user interaction and device unlock, this attack shows how malware can obtain the required signature silently, without user consent, biometrics, device unlock or elevated privileges." The attacker opens a WebSocket handshake with the cloud authenticator, signs the handshake hash together with the assertion request using the stolen identity key, receives a valid assertion, and replays it to the relying party.

The single bit that decides whether that works. The cloud authenticator issues a valid assertion whether the request was signed with the identity key or with the user-verification key; the only difference is the User Verified flag in the authenticator data, which is 0 for the identity key. A relying party that requires user verification and checks the flag rejects the forged assertion — a passkey-protected GitHub login did. A relying party that sets userVerification to required but never inspects the returned flag accepts it, and multi-factor authentication collapses to possession of one device key: "In our testing, we identified relying parties that accepted authentication because they did not properly validate the UV flag." Unit 42 demonstrated this against eBay, which has since fixed its validation. Because many relying parties set the parameter to preferred rather than required for device-compatibility reasons, the population this variant works against is not small.

Silver Pass-ta-key — becoming the verification key. Rather than trying to reach the UV key, the attacker deletes it. Nothing protects the passkey_enclave_state file from removal (or the attacker issues a device/forget command with the identity key it already controls), which forces Chrome to re-onboard the device on next passkey use. Windows onboarding completes only on the second passkey use, so the device sits in a uv_key_pending state in between — Chrome defers creating the UV key to avoid stacking a Windows Hello prompt on top of the Google Password Manager recovery-PIN prompt. In that window the attacker generates its own key pair and sends device/add_uv_key with its public key, and it is accepted: "The cloud authenticator does not validate the attestation of newly registered UV keys to verify whether they originate from secure hardware." From then on the attacker mints assertions with the UV bit set, from its own infrastructure, without the victim's device being online — reusable access that satisfies even correctly implemented relying parties.

Golden Pass-ta-key — taking the master key. Synced passkey private keys are encrypted under a 32-byte security domain secret (SDS) that is supposed to stay inside the cloud authenticator, with only a wrapped copy on the client. Unit 42 found it in plaintext in Chrome's own FIDO device log, and while Google removed it from logging after the report, the underlying flow is unchanged: "Although Google removed this secret from Chrome's logging output following our report, the SDS is still sent to the client and remains accessible in Chrome's process memory." So the attacker forces a fresh onboarding using the Silver technique, watches for passkey_enclave_state to be recreated, dumps Chrome's process memory at that moment, extracts the SDS, and decrypts every record in the sync database. The result is exportable passkey private keys, usable from anywhere, for every current and future passkey on the account — and there is no remediation: "In Google's current implementation, there is no way to rotate or revoke the SDS, meaning all current and future synced passkeys remain protected by the same master key." Re-enrolling the device evicts the Silver variant; nothing evicts this one.

Triage: the telemetry classes are process and file access, not network. In process and module telemetry, the discriminator for the assertion-forging step is process identity — Chrome itself calling CNG to sign with the device identity key is the legitimate flow that happens on every real passkey login, whereas a non-browser process importing an NCRYPT_OPAQUE_KEY_BLOB and calling NCryptSignHash after reading passkey_enclave_state or the sync LevelDB is not a flow the product produces. For the Silver and Golden variants the sequence is the signal rather than any single event: deletion or modification of passkey_enclave_state, followed by a device re-onboarding the user did not initiate, followed by cross-process memory reads of chrome.exe. Legitimate re-enrolment happens, but it is user-initiated and rare, and it is not preceded by something removing the local state file. Hardening beyond the relying-party check follows Unit 42's own list: restrict access to Chrome's sync database and local passkey state files to the browser process through platform access controls, and monitor for repeated or unexplained re-triggering of onboarding and recovery flows.