Malware Can Silently Hijack Chrome Passkeys, Researchers Show
Palo Alto's Unit 42 details three attack paths against Google Password Manager that let ordinary user-level malware sign in without a fingerprint, PIN, or on-screen prompt.
Key points
- Researchers at Palo Alto Networks' Unit 42 have shown that malware running as a normal Windows user can abuse Chrome's Google Password Manager to sign into passkey-protected accounts.
- Two of the three techniques, Pass-ta-key and Silver Pass-ta-key, target the local signing flow and session tokens respectively; Golden Pass-ta-key goes after the master encryption key protecting all stored passkeys.
- All three work without any fingerprint check, PIN entry, or visible prompt on the victim's screen.
- The attacks assume malware is already running with the victim's own permissions, not administrator rights.
- Passkeys stored in cloud-synced password managers inherit the security of the device they sync to, not the strength of the passkey standard itself.
Passkeys were meant to end the password era. A passkey is a login credential stored on your device that proves who you are using a fingerprint or PIN, so there's nothing for a phishing site to steal. Or so the pitch goes.
New research from Palo Alto Networks' Unit 42 pokes a serious hole in that pitch, at least for people who let Chrome's built-in Google Password Manager handle their passkeys.
What did the researchers actually do?
Unit 42 built three attack techniques that let malware, running as the logged-in user on a Windows PC, sign into that user's passkey-protected accounts. Nothing appears on screen. The victim has no idea.
The techniques escalate in seriousness. Pass-ta-key abuses the local signing flow. Silver Pass-ta-key reuses tokens tied to the browser session. Golden Pass-ta-key, the worst, goes after the master key that unlocks every passkey stored in the cloud. Unit 42 has been a consistent source on browser-based threats: we covered a related Chrome malware defence just two days before this research surfaced, and on 23 July we reported on near-exploitable bugs in Microsoft's own passkey rollout, so the timing here isn't coincidental.
How bad is this in practice?
Bad enough to take seriously, not bad enough to panic. Every technique assumes something has already gone wrong: malware is running on the machine as the user. That's a real scenario (a rogue installer, a malicious extension, a poisoned download) but it isn't a remote hack from nowhere.
What changes is the assumption underneath passkeys. The whole point is that even if attackers take everything on your disk, they still can't log in without a live biometric check. These techniques break that promise for Chrome's implementation. Once the malware's in, the passkey behaves a lot like a saved password.
| Technique | Target | Impact |
|---|---|---|
| Pass-ta-key | Local signing flow | Silent sign-in as user |
| Silver Pass-ta-key | Session tokens | Reuse of authenticated state |
| Golden Pass-ta-key | Master encryption key | Access to all synced passkeys |
Should you worry?
Don't ditch passkeys. They're still far better than reused passwords, and this research targets one specific implementation, not the standard itself.
A few practical steps:
- Store passkeys on a hardware security key (a small USB device like a YubiKey) or on your phone rather than in the browser, if your accounts allow it.
- Turn on login alerts for your Google account so a strange sign-in shows up in your inbox.
- Be cautious about browser extensions. Install only what you need, from publishers you recognise.
- Keep Windows and Chrome updated. Google has been notified.
For businesses, treat any passkey stored in a cloud-synced consumer password manager as being only as safe as the endpoint it sits on. Device gets malware, the passkey follows.
Google hadn't published its own advisory naming these three techniques at time of writing. Watch for one.
