Overview

Security researchers have uncovered a series of attacks that allow malware already running on a compromised Windows system to hijack Google-synced passkeys and take over online accounts without requiring a password, PIN, fingerprint, or facial recognition.

The research, published by Palo Alto Networks Unit 42, identifies weaknesses in Google's Cloud Authenticator implementation rather than flaws in passkey cryptography itself.

The attacks—named Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key—demonstrate how malware can abuse device trust and recovery mechanisms to silently authenticate as victims.

What Are Passkeys?

Passkeys replace traditional passwords with public-key cryptography, eliminating shared secrets that attackers commonly steal through phishing or credential stuffing attacks.

Normally, passkeys require:

• Device possession
• User verification (PIN or biometrics)
• Cryptographic authentication

However, the new research shows attackers can bypass these protections once malware gains access to a victim's Windows computer.

Pass-ta-key Attack

The first attack abuses how Google Chrome stores synchronized passkey information.

Researchers found that Chrome stores passkey metadata inside a local database that is:

• Unencrypted
• Readable without administrator privileges

This allows malware to identify every website where the victim uses passkey authentication.

The primary weakness involves Chrome's Identity Key, a credential used to prove device ownership to Google's Cloud Authenticator.

Instead of remaining permanently protected by the Trusted Platform Module (TPM), the key is temporarily exportable.

Malware can:

• Extract the identity key
• Use standard Windows cryptographic APIs
• Sign authentication requests exactly like Chrome

As a result, attackers can complete passkey authentication without triggering:

• Password prompts
• PIN verification
• Fingerprint authentication
• Face recognition

Silver Pass-ta-key

A second attack bypasses user verification entirely.

Researchers discovered that deleting or corrupting Chrome's local passkey state forces the browser into a recovery process.

During re-onboarding:

• Chrome registers a new verification key.
• Google Cloud Authenticator accepts the new key.
• The origin of the registration is not fully validated.

This enables attackers to permanently register their own trusted device and authenticate as the victim from another system.

Even accounts protected by strong multi-factor authentication can be affected.

Golden Pass-ta-key

The most serious attack targets Chrome's master encryption secret known as the Security Domain Secret (SDS).

The SDS protects every synchronized passkey associated with a Google account.

Researchers found the secret:

• Appears briefly inside Chrome debug logs
• Remains accessible in memory during recovery operations

Once extracted, attackers can decrypt:

• Existing passkeys
• Future synchronized passkeys

Unlike passwords, Google currently provides no mechanism to rotate the Security Domain Secret, allowing persistent long-term access after compromise.

Attack Comparison

What This Does Not Break

Researchers emphasized that:

• Passkey cryptography remains secure.
• TPM hardware is not broken.
• FIDO2 authentication is not compromised.

Instead, the attacks exploit weaknesses in:

• Device trust assumptions
• Browser implementation
• Cloud Authenticator onboarding
• Recovery workflows

Mitigations

Organizations should consider:

• Enforcing strict user verification for passkey authentication
• Validating hardware-backed device attestation during registration
• Restricting malware access to browser credential stores
• Monitoring unexpected passkey onboarding events
• Investigating unusual account recovery activity

Several affected services, including eBay, have already addressed portions of the identified verification weaknesses following responsible disclosure.

Key Takeaway

The Pass-ta-key research demonstrates that while passkeys remain significantly more secure than passwords, malware running on a trusted endpoint can still exploit implementation weaknesses surrounding device trust and recovery. Organizations should continue deploying passkeys while strengthening endpoint security, monitoring recovery events, and enforcing hardware-backed verification wherever possible.