Passkey / WebAuthn attack-surface disclosure convergence (2026-08)

Three independent disclosures in one week attacked passkeys from both ends — the cryptography on a compromised endpoint and the enrolment on the phone — and the enterprise path, borrowing a signed-in session's Windows Hello key to authenticate to Entra ID, carries no CVE and no fix

Passkeys are the control European public-sector identity programmes are being pushed toward, on the correct premise that a credential which cannot be replayed to the wrong origin defeats remote phishing. Three independent disclosures inside ISO week 2026-W32 attacked that control from different directions, and the useful reading is neither that passkeys are broken nor that this is coincidence: it is that the residual attack surface has moved entirely onto the endpoint and the enrolment, and this week three separate parties published against it.

The enterprise path is the new one, and it is unpatched. At Black Hat USA 2026, Dirk-jan Mollema showed that malware running in an already-signed-in Windows session can call the Passport key-storage provider to sign data with the Windows Hello for Business private key — and that "calling these native functions from for example PowerShell does not prompt the user for a PIN or biometric authentication at all, but works based on cached data" (Dirk-jan Mollema, 2026-08-05). The second half is what makes it a remote-usable attack rather than a local curiosity: the WebAuthn challenge Entra ID issues "is not bound to a session, a user or even a tenant, so we can request it on our attacker host and then use the WHFB key on the victim machine," after which the signed assertion is replayed from the attacker's own host. Where the resulting token carries no device-ID claim, the attacker can register a device of their own and obtain a long-lived refresh token. No CVE was assigned and the behaviour was left as it is — a characterisation the reporting attributes to Mollema himself rather than to the vendor, noting that its own requests for comment to Microsoft and to Mollema were still outstanding at publication (The Hacker News, 2026-08-07). For a defender the practical position is the same either way: there is no patch to wait for and no identifier to track it by.

The consumer-synced path was published two days earlier and reaches further. Unit 42's three attacks against Google Password Manager's cloud-synced passkeys in Chrome on Windows all require only unprivileged malware already on the endpoint: driving the TPM-wrapped device identity key through standard Windows cryptography calls to sign a forged assertion with the User Verified flag unset, which succeeds against any relying party that does not validate that flag; forcing device re-enrolment and registering an attacker-generated user-verification key, because the cloud authenticator does not check attestation on new user-verification keys; and dumping the 32-byte security-domain secret from Chrome's memory during recovery, which decrypts every synced passkey private key (Palo Alto Networks Unit 42, 2026-08-03). The third has no remediation path at the user's disposal — Google has no mechanism to rotate or revoke that secret.

The third direction needs no software flaw at all. Google's threat-intelligence group reports that UNC6671, the operator behind the BlackFile extortion brand and four later brands, runs an identity-centric intrusion chain whose current pretext is precisely the control being rolled out: a call to an employee's personal mobile impersonating the IT helpdesk, sometimes spoofing the real helpdesk number, demanding an urgent FIDO2 passkey or MFA re-enrolment into an adversary-in-the-middle panel (Google Threat Intelligence Group, 2026-08-06). Enrolment is the moment the phishing-resistance property does not yet exist, and an organisation that has just deployed passkeys is an organisation whose staff have been told to expect exactly such a call.

Triage: the telemetry these attacks produce is authentication that succeeds, which is why the discriminator has to be positional rather than a failure signal. Look for a successful passkey or WebAuthn sign-in from a network location or device that has never previously held that key, and for Windows Hello key use with no corresponding interactive logon that would have prompted for a PIN or biometric — a genuine user's assertion is preceded by an unlock event, a borrowed one is not. On the tenant side, the sequence to alert on is a device-registration event followed closely by a long-lived refresh-token issuance for an account whose enrolment state changed within the preceding hours; legitimate device onboarding produces the same events, but not usually within minutes of a helpdesk-initiated credential reset.

Builds on: 2026-08-04/unit42-pass-ta-key-chrome-synced-passkey-forgery-sds-theft · 2026-08-07/unc6671-blackfile-multi-brand-passkey-vishing-aitm

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.