Credential manager key extraction

Credential manager key extraction is malware on a signed-in endpoint either stealing the private key material behind a passkey or using the key without the fresh PIN or biometric check meant to gate each use. It does not break WebAuthn cryptography. It targets the software around the key: the password manager that syncs it, the operating system that releases it for use, and the relying party that is supposed to check what the authenticator asserted. Three separate pieces of research in August 2026 showed working versions against Google Password Manager in Chrome, Windows Hello for Business, and Windows event logging. All three start from code already running on the victim's machine.

How it works

Synced passkeys in Google Password Manager. Unit 42's Pass the Passkey research, published August 3, 2026, tested Chrome on Windows with a TPM and described three techniques, all from unprivileged malware:

1. Pass-ta-key. Malware uses Chrome's TPM-backed device identity key to ask Google's cloud authenticator for an assertion, with no user interaction. The assertion does not carry a valid user-verification (UV) result, so it works only against relying parties that do not enforce the UV flag. GitHub rejected it; eBay accepted it until fixed.
2. Silver Pass-ta-key. Malware deletes Chrome's local passkey state to force re-onboarding, then registers its own key as the device's UV key. The cloud authenticator did not validate attestation for the new key, so the attacker can produce assertions with UV set, from another machine.
3. Golden Pass-ta-key. During forced re-onboarding the 32-byte security domain secret, the master key that encrypts every passkey synced to the account, is sent to Chrome and sits in process memory, where malware can read it. With it the attacker decrypts the synced passkey private keys and moves them elsewhere. Unit 42 reports there is no way to rotate or revoke that secret; Google removed it from Chrome's logs but not from memory.

Windows Hello for Business keys. Dirk-jan Mollema showed that code running in a signed-in Windows session can use the user's TPM-bound Windows Hello key as a FIDO2 credential to sign in to Microsoft Entra ID, with no PIN prompt and no admin rights. The key never leaves the TPM; the malware simply asks Windows to use it, as a legitimate process would. Entra's five-minute WebAuthn challenge was not bound to session, user, or tenant, so it could be requested on the attacker's host and signed on the victim's. The resulting sign-in satisfies phishing-resistant conditional access and can be used to register a device and obtain a Primary Refresh Token. Mollema treats this as how Windows Hello works rather than a bug; no CVE was issued.

Assertions written to logs. CVE-2026-34348: SpecterOps and Roman Grafnetter found Windows wrote WebAuthn assertions to event logs in cleartext readable by unprivileged users, replayable against Entra ID. Microsoft fixed it in July 2026.

Why it works

"The key never leaves the device" is a guarantee against remote phishing and against copying a credential between machines. It is not a guarantee against code on the same device. The control assumption that fails is that the user-verification gesture happens for every use. In each case the gate is enforced by software the attacker shares a machine with: a sync service that trusts a re-onboarding request, an OS that lets any process in the session use the key, or a relying party that never checks the UV flag the authenticator reported. A second assumption is that synced and device-bound passkeys carry the same risk. A synced passkey is only as strong as the master secret that encrypts it in the sync fabric, and Golden Pass-ta-key turns one endpoint compromise into a permanent compromise of every passkey in that account.

How to detect it

• Server-side flag logging. Relying parties receive the UV, backup eligibility (BE), and backup state (BS) flags in authenticator data on every assertion. Log them. An assertion without UV for a credential that always had it, or a BE/BS change on a credential you thought was device-bound, is a strong signal. Unit 42 also suggests watching signature counters, while noting synced systems make consistent counters hard.
• Entra sign-ins with an empty device ID using Windows Hello for Business, and unexpected new device registrations shortly after. Legitimate private-browsing sessions produce the same pattern, so expect noise.
• Endpoint telemetry. Non-browser processes reading or deleting Chrome's passkey state or sync database files, or reading Chrome process memory. Unit 42 recommends restricting those files to the browser process.
• Passkey re-onboarding events in a user's Google account that the user did not initiate.

The gap is structural: every technique begins with malware already on the endpoint, where local telemetry is the attacker's to tamper with. These are mostly forensic signals, plus the relying party's own logs, which the attacker cannot touch.

How to stop it

Ranked by effect:

1. Use device-bound hardware security keys for privileged accounts. A key on a YubiKey or similar authenticator is not in any process's memory and cannot be synced out. The phishing-resistant MFA matrix compares options.
2. Enforce and verify user verification at the relying party. Set userVerification to required and reject assertions where the UV flag is not set, on every authentication, not just registration. This defeats the base Pass-ta-key technique outright.
3. Treat endpoint compromise as full identity compromise. Revoke sessions and Primary Refresh Tokens, remove device registrations, and for synced passkeys assume every credential in that account is exposed.
4. Require compliant devices in conditional access, which can interrupt the Windows Hello persistence chain that relies on registering a new device.
5. Patch CVE-2026-34348 and keep forwarded logs from becoming a credential store.
6. Restrict who can register new authentication methods after a risky sign-in. See phishing-resistant MFA and the enterprise passkeys guide.

Seen in the wild

No incident in the SWI Identity Breach Database is attributed to this technique, and none of the August 2026 research reported in-the-wild exploitation. What exists is demonstrated research, from three independent teams in one week:

• Three passkey attacks land in one week, none of them breaking the cryptography
• Malware can drive a Windows Hello key for Entra ID persistence without a PIN prompt
• Windows stores WebAuthn assertions in cleartext event logs

Sources

No enterprise ATT&CK sub-technique cleanly covers this mechanism. T1555.004 is scoped strictly to the Windows OS-level Credential Manager and its credential lockers, not the Chrome-held or FIDO2 key material described here. T1555.003 covers saved passwords in browsers rather than private-key material, and is already used for infostealer credential theft. T1111 (Multi-Factor Authentication Interception) covers smart cards, hardware tokens, and interception of out-of-band one-time codes; it does not address WebAuthn or passkey key material. Rather than force a mapping that does not fit, this brief cites no attack_mitre ID.

• Unit 42: Pass the Passkey, a novel attack surface in passwordless authentication (August 3, 2026)
• BleepingComputer: New Pass-ta-key attacks let malware hijack Google synced passkeys
• The Hacker News: Malware can abuse Windows Hello for Business keys (August 2026)
• W3C: Web Authentication Level 3
• Passkey, glossary