How a Compromised Endpoint Undermines Passkey Trust
Researchers at Unit 42 identified three distinct attack paths, collectively dubbed "Pass-ta-key" attacks. These aren't theoretical; they're practical ways for malware to bypass the core security promises of passkeys. The common thread? The malware needs to be on your Windows device first. The focus here isn't on phishing, but on the consequences once an attacker has already established a presence on your device.
The attacks target the code around passkeys – how they're stored, how devices re-enroll, and how sites verify them. It's the operational security, not the crypto, that's the weak link here.
A Deep Dive into the Pass-ta-key Attack Chains
1. Pass-ta-key: Silent Authentication Bypass
Malware first performs reconnaissance, reading synchronized credential records from the Chrome sync database (%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB). This provides usernames and credential identifiers.
Next, the malware extracts Chrome's wrapped device identity key. Chrome creates this key without a key name, preventing standard disk persistence. It then exports and reloads it as an opaque blob, which suppresses user prompts.
With this wrapped_identity_private_key, the malware uses standard Windows Cryptography API: Next Generation (CNG) calls to sign an attacker-controlled request via the Trusted Platform Module (TPM). The key point is this happens silently, without any user consent, PIN, or biometric prompt.
The result is a valid authentication assertion, but with the User Verified (UV) flag unset. A common misconfiguration is for relying parties to set userVerification as preferred instead of required, or to fail to validate the UV flag properly. If a site doesn't strictly check that UV bit, the attacker gains access.
2. Silver Pass-ta-key: Attacker-Controlled UV Key Registration
This attack targets accounts that do enforce user verification. The attacker's goal is to register their own user-verification key.
The malware forces Chrome to re-enroll the device, either by issuing a device/forget command via the device identity key or by deleting the passkey_enclave_state file. This makes Chrome believe it's a new device.
During re-onboarding, Chrome defers UV key creation to avoid back-to-back PIN prompts. This creates a window for the attacker.
The attacker generates an asymmetric key pair in their environment and sends a device/add_uv_key command to the Google Cloud Authenticator, providing their controlled public key as the new UV key.
The flaw: the cloud authenticator does not verify if this newly registered UV key originates from secure hardware; it simply accepts it. The attacker now controls a UV key, stored alongside your legitimate device identity key. They can use this forged key to request signatures for any passkey, obtaining assertions with the UV bit set. This provides reusable access to high-value accounts from their own environment, even if your device is offline. This represents a significant persistence vulnerability.
3. Golden Pass-ta-key: Stealing the Master Key
This is the most severe attack. The Golden Pass-ta-key aims to extract the Security Domain Secret (SDS) – the symmetric master key protecting all synced passkey private keys. Compromising the SDS allows an attacker to decrypt all your passkeys.
The SDS should be highly protected, stored as an encrypted wrapped_secret and only decrypted by the cloud authenticator in an isolated environment. However, during device registration or re-registration, the SDS is sent to the client and briefly remains accessible in plaintext within Chrome's process memory.
The attack flow: Malware forces Chrome to trigger a fresh onboarding, similar to the Silver attack. It then monitors for the passkey_enclave_state file to be recreated or modified. While the SDS is briefly in memory, the malware dumps Chrome's process memory and extracts the 32-byte SDS.
With the SDS, the attacker can read WebauthnCredentialSpecifics records from Chrome's sync database, decrypt all encrypted fields, and recover your passkey private keys. From there, they can sign any relying party challenge and authenticate as you.
The practical impact: an attacker with this access allows full account takeover, decrypting all existing and any future passkeys for the account. Google's current implementation offers no way to rotate or revoke the SDS. If compromised, all current and future synced passkeys are vulnerable. This means compromising the SDS grants an attacker complete control over all synced passkeys, making it a critical vulnerability point.
What This Means for You and Your Accounts
The mainstream narrative often positions passkeys as a universal solution, but these attacks highlight critical implementation details. While passkeys significantly improve phishing resistance, they are not malware-proof. A compromised endpoint remains a fundamental risk.
Unit 42's report does not describe exploitation in the wild. No CVEs have been assigned yet. It's important to note that as of the Unit 42 report, no CVEs have been assigned for these specific attack paths, and there is no description of in-the-wild exploitation. While the research does not map these techniques to specific MITRE ATT&CK IDs, the detailed attack chains provide a clear understanding of the post-compromise tactics, techniques, and procedures involved. Google has already patched some historical SDS exposures, such as those found in FIDO logs. eBay also addressed a validation gap for the Pass-ta-key by enforcing the UV flag check.
The disclosure does not confirm if all three attack paths have been fully closed. The lack of SDS rotation or revocation controls remains a significant concern.
What Needs to Change
This research provides a clear roadmap for hardening passkey systems. For Relying Parties—the websites and services you log into—the immediate action is to set userVerification to required for all passkey registrations and authentications. More importantly, the returned UV bit in the authenticator data must be verified. Simply trusting the request setting is insufficient; if the UV bit is absent, the authentication must fail.
Credential Providers, such as Google, who manage synced passkeys, face a more complex set of technical requirements. A key step involves attesting newly enrolled keys. When a new device or UV key registers, the system must verify its origin and attestation, ensuring it comes from secure hardware and not an attacker-controlled environment. This directly counters the Silver Pass-ta-key vector.
Strengthening re-registration and recovery checks is equally critical. These workflows are prime targets for attackers, particularly after local passkey state files are tampered with, as seen in the Silver and Golden attacks. Implementing more robust verification steps during these processes is essential to prevent unauthorized device re-onboarding.
Furthermore, access to local passkey state must be severely restricted. The sync database and passkey_enclave_state files should be locked down tighter, limited strictly to the browser process and protected by strong platform access controls. This directly addresses the initial reconnaissance and access points for the Pass-ta-key and Golden Pass-ta-key attacks.
Crucially, master keys must be kept out of client memory. The Security Domain Secret (SDS) should never be exposed in plaintext on the client device, even temporarily. All cryptographic operations involving such sensitive material should occur within isolated environments, without transferring key material to the client. This mitigation directly addresses the Golden Pass-ta-key extraction method.
Finally, improving abnormal passkey usage detection is a necessary layer of defense. Systems should actively monitor for unusual signCount values or unexpected re-use of credentials, even when accounting for the complexities of multi-device synchronization. Such anomalies could signal a compromised passkey or an attacker's attempt to leverage stolen credentials.
This isn't about discarding passkeys. It's about recognizing that security requires multiple, independent controls, and even the best new technologies have implementation edges that attackers will probe. Passkeys remain a significant improvement, but continuous vigilance is required. The "unbreakable" narrative must be tempered with the reality that a compromised endpoint fundamentally alters the security posture.
