Malware Turns Google Synced Passkeys Into Reusable Account Keys

Palo Alto Networks Unit 42 published three post-compromise techniques on August 3, 2026, that let malware running as a normal Windows user abuse Google Password Manager’s synced passkeys in Chrome. The attacks, named Pass-ta-key, Silver Pass-ta-key and Golden Pass-ta-key, target device enrolment keys, re-registration flows and the 32-byte Security Domain Secret rather than the underlying WebAuthn cryptography.

Every path requires malware already present on a TPM-equipped Windows machine. No remote break-in of passkey accounts is shown, and researchers reported no active exploitation. The work still rewrites the residual risk model for the millions of accounts that now rely on Google’s cloud sync.

Three Techniques That Escalate After Infection

Unit 42’s full Pass-ta-key technical analysis walks through progressive escalation. All begin with unprivileged access to Chrome’s local profile data, including the LevelDB sync database that stores relying-party IDs, usernames and encrypted private-key material.

Pass-ta-key pulls the wrapped identity key from the passkey_enclave_state file, imports it via Windows CNG and has the legitimate TPM sign attacker-controlled handshake data. Google’s cloud authenticator accepts the signature and returns a valid assertion. Sites that fail to enforce the User Verified bit accept the login.

Silver forces a re-onboarding window by deleting or invalidating local state. Chrome can sit in a uv_key_pending transitional state. The attacker then registers its own verification key. The cloud service accepted the replacement without hardware attestation. Subsequent assertions carry the UV flag and work from attacker infrastructure.

Golden is the most severe. Malware triggers fresh onboarding, dumps Chrome process memory while the SDS briefly appears in plaintext, and pairs the 32-byte secret with the encrypted records from the sync database. Private keys become portable. Unit 42 demonstrated login to a cryptocurrency exchange with recovered material. The same SDS protects future passkeys created under the account, and no public rotation path is documented.

The Sync Architecture That Creates the Surface

Passkeys themselves remain strong against phishing and server breaches. A private key never leaves the authenticator in normal use, and domain binding stops look-alike sites. Google’s design adds a cloud enclave that holds the SDS and device-specific wrapping keys so credentials can follow a user across phones and desktops.

Chrome on Windows generates a hardware-backed identity key and a user-verification key tied to Windows Hello. Public halves go to the cloud. The SDS encrypts the actual passkey private keys for sync. During recovery or re-enrolment the SDS is delivered to the client so the browser can unwrap material. That hand-off is the window Golden exploits.

• Identity key proves device possession and needs no Hello prompt for signing.
• UV key is gated by biometrics or PIN and sets the UV bit.
• passkey_enclave_state holds wrapped keys and SDS material under the user profile.
• LevelDB sync store exposes metadata and ciphertext to any process with the user’s privileges.

Google’s 2022 description of the end-to-end encrypted passkey design stressed that even Google cannot use the keys. The research shows the client-side recovery path still places the master secret where malware can reach it.

When a Single Bit Decides Success

WebAuthn separates user presence from user verification. The UV flag inside authenticator data tells the relying party whether a biometric or PIN check occurred. Merely setting userVerification to “required” in the browser request is not enough. The server must parse the signed flags and reject UV=0.

The server should examine whether the UP flag is true or false, and whether the UV flag is true or false, depending on the requirement.

That guidance appears in Google’s own web.dev documentation, which states the server must check the UV flag. Unit 42 tested against GitHub (which rejected) and eBay (which accepted until the researchers reported the gap). eBay fixed the validation before publication.

Many services still treat “required” as a client-side hint. That single-bit failure turns Pass-ta-key into a full account takeover even when the site believes it demanded MFA.

Passkey Scale Makes the Gap Costly

FIDO Alliance figures released for World Passkey Day 2026 put the installed base at roughly 5 billion passkeys now in use. Consumer awareness sits at 90 percent, 75 percent of people have enabled at least one, and 68 percent of organizations are deploying or piloting workforce passkeys. Google Password Manager is one of the largest sync providers.

5 billion estimated active passkeys worldwide

90 percent consumer awareness

75 percent of people enabled on at least one account

36 percent of eligible accounts already enrolled in earlier FIDO Index data

Credential-stealing malware already harvests cookies, tokens and password-manager databases with ordinary user rights. Passkeys were expected to shrink that haul. The new techniques give stealers a path to convert an endpoint foothold into portable high-value logins or black-market private keys. Development cost is non-trivial, but the reward scales with adoption.

Who Feels the Pressure First

Ordinary users who keep only low-value accounts in Google Password Manager face limited extra risk. The prerequisite remains full malware execution. High-value targets change the calculus: crypto exchanges, developer platforms, corporate identity providers and finance apps become higher-priority malware payloads once private keys can be extracted.

Enterprises that rolled out synced passkeys for convenience now confront the same trade-off security teams already know from password managers. Device-bound hardware security keys cannot be exported through a cloud domain. Unit 42 explicitly recommends them for administrators, developers and finance staff.

The pattern echoes other recent Google-surface issues, including an earlier Google lock-screen bypass that also turned a local trust boundary into remote-usable access. Endpoint compromise continues to matter even as the credential itself improves.

Practical Steps That Still Hold

Google removed the SDS from FIDO diagnostic logs after Unit 42’s report. The secret still arrives in process memory during recovery. Public documentation lets users change Google Password Manager PIN or delete Password Manager data, yet it does not state that either action rotates the SDS. Relying-party revocation of individual passkeys remains the surest way to invalidate a stolen private key.

1. August 2025-early 2026: Unit 42 maps Google cloud authenticator architecture in earlier papers.
2. Disclosure window: Researchers report log exposure, eBay UV gap and related issues; Google and eBay apply partial fixes.
3. August 3, 2026: Full public report with attack videos and mitigations.
4. Ongoing: No CVEs listed, no claimed wild use, no complete SDS-revocation UI described.

Defenders should treat unexpected deletion of passkey_enclave_state, abnormal TPM signing calls and Chrome memory dumps as signals. Monitoring for re-enrolment spikes helps. Relying parties must validate UV after every assertion. Credential providers should require attestation on new identity and UV keys and treat recovery as a privileged operation with notifications to existing devices.

Users who suspect compromise should rebuild the endpoint, review Google signed-in devices, revoke passkeys at each important service from a clean machine, and consider hardware keys for the accounts that matter most. Similar pressure appears in other automation layers, where agents pulling sensitive data more often also expand the blast radius of any single foothold.

Passwordless Still Wins on Phishing, Not on Endpoint Trust

The research leaves the core cryptographic claims of passkeys intact. No shared secret is typed or transmitted. Domain binding stops phishing pages. Database dumps at the relying party yield only public keys. Those properties remain decisive against the dominant historical attacks.

What changes is the post-compromise story. Synced implementations necessarily add recovery, onboarding and cloud key-management layers. Those layers can re-introduce transferable trust. When malware already owns the user session, the difference between a device-bound key and a cloud-recoverable one becomes the difference between a one-time proxy and a portable private key.

Organizations that treat passkeys as a complete replacement for endpoint hygiene will rediscover why layered defense never left. The ones that keep hardware keys for privileged roles, enforce UV validation and watch enrolment state will keep the gains while shrinking the new surface Unit 42 mapped.

Frequently Asked Questions

What is the Security Domain Secret in Google Password Manager?

The SDS is a 32-byte master symmetric key that encrypts the private keys of all synchronized passkeys belonging to a Google account’s security domain. Google’s cloud authenticator unwraps it with a device-specific wrapping key; once an attacker holds the SDS, existing and future synced private keys under that domain can be decrypted without further cloud help.

Does changing the Google Password Manager PIN rotate the SDS?

Google’s public support pages describe the PIN as a recovery and verification factor but do not state that a PIN change replaces the underlying SDS. Unit 42’s analysis found no exposed rotation or revocation mechanism for the secret itself, so relying-party passkey deletion remains the more reliable remediation for extracted keys.

Why did GitHub reject Pass-ta-key while eBay accepted it?

GitHub correctly inspected the authenticator data and rejected assertions whose UV flag was unset. eBay had set userVerification to required yet failed to validate the returned bit at the time of testing; the company fixed the gap after disclosure. The difference is entirely server-side validation, not the cloud authenticator’s response.

Can these attacks work without a TPM or on non-Windows systems?

Unit 42 focused exclusively on Chrome on Windows with a Trusted Platform Module. The identity and UV keys are generated through Windows CNG and TPM wrapping. Other platforms and browsers that implement Google’s cloud authenticator may share architectural elements, but the concrete techniques and memory layouts demonstrated are Windows-specific.

Are device-bound hardware security keys affected?

No. Hardware keys that never sync private material through a cloud security domain cannot be extracted via SDS recovery or unattested re-enrolment. Unit 42 recommends them precisely for high-risk roles where the convenience of sync is outweighed by the need for non-exportable credentials.