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.

cover

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 is offline access to every passkey the victim has, current and future, with no rotation mechanism available on Google’s side.

If you have read my earlier piece on applying software engineering discipline to threat detection, you will recognize the pattern here: the failure lives in the trust boundary around the cryptographic primitive, not in the cryptography itself. That is exactly the class of problem detection engineering has to compensate for when the vendor’s own architecture leaves a gap.

The forensic footprint on a Windows endpoint

From a DFIR perspective, all three attacks share a narrow set of artifacts, and that narrowness is good news. Reconnaissance, the phase Unit 42 calls Stage Zero, requires reading Chrome’s synced passkey metadata from:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

This LevelDB store contains proto-encoded WebauthnCredentialSpecifics records: relying party, username, credential ID and the encrypted private key blob. No elevated privileges are required to read it, which means process-access logging, not privilege escalation detection, is where you catch this. Any non-browser process opening a handle into that directory or into chrome.exe’s address space is a signal worth an alert, not a shrug.

The second artifact, and the more forensically valuable one, is passkey_enclave_state. It stores the wrapped identity key and, after enrollment, the registered UV key reference. Silver and Golden Pass-ta-key both require this file to be deleted or invalidated to force re-onboarding. A file that should change only during legitimate device setup or account recovery, but that shows unexpected modification or deletion timestamps outside those windows, is close to a smoking gun. File-integrity monitoring on this single path, correlated with subsequent Chrome network activity to Google’s cloud authenticator endpoints, is cheap to build and high-signal.

For Golden Pass-ta-key specifically, the SDS exists in Chrome’s process memory only for a short window during re-registration. This is squarely memory forensics territory. If you are pulling a memory image during an incident where passkey compromise is suspected, the techniques I described in my deep dive on Windows memory management and Volatility 3 apply directly: windows.vadinfo and windows.malfind to check whether an unexpected process has mapped or hollowed into chrome.exe’s address space, and windows.dumpfiles to recover any staged copies of passkey_enclave_state that a rootkit-style process might have cached before exfiltration. The practical limitation is timing: the SDS is transient, so unless the memory image is captured during or shortly after a forced re-enrollment event, you will not find it. That makes the file-system artifact (the re-creation of passkey_enclave_state) the trigger that should prompt acquisition, not an afterthought discovered during a routine triage weeks later.

Detection engineering for passkey abuse

None of this requires exotic tooling. It requires the same discipline I described in my post on building a CI/CD pipeline for Sigma rules: version-controlled rules, test fixtures, shadow mode before promotion. Here is a starting Sigma rule targeting the cross-process memory access that every variant of Pass-ta-key needs to reach Chrome’s key material:

title: Suspicious process access to chrome.exe memory
id: 8f2e1a4c-91d3-4b7e-9c6a-2f5d7e8b1a3c
status: experimental
description: Detects a non-whitelisted process opening a handle into chrome.exe with memory-read access, consistent with passkey identity/UV key extraction (Pass-ta-key attack family).
author: Andrea Fortuna
date: 2026-08-05
logsource:
  category: process_access
  product: windows
detection:
  selection:
    TargetImage|endswith: '\chrome.exe'
    GrantedAccess|contains:
      - '0x1010'
      - '0x1038'
      - '0x1400'
  filter_main_edr:
    SourceImage|contains:
      - '\Program Files\'
      - '\Program Files (x86)\'
  condition: selection and not filter_main_edr
falsepositives:
  - Debuggers and legitimate process monitoring tools
  - EDR agents performing memory inspection
level: high
tags:
  - attack.t1055
  - attack.t1552.001

A second rule covers the file-system trigger, deletion or recreation of the enclave state file outside a normal Chrome update window:

title: Passkey enclave state file modified by non-browser process
id: 4d6b8e2f-73a1-4c5d-8e9f-1b3c5d7e9f2a
status: experimental
description: Detects creation, deletion or modification of Chrome's passkey_enclave_state file by a process other than chrome.exe, consistent with forced re-onboarding used in Silver/Golden Pass-ta-key.
author: Andrea Fortuna
date: 2026-08-05
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith: '\passkey_enclave_state'
  filter_chrome:
    Image|endswith: '\chrome.exe'
  condition: selection and not filter_chrome
falsepositives:
  - Backup or sync software that touches the Chrome profile directory
level: high
tags:
  - attack.t1552.001
  - attack.t1556

A third detection is behavioral rather than event-based: correlate the two rules above with an unexpected WebSocket connection from chrome.exe (or, worse, from a process that is not chrome.exe) to Google’s cloud authenticator infrastructure occurring within minutes of the file event. That correlation is what separates “Chrome updated normally” from “something forced Chrome to re-enroll this device.” As I argued in the Sigma CI/CD post, a rule like this belongs in shadow mode for at least a week before it pages anyone, precisely because backup software and profile migration tools can trigger the file-event half of the correlation innocently.

Behavioral IOCs worth adding to hunt queries and EDR watchlists, since no file hashes or C2 infrastructure were published (this is technique research, not a tracked campaign):

Artifact Location Significance
Sync Data\LevelDB read by non-browser process %LocalAppData%\Google\Chrome\User Data\<Profile>\ Passkey enumeration (Stage Zero reconnaissance)
passkey_enclave_state deleted/modified unexpectedly Same Chrome profile directory Forced re-onboarding preceding Silver/Golden attack
NCryptOpenStorageProvider / NCryptSignHash calls from non-browser process Windows CNG API telemetry / ETW Identity key signing outside legitimate Chrome flow
Repeated GPM recovery PIN prompts outside account setup User-reported / UI telemetry Possible sign of forced re-registration
chrome://device-log/FIDO accessed programmatically Browser automation / DevTools protocol Reconnaissance for SDS leakage (patched, but worth retro-hunting)
Memory read of chrome.exe shortly after enclave state recreation Process-access + file-event correlation Consistent with Golden Pass-ta-key SDS extraction

What incident responders should prioritize

If you land on a case where account takeover happened despite passkey-only authentication, do not assume the passkey itself was “broken.” Start from the endpoint, not the identity provider. Check for the artifacts above in that order: sync database access first, enclave state file history second, memory acquisition (if the timing allows it) third. Attribution of intent matters less here than sequencing: a deleted passkey_enclave_state followed by a legitimate-looking re-enrollment and then an authentication event from an unfamiliar network is a pattern, not a coincidence.

On the relying-party side, if you run services that accept passkey logins, this research is a direct argument for auditing whether your WebAuthn implementation actually rejects assertions with UV=0 when userVerification: required is set. Testing this takes an afternoon and the eBay case study shows exactly what happens when nobody does. Pair that with monitoring for the signature-counter weaknesses Unit 42 flagged: synced passkeys commonly report a constant signCount, so the one classic WebAuthn anti-cloning signal is mostly unavailable, and you will need behavioral detection (impossible-travel, device-fingerprint drift, session anomaly) to compensate.

None of this is an argument against passkeys. The credential-theft economics genuinely change when there is no shared secret to phish or resell. But the endpoint compromise problem that DFIR teams have been fighting for two decades did not go away because the authentication factor got smarter. It just moved one layer down the stack, into the browser’s sync database and the enclave state file, which is exactly where our detection logic needs to move next.

FAQ

What is the Pass-ta-key attack? Pass-ta-key is a set of three techniques disclosed by Unit 42 that abuse Google’s synced passkey ecosystem in Chrome on Windows. Malware already running on a compromised endpoint can sign authentication requests using the device’s hardware-backed identity key, register a rogue user-verification key, or extract the security domain secret that decrypts every synced passkey.

Do these attacks break passkey cryptography? No. The public-private key model behind WebAuthn remains intact. The attacks exploit gaps in device trust, onboarding, recovery and relying-party validation, not the cryptography itself, which is why detection has to focus on process behavior and file system artifacts rather than key material.

How can defenders detect Pass-ta-key style abuse? Focus on three signals, unexpected reads of Chrome’s Sync Data LevelDB store by non-browser processes, deletion or re-creation of the passkey_enclave_state file outside a normal update cycle, and cross-process memory access to chrome.exe from unsigned or unusual binaries. These map cleanly to Sysmon event IDs 10 and 11 and to standard EDR process-access telemetry.