Unit 42 Details Three Chrome Passkey Attack Paths Requiring Existing Windows Malware

· Original article ↗

Summary

Unit 42 describes three post-compromise attacks against Chrome’s Google Password Manager on Windows that could expose passkey accounts or keys. The article says they require existing malware and that current exploitability and remediation remain unclear.

Key points

  • All three paths require malware already running on a Windows device with a TPM; the research does not describe how an attacker initially compromises the device.
  • Pass-ta-key reuses Chrome’s wrapped device identity key and TPM signing to obtain an authentication assertion; sites that do not enforce user verification may accept it.
  • Unit 42 said GitHub enforced the user-verification check, while eBay accepted a test assertion until it fixed the validation gap following disclosure.
  • Silver Pass-ta-key targets device re-enrollment to register an attacker-controlled verification key; Unit 42 said this could enable later logins without the victim’s device.
  • Golden Pass-ta-key targets the 32-byte Security Domain Secret in Chrome memory, which Unit 42 said could be used to recover synced passkey private keys; reliable extraction and persistence remain unresolved.
  • The article says Chromium source corroborates parts of the architecture, but does not establish that the latest stable Chrome release remains exploitable or that all paths are closed. No in-the-wild exploitation or CVE is reported.
  • The researchers recommend requiring and checking the user-verification bit; other suggested defenses include attesting newly enrolled keys and strengthening re-enrollment and recovery checks.

Article Details

Attack Vectors
  • Malware already running on a Windows device reads local Chrome profile data to identify passkey accounts and access credential identifiers and encrypted private-key material.
  • Pass-ta-key extracts Chrome’s wrapped device identity key and uses the TPM through Windows CNG calls to generate an authentication assertion without a visible user prompt.
  • Silver Pass-ta-key exploits the delay during device re-enrollment to register an attacker-controlled verification key, enabling later logins without the victim’s device.
  • Golden Pass-ta-key triggers re-enrollment and reads the 32-byte Security Domain Secret from Chrome process memory while it is temporarily present in plaintext, allowing recovery of synced passkey private keys.
Defensive Notes
  • Relying parties should set userVerification to required and verify the returned User Verified bit; the article reports that GitHub enforced this check and that eBay fixed a validation gap after disclosure.
  • Credential providers should attest newly enrolled keys and strengthen re-registration and recovery checks.
  • Restrict access to local passkey state and keep master keys out of client logs and memory.
  • The article does not establish whether all three paths are closed or whether changing a Google Password Manager PIN or deleting its data invalidates a previously obtained Security Domain Secret.

MITRE ATT&CK

Vendors

Products

Related Articles