Credential manager key extraction

How it works

Passkeys and other credential-manager-held keys are marketed as phishing-resistant because the private key never leaves the device and the browser or OS handles the cryptographic ceremony on the user's behalf. That promise depends entirely on the credential manager protecting the key material while it sits in memory and gating its use behind a fresh check, a PIN or biometric prompt, each time it is invoked. Two research efforts published in August 2026 targeted that plumbing rather than the WebAuthn cryptography itself. Unit 42 recovered synced private keys from Chrome's Google Password Manager on Windows by pulling a security domain secret out of the memory of the process holding it, once already running on the machine. Separately, Dirk-jan Mollema showed that low-privilege code running inside an already signed-in session could drive a TPM-bound Windows Hello key without triggering a fresh PIN or biometric prompt, using the same session state a legitimate process would use.

Both attacks require code execution on the target endpoint first; neither breaks the underlying public-key cryptography or forges a signature without the key. What they show is that a credential manager's protection is only as strong as the isolation between the process holding the key and any other process that can read its memory or ride its own open session.

Why it works

The control assumption that fails is that "the key never leaves the device" is equivalent to "the key cannot be reached by anything else on the device." Those are different guarantees. A device-bound key is safe from remote phishing and from copy-and-replay across machines, but it is not automatically safe from local compromise, because the process holding it still has to decrypt and use it at some point, and that moment is observable to anything running with sufficient access on the same host. A second assumption that fails is that a credential manager's own session state can be trusted to gate reuse: if a key can be invoked without a fresh authentication check because a session is already open, the freshness the check was supposed to guarantee no longer exists at the point of use.

How to detect it

• WebAuthn or Windows Hello authentication events with no corresponding fresh PIN or biometric prompt logged on the endpoint at the expected time.
• Process activity reading memory regions belonging to a browser's password manager or credential store process, outside of the browser's own normal operation.
• Sign-ins using a synced passkey from a device or session context that does not match the device's known enrollment history.

Be honest about the limits: both attacks start from an endpoint that is already compromised, and at that point a great deal of local telemetry becomes noisy or attacker-controlled. Detecting the specific memory read or session reuse in real time is hard without endpoint tooling built for it, and normal browser and OS process activity can look similar enough that this is a forensic signal more than a live blocking one.

How to stop it

• Prefer device-bound hardware security keys for privileged accounts rather than software-synced passkeys, since a hardware key's material is not extractable from process memory the way a synced key can be.
• Treat endpoint compromise as full identity compromise for any account using software-based key storage, since a compromised endpoint can drive or extract the key regardless of the cryptography behind it.
• Patch and harden the credential manager's process isolation and monitor for unauthorized reads of its memory space where endpoint tooling supports it.
• Verify server-side that a fresh user-verification flag is actually set on each assertion rather than trusting that the client enforced it, closing the gap that let a stale session drive a key without a new prompt. See passkey.

Seen in the wild

• Three passkey attacks land in one week, none of them breaking the cryptography

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 plaintext saved passwords 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 at all, so it is not a near miss, just a different mechanism. Rather than force a mapping that does not fit, this brief cites no attack_mitre ID.

• Passkey, glossary