How Pass-ta-key attacks steal passkeys instead of passwords | Andrea Fortuna

GitHub rejected it. eBay accepted it, at least until someone told them not to. Same cryptographically valid, silently forged authentication assertion, two completely different outcomes, because one relying party actually checked a single bit in the response and the other didn’t. That bit is the whole story of why passkeys, the technology everyone was told would finally kill credential theft, can still be walked around by malware that never touches a password.

The research comes from Unit 42’s Pass the Passkey paper, part three of a series dissecting Google’s synced passkey architecture, and it has already been picked up in the Italian press by Matrice Digitale. Most of the coverage so far has focused on the “passkeys aren’t as safe as you thought” angle. That framing is accurate but incomplete for anyone doing incident response. The interesting part, for this blog at least, is not that the attack exists. It’s what it leaves behind on disk, in memory and on the wire, and how you build detections for it before your SOC finds out about Pass-ta-key from a vendor advisory instead of from your own telemetry.

In brief

Three attacks (Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key) let malware already present on a Windows endpoint take over accounts protected by Google-synced passkeys in Chrome, with escalating levels of persistence and impact.

None of the attacks break WebAuthn cryptography. They exploit trust assumptions in device onboarding, recovery and relying-party validation of the User Verified (UV) flag.

The forensic footprint is concrete: reads of Chrome’s Sync Data LevelDB store, deletion or re-creation of the passkey_enclave_state file, and (for the most severe variant) a security domain secret that briefly exists in Chrome’s process memory.

Detection should center on process-access telemetry (who is reading chrome.exe’s memory), file-integrity monitoring on passkey state files, and correlation with unexpected re-enrollment or recovery prompts.

No CVE was assigned and no active exploitation has been reported, but the technique class is a preview of what account-takeover detection will need to cover as passwordless adoption scales.

Three ways to defeat a system that has no password to steal

The attacks target Google Password Manager’s cloud authenticator model in Chrome on Windows, specifically on devices with a Trusted Platform Module. All three assume malware is already running on the victim’s machine with standard user privileges, no elevation, no jailbreak, no exploit chain against the browser itself.

The baseline technique, Pass-ta-key , abuses the fact that Chrome’s device identity key, the hardware-backed key that proves “this request comes from a device the cloud authenticator already trusts”, can be invoked through standard Windows CNG APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) by any unprivileged process that can read the wrapped_identity_private_key blob stored in passkey_enclave_state. Malware uses this to sign an assertion request, opens a WebSocket handshake with the Google Cloud Authenticator, and gets back a cryptographically valid response, without the victim unlocking the device, entering a PIN, or seeing a prompt. The catch is the User Verified (UV) flag : signatures produced this way carry UV=0. A relying party that actually validates the flag, GitHub did during testing, rejects the login. eBay, initially, did not.

Silver Pass-ta-key removes that limitation by forcing a fresh onboarding cycle. The malware invalidates the existing UV key, either by issuing a device/forget command signed with the stolen identity key or simply by deleting passkey_enclave_state, then waits for Chrome to re-enroll the device. During the brief uv_key_pending window that precedes the second passkey use, the attacker registers their own public key as the device’s UV key. The cloud authenticator does not validate the attestation of that key, so from then on, every assertion the attacker signs carries a fraudulent UV=1. Unlike the base attack, this one survives without live access to the victim’s machine: the attacker authenticates from their own environment, at will.

Golden Pass-ta-key is the one worth losing sleep over. It targets the 32-byte security domain secret (SDS) , the master key that decrypts every synced passkey private key. The SDS should never reach the client in usable form, but Unit 42 found it briefly present in plaintext in Chrome’s internal FIDO logging (chrome://device-log/FIDO), and, after Google removed it from the logs, still transiently resident in Chrome’s process memory during re-registration. Malware that forces a fresh onboarding, monitors for the recreation of passkey_enclave_state, and dumps Chrome’s process memory at the right moment can extract the SDS, then decrypt the WebauthnCredentialSpecifics records already harvested from Chrome’s sync database. The result...