# When Malware Doesn't Need Your Fingerprint: The Passkey Attacks Google Didn't See Coming
The pitch for passkeys has always rested on a simple premise: the private key never leaves your device, so there's nothing for an attacker to steal. Researchers at Palo Alto Networks' Unit 42 just stress-tested that premise against Google Password Manager's cloud sync — and found three ways to break it without touching the cryptography.
The attack family, called Pass-ta-key, targets Chrome on Windows devices equipped with a Trusted Platform Module. None of the three techniques crack the underlying math. All three exploit how Google's cloud authenticator handles device trust, registration, and the synced credential layer that makes passkeys convenient across devices. Convenience, as usual, is where the seams show.
## The Trust Google Extends to Your Machine
The first technique — the one that shares its name with the family — works like this: malware already running on a compromised Windows machine abuses Chrome's TPM-backed device identity key to craft a signed request to Google's cloud authenticator. The cloud service sees the request, recognizes the device signature, and returns a valid authentication assertion — the cryptographic token needed to log in.
No administrator privileges. No user interaction. No biometric prompt. No PIN.
Google's authenticator hands back what looks like a successful login because, from its perspective, the request came from a machine it trusts. The problem is that "the machine is trusted" and "a human on that machine just verified their identity" are very different statements, and the system conflates them.
There's a built-in safeguard here: the assertion includes a User Verified flag that signals whether biometric or PIN verification actually occurred. If a relying party checks this flag properly, the attack fails. GitHub does check it — Unit 42's tests against GitHub came back empty. eBay did not validate the flag, which meant the attack worked. eBay has since patched the issue.
The lesson for service operators is blunt: requiring user verification and actually validating that it happened are two different things. Implementing the former without enforcing the latter is a paper control.
## Silver: Own the Verification Key Itself
The second technique, Silver Pass-ta-key, escalates the attack by targeting the verification key rather than working around it.
The attacker forces Chrome to re-register the device — either by invalidating its existing verification key or deleting the local passkey state file. During re-registration, Google's cloud authenticator accepts a new user-verification key without confirming it originated from trusted hardware. The attacker, who controls the malware on the device, substitutes their own key.
After that, the attacker doesn't need the victim's machine anymore. They've registered a key they control with Google's infrastructure as proof of the victim's biometric unlock. They can authenticate from a completely different system, satisfying even relying parties that properly enforce the User Verified flag.
This moves the attack from exploitation to persistence. The victim's account is now accessible to whoever holds that malicious verification key, for as long as Google accepts it.
## Golden: The Master Key Under the Floorboards
The third technique is the one that should make Google product leads uncomfortable.
Golden Pass-ta-key extracts the security domain secret — the master key Google Password Manager uses to encrypt every passkey synced to a victim's account. Unit 42 found that Chrome receives this master key temporarily when a device registers or recovers access to the account. Malware positioned on the device at the right moment can intercept it.
If the first two attacks are precise surgical strikes on individual accounts, Golden Pass-ta-key is a full vault extraction. An attacker with the security domain secret doesn't need to target individual passkeys one by one — they have the decryption material for everything the victim has stored and synced through Google Password Manager.
The scope of that exposure depends on how much a victim has adopted passkeys across their accounts. For someone who has moved aggressively to passkeys as their primary authentication method — exactly the behavior Google and the FIDO Alliance have been encouraging — the blast radius is significant.
## HackWire Analysis
The security industry spent years telling users that passkeys were the answer. And at the cryptographic level, they still are: the math is sound, and remote phishing attacks that work against passwords don't work against passkeys. None of that has changed.
What this research exposes is that the *implementation layer* — specifically, the cloud sync infrastructure that makes passkeys usable across multiple devices — carries trust assumptions that don't hold when a device is already compromised. This is a familiar problem wearing new clothes. We saw it with password manager browser extensions that could be targeted by malicious JavaScript. We saw it with cloud-backed key storage in mobile OS ecosystems. Every time a security primitive gets a sync layer bolted on for usability, the sync layer becomes the attack surface.
The more uncomfortable finding is the eBay case. A major consumer platform was checking whether user verification was *requested* rather than whether it actually *happened* — a distinction that matters enormously. That's not a sophisticated bypass; it's a relying party not reading the spec carefully enough. How many other services that accept passkeys are making the same mistake? Unit 42 tested two; there are thousands of sites implementing WebAuthn right now, many without dedicated security engineering reviewing their assertion validation logic.
The "requires prior malware" prerequisite will lead some to dismiss this as a lower-priority concern. That framing misses the point. Modern endpoint compromise is not rare. InfoStealer malware is commodity software. The question is not whether attackers can get malware onto endpoints — they do, routinely — but what additional leverage that access gives them. Pass-ta-key turns a one-time endpoint compromise into account persistence that survives re-imaging if the victim doesn't also rotate their Google account's security domain secret, which most users have never heard of.
For defenders: if you're running enterprise environments where users have Chrome passkeys synced to Google accounts, treat this as a post-compromise lateral movement and persistence vector, not just an authentication bypass. Endpoint detection coverage for Chrome process behavior and TPM-adjacent credential operations needs to be on your radar. For developers implementing WebAuthn: validate the User Verified flag on every assertion that requires it. Don't trust the presence of the uv bit in the authenticator data; confirm it matches your policy requirement server-side before completing authentication.
Google's response to these disclosures will be worth watching. The architecture questions here — particularly around the security domain secret's exposure window during device registration — aren't trivially patched.
— HackWire Editorial
---
## Related Coverage