Passkey Attack: Malware Can Hijack Google-Synced Passkeys

Marcus Chen Staff Engineer, Backend & Cloud, YuSMP Group · Application security and authentication for US/EU services

The short answer

What Unit 42 found

Passkeys are meant to be device-bound and phishing-resistant: a private key stays on your device, protected by hardware, and a login is only signed after you prove presence with a fingerprint, PIN or device unlock. To make them usable across phones and laptops, providers such as Google sync those private keys through the cloud, encrypted under a master key. Researcher Arie Olshtein at Unit 42 examined that sync-and-recovery machinery in Chrome on Windows and found that once malware is on the machine, several of its assumptions can be turned against it.

The common thread across all three techniques is silence. In a legitimate flow the user must interact and unlock the device; Unit 42 showed how malware running as an unprivileged user can obtain the required signature, register its own verification key, or lift the master secret entirely — without any prompt appearing on screen. The work is limited to Google Password Manager in Chrome on Windows systems with a Trusted Platform Module, and, importantly, it is responsible research rather than a report of active abuse.

The three variants

Unit 42 grouped the findings into a family it nicknamed Pass-ta-key, escalating in impact:

• Pass-ta-key. Malware reads the wrapped identity key Chrome stores locally and uses it to sign an authentication assertion exactly as the browser would. The result is a completed login with no device unlock, biometric or consent — a silent account takeover that mimics legitimate behaviour.
• Silver Pass-ta-key. By deleting or corrupting the local passkey state file, the attacker forces Chrome into a re-onboarding flow, during which the cloud authenticator accepts a newly registered, attacker-controlled user-verification key without properly validating its origin. That removes the need for the victim's device during future logins and makes the attack automatable across accounts.
• Golden Pass-ta-key. The most damaging path extracts the 32-byte security domain secret (SDS) — the master key that protects all of a user's synced passkeys — from Chrome's process memory. With the SDS, an attacker can decrypt and reuse every synced credential offline, well beyond a single session.

Google has already made at least one change, removing the SDS from a Chrome device-log output after the issue was reported, but Unit 42 noted the secret remained reachable in process memory during re-registration, and it was not established that all three paths were closed at the time of publication.

Why passkeys aren't broken

It is worth stating plainly, because the headline invites the wrong conclusion: this research does not break passkeys, WebAuthn or FIDO2. The cryptography still does its job, and passkeys remain dramatically more resistant to phishing and credential stuffing than passwords or one-time codes. What Pass-ta-key demonstrates is a familiar security truth — a sound protocol can be undermined by the implementation around it. The weak points here are storage, cloud sync and account recovery, not the signature scheme.

The other essential caveat is the precondition. Every variant assumes an attacker has already achieved code execution on the victim's device. Malware with local access has always been able to do serious damage; the notable part is that the passwordless model was often sold as if a device compromise no longer mattered, and this work shows that the credential manager still needs defending after the perimeter has failed. In other words, keep migrating to passkeys — just don't retire your endpoint and anomaly defences on the assumption that they made those obsolete.

What it means for US & EU software teams

Most teams reading this are not Chrome engineers; they are relying parties — the applications that accept a passkey and grant a session. That is the right lens. The practical exposure is that a login backed by a synced passkey can now come from a compromised device without the human ever being present, so a passkey assertion should be treated as a strong signal, not an unconditional guarantee of a trusted user. The defensive work lives on your side of the exchange: enforce user-verification server-side instead of trusting the client, validate the origin and attestation of any credential at registration so an attacker cannot quietly swap in its own key, and pay attention to the WebAuthn signature counter, which exists precisely to reveal cloned or reused credentials.

For regulated sectors the stakes are higher. In FinTech, payments and healthcare, strong customer authentication and access integrity are contractual and legal obligations under frameworks such as PSD2, SOC 2, DORA and HIPAA, and "the user had a passkey" will not satisfy an auditor if a malware-driven session could have produced the same assertion. Recovery and re-enrolment flows deserve special scrutiny, because the Silver variant shows that onboarding is often the softest part of a passwordless system — an attacker who can trigger re-registration can side-step the very verification the login enforces. Designing those flows to be as hard to abuse as authentication itself is now table stakes, not a nice-to-have.

How to harden your passwordless auth

You do not need to abandon passkeys to respond to this. You need to make your relying-party implementation assume the device might be hostile.

1. Enforce user-verification server-side. Set userVerification = required and actually validate the UV flag in the authenticator data on the server — do not infer it from client behaviour.
2. Validate attestation at registration. Check the origin and attestation of newly registered credentials so a silently registered, attacker-controlled key is rejected rather than trusted.
3. Watch the signature counter. Track the WebAuthn signature counter per credential and treat regressions or impossible jumps as a cloning signal that triggers step-up or revocation.
4. Harden recovery and re-enrolment. Make account recovery and passkey re-registration as strong as login — additional verification, cool-down windows and alerting — because that is where these attacks concentrate.
5. Keep device and behavioural signals. Layer device posture, anomaly detection and step-up checks for sensitive actions; a passkey login is one input, not the whole decision.
6. Pressure-test the whole flow. Include passkey enrolment, login and recovery in security reviews and threat models that explicitly assume malware on the endpoint.

None of this is a reason to slow your move away from passwords. The strategic signal from Unit 42's work is narrower and more useful: passwordless authentication shifts risk from the network to the endpoint and the sync layer, and the teams that design for a compromised device — validating server-side, guarding recovery, and watching for cloned credentials — are the ones who get the phishing resistance of passkeys without inheriting a new blind spot.

Frequently asked questions

Sources

Palo Alto Networks Unit 42 — Pass the Passkey: A Novel Attack Surface in Passwordless Authentication (primary source)
The Hacker News — Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts
BleepingComputer — New Pass-ta-key attacks let malware hijack Google-synced passkeys