10 minhigh
Pass the Passkey: A Novel Attack Surface in Passwordless Authentication
Unit 42 discloses three novel attack classes against Google's synced passkey ecosystem on Windows TPM devices, collectively nicknamed 'Pass-ta-key.' All three require pre-existing unprivileged malware on the victim's endpoint. The Pass-ta-key attack silently signs cloud authenticator requests using the extracted TPM-backed device identity key. The Silver Pass-ta-key attack exploits Chrome's deferred UV key onboarding to register an attacker-controlled verification key, enabling persistent remote access without the victim's device. The Golden Pass-ta-key attack extracts the Security Domain Secret from Chrome's process memory during forced re-onboarding, enabling decryption of all synced passkeys. Key gaps include lack of UV flag validation by relying parties, absence of attestation verification for newly registered UV keys, and exposure of the SDS to the client environment.
Conf:high
Detection / Hunteropenrouter
What Happened
Researchers discovered new ways that attackers can hijack accounts protected by passkeys (a modern password replacement) when they already have malware running on a victim's computer. The attacks target Google's passkey system in Chrome on Windows computers. The first attack lets the attacker silently log in as the victim without needing their fingerprint, PIN, or any interaction. The second attack tricks Google's system into accepting a new security key controlled by the attacker, giving them permanent remote access to all the victim's passkey-protected accounts. The third and most serious attack steals a master key from Chrome's memory that can decrypt every passkey the victim has, and there is currently no way to rotate or replace this master key. Anyone using Google synced passkeys on Windows is potentially affected. Organizations should ensure their websites properly verify user identity during passkey logins, monitor for suspicious re-registration of devices, and maintain strong endpoint malware protection. Passkeys remain more secure than passwords, but endpoint security remains critical.
Key Takeaways
- Three novel attack classes (Pass-ta-key, Silver Pass-ta-key, Golden Pass-ta-key) enable account takeover of Google-synced passkey-protected accounts from unprivileged malware on the endpoint
- The Pass-ta-key attack silently authenticates as the victim by extracting the TPM-backed device identity key and signing cloud authenticator requests without user interaction, device unlock, or elevated privileges
- The Silver Pass-ta-key attack registers an attacker-controlled UV key by exploiting Chrome's deferred onboarding flow, enabling fully automated authentication from the attacker's own environment without the victim's device being online
- The Golden Pass-ta-key attack extracts the Security Domain Secret (SDS) from Chrome's process memory during forced re-onboarding, allowing decryption of all current and future synced passkeys with no rotation or revocation mechanism available
- Some relying parties (e.g., eBay prior to fix) accepted passkey assertions without validating the UV flag, reducing MFA to a single factor; all relying parties should enforce userVerification=required and validate the UV flag
Affected Systems
- Google Chrome on Windows with TPM
- Google Password Manager synced passkeys
- Google Cloud Authenticator
- WebAuthn relying parties (websites and services accepting passkey authentication)
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Unprivileged malware already running on victim's Windows endpoint with TPM
- Reconnaissance: Malware reads Chrome sync database at %LocalAppData%\Google\Chrome\User Data<Profile>\Sync Data\LevelDB to enumerate passkey-protected accounts and extract encrypted credential records
- Credential Access: Malware extracts wrapped_identity_private_key from passkey_enclave_state file or Chrome memory, then uses Windows CNG APIs (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash) to sign authentication requests via TPM without elevated privileges
- Defense Evasion: For Silver attack, malware deletes passkey_enclave_state or issues device/forget command to force Chrome re-onboarding, then registers attacker-controlled UV key via device/add_uv_key without attestation verification
- Credential Access: For Golden attack, malware forces re-onboarding and monitors for passkey_enclave_state recreation, then dumps Chrome process memory to extract the 32-byte Security Domain Secret (SDS) in plaintext
- Account Takeover: Attacker uses forged assertions (Pass-ta-key/Silver) or decrypted passkey private keys (Golden) to authenticate as victim across all passkey-protected services, with no rotation or revocation available for the SDS
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: No
No detection rules, queries, or signatures are provided in the article. The article describes attack techniques and mitigations at an architectural level but does not include specific detection logic.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Medium | EDR can potentially detect non-Chrome processes accessing Chrome's sync database or passkey_enclave_state file, process memory read operations targeting Chrome, and NCrypt API calls from unexpected processes. However, the attacks closely mimic legitimate Chrome behavior, making behavioral differentiation challenging. |
| Network Visibility | Low | The WebSocket communication with Google Cloud Authenticator appears as legitimate Chrome traffic. The authentication assertions are cryptographically valid and indistinguishable from legitimate user authentication at the network layer. |
| Detection Difficulty | Hard | The attacks are designed to mimic legitimate Chrome and TPM interactions. The identity key signing uses standard Windows CNG APIs without elevated privileges. Network traffic to the cloud authenticator is encrypted and appears legitimate. The UV key registration during onboarding follows a legitimate flow. Distinguishing malicious re-onboarding from legitimate device re-registration requires contextual correlation across multiple telemetry sources. |
Required Log Sources
- Process access/memory read events (e.g., Sysmon Event ID 10 for ReadAccess to Chrome process)
- File access events for Chrome sync database and passkey_enclave_state (Sysmon Event ID 11 for file creation, Event ID 2 for file creation time change)
- Process execution and module load events to identify non-Chrome processes invoking NCrypt APIs
- Chrome device logs (chrome://device-log/FIDO) for unexpected onboarding or recovery events
- EDR process telemetry for cross-process access patterns targeting Chrome
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for processes other than Chrome accessing or reading the Chrome sync LevelDB database, which would indicate credential enumeration by malware (T1552.001) | File access events targeting Chrome's Sync Data LevelDB directory from non-Chrome processes | Reconnaissance | Medium - legitimate Chrome extensions or password management tools may access this directory |
| Consider hunting for deletion or unexpected modification of the passkey_enclave_state file followed by Chrome process memory access, which may indicate a forced re-onboarding to extract the SDS (T1005) | File deletion events for passkey_enclave_state correlated with process memory read operations targeting Chrome | Credential Access | Low - legitimate deletion of this file is uncommon outside of profile reset scenarios |
| Consider hunting for non-Chrome processes invoking NCryptSignHash or NCryptImportKey APIs, which may indicate malware signing authentication requests with extracted TPM-backed keys (T1606.001) | API call monitoring or DLL load events for ncrypt.dll from non-browser processes | Defense Evasion / Credential Access | Medium - other legitimate applications use CNG APIs for cryptographic operations |
| Consider hunting for unexpected or repeated Chrome onboarding and recovery PIN prompts, which may indicate manipulation of passkey state to trigger re-registration of device keys (T1556) | Chrome FIDO device logs showing unexpected device registration or UV key registration events | Defense Evasion | Medium - legitimate device changes or profile migrations can trigger re-onboarding |
| Consider hunting for process memory dump operations or cross-process memory reads targeting Chrome, which could indicate extraction of the Security Domain Secret from process memory (T1552) | Process access events (e.g., Sysmon Event ID 10) showing ReadAccess permissions requested on Chrome processes | Credential Access | Medium - security tools and debugging utilities may legitimately read Chrome process memory |
Control Gaps
- Network-based detection cannot distinguish malicious passkey authentication from legitimate authentication since assertions are cryptographically valid
- Signature-based antivirus is unlikely to detect these attacks as they use legitimate Windows APIs and do not drop identifiable malware files
- Relying parties that do not validate the UV flag cannot detect Pass-ta-key attacks where user verification is bypassed
- WebAuthn signCount is constant in synced passkey systems, eliminating a key clone detection mechanism
- No mechanism exists to rotate or revoke the Security Domain Secret, limiting remediation after Golden Pass-ta-key compromise
Key Behavioral Indicators
- Non-Chrome process accessing Chrome sync database LevelDB files
- Deletion or modification of passkey_enclave_state file outside of legitimate Chrome profile management
- Process memory read operations (e.g., OpenProcess with PROCESS_VM_READ) targeting Chrome processes
- Non-Chrome processes loading ncrypt.dll and invoking NCryptSignHash or NCryptImportKey
- Unexpected Chrome FIDO device log entries showing device/forget or device/add_uv_key commands
- Repeated or unexpected GPM recovery PIN prompts during normal browsing sessions
- Chrome device log entries at chrome://device-log/FIDO showing security domain secret key material
False Positive Assessment
Medium - Several behavioral indicators (file access to Chrome directories, CNG API usage, process memory access) can be triggered by legitimate applications, browser extensions, or security tools. Correlation across multiple telemetry sources and focusing on non-Chrome process ancestry will be important for reducing false positives.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing relying parties your organization operates to confirm userVerification is set to required and the UV flag is validated in all WebAuthn authentication responses.
- If your EDR supports file access monitoring, consider deploying rules to alert on non-Chrome processes accessing Chrome's sync database or passkey_enclave_state file.
- If you have process memory access monitoring capabilities, consider evaluating whether alerts on cross-process memory reads targeting Chrome are feasible given your false positive tolerance.
- Consider reviewing Chrome FIDO device logs (chrome://device-log/FIDO) on endpoints where suspicious passkey activity is suspected to identify unexpected onboarding or key registration events.
Infrastructure Hardening
- If your organization operates WebAuthn relying parties, consider enforcing userVerification=required and implementing strict UV flag validation in authentication response processing.
- Evaluate whether your credential management infrastructure validates device key attestation during registration to prevent enrollment of attacker-controlled keys.
- Consider implementing coordinated signature counter mechanisms for synced passkey systems to improve detection of credential reuse across environments, if supported by your platform.
- If applicable to your environment, evaluate whether recovery and device re-registration flows can be hardened with additional verification steps before re-establishing device trust.
User Protection
- Consider ensuring endpoint malware protection and EDR coverage is deployed on all devices used for passkey authentication, as all described attacks require pre-existing malware on the endpoint.
- If your EDR supports host isolation, consider having procedures ready to isolate endpoints showing signs of passkey state manipulation.
- Evaluate whether your organization can restrict access to Chrome's local passkey data files through platform access controls or application allowlisting.
- Consider educating users to report unexpected Google Password Manager recovery PIN prompts during normal browsing, as these may indicate manipulation of passkey state.
Security Awareness
- Consider incorporating awareness of passkey security into existing security training programs, emphasizing that endpoint compromise remains a critical threat even with passwordless authentication.
- If your organization has adopted or is adopting passkeys, consider training help desk and IT staff to recognize signs of forced device re-onboarding as a potential security indicator.
- Consider adding guidance to existing security awareness materials advising users to report unexpected or repeated recovery PIN prompts during routine passkey usage.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping6 techniques
Tactic
Persistence
Tactic
Credential Access
Tactic
