The Pass-ta-key Threat: Understanding How Malware Hijacks Google Synced Passkeys on Windows
Passkeys were supposed to be the end of passwords. They're passwordless, cryptographically sound, and designed to resist phishing attacks. But a report from Palo Alto Networks' Unit 42 reveals something uncomfortable: three novel attacks, collectively dubbed "Pass-ta-key," that let malware already running on a compromised Windows machine hijack Google Password Manager's synced passkeys to take over accounts.
The attacks don't break passkey cryptography. They exploit how Chrome and Google's cloud authenticator handle device trust, onboarding, recovery, and synced credentials. All three require malware to already be present on the victim's computer. None break the underlying crypto. That's the core problem — these are trust-model failures, not cryptographic ones.
For security and compliance analysts, this matters because it demonstrates a critical gap: passkeys don't eliminate the risks posed by malware on an already-compromised device. If your Windows machine is owned, passkeys offer less protection than you might assume.
The Threats Vulnerabilities Assets Framework: What This Means for Your Security Posture
When security teams assess modern authentication risks, they typically work through a threats vulnerabilities assets (TVA) worksheet — mapping out what attackers can do, where the weaknesses lie, and what they're trying to steal. The Pass-ta-key attacks fit squarely into that framework.
The threat actor here is malware already on the device. The vulnerability isn't in the cryptography itself but in how Chrome handles device trust and Google's cloud authenticator validates requests. The asset at risk? The victim's synced passkeys — private keys that grant access to accounts across the web.
This is exactly the kind of scenario that should trigger a review of your Known Exploited Vulnerabilities Catalog tracking. CISA maintains that catalog to help organizations prioritize patching against threats actively being exploited in the wild. While these specific Pass-ta-key vulnerabilities may not yet be cataloged by CISA, the pattern is clear: cloud-based credential managers are becoming prime targets when endpoint security is already breached.
Security teams need to understand that no single authentication mechanism is a silver bullet. Passkeys remain significantly safer than traditional passwords, but they don't make malware on a compromised device irrelevant.
Pass-ta-key: Impersonating a Trusted Device
The first technique, simply called Pass-ta-key, lets unprivileged malware impersonate a trusted device and request a valid authentication response for one of the victim's passkeys.
Here's how it works: the malware abuses Chrome's TPM-backed device identity key to sign a request sent to Google's cloud authenticator. No administrator privileges required. No user interaction. No biometric scan. No device unlock.
Google's cloud authenticator treats the request as coming from the victim's trusted computer and returns a signed authentication response — an assertion that can be used to log in to the targeted account. But here's the critical detail: the assertion includes a User Verified flag indicating whether biometric or PIN verification actually occurred.
If a website requires and properly validates that User Verified flag, the attack fails. Unit 42 demonstrated this clearly. The attack failed against GitHub, which properly checked the flag. But it succeeded against eBay, which required user verification but didn't properly validate whether that verification actually happened. eBay has since fixed the issue after the researchers reported it.
The takeaway for security teams? Websites must require user verification AND properly validate the flag. Credential managers need to validate newly registered device keys. These are basic security hygiene practices that remain inconsistently implemented.
Silver Pass-ta-key: Registering Your Own Verification Key
The second technique, Silver Pass-ta-key, goes further by letting attackers register their own user-verification key with Google's cloud authenticator.
The attacker first uses malware on the compromised device to force Chrome to re-register itself — either by invalidating the existing verification key or deleting the local file containing the passkey state. During this re-registration process, the attacker can register a user-verification key they control because Google's cloud authenticator doesn't validate whether the new key originated from trusted hardware.
Once registered, Google accepts requests signed with the attacker's key as proof that the victim unlocked the device using a PIN or biometrics. This gives the attacker access to accounts that properly require and validate user verification.
The persistence angle makes this particularly nasty. Once the malicious key is registered, the attacker can authenticate from another system entirely — no further access to the victim's computer needed. That's a long-term foothold that could persist for months.
Golden Pass-ta-key: Extracting the Master Key
The third and most severe technique, Golden Pass-ta-key, lets malware obtain the master key used to encrypt all passkeys synced through the victim's Google Password Manager account.
This master key — known as the security domain secret (SDS) — is temporarily sent to Chrome when a device registers or recovers access to the account. Unit 42 initially discovered that Chrome exposed the secret in plaintext through its internal FIDO logs. Google removed the secret from the logs after the researchers reported the issue, but Unit 42 found it's still sent to Chrome and remains temporarily accessible in the browser's process memory.
"Although Google removed this secret from Chrome's logging output following our report, the SDS is still sent to the client and remains accessible in Chrome's process memory," Unit 42 explains. "If the attacker forces the victim to re-register with the cloud authenticator and knows the pattern to look for, they can extract the SDS directly from memory."
The attacker then uses the stolen master key to decrypt the victim's synced passkey records and recover their private keys. Those private keys can be transferred to another system and used to impersonate the victim and sign in to their accounts.
Unit 42 warns that the stolen master key could also decrypt future passkeys synced to the account. Google's current implementation reportedly provides no way to rotate or revoke the key. Current and future synced passkeys remain protected by the same secret. That's a serious architectural problem.
What Security Teams Should Know
Unit 42 recommends that websites require and properly validate user verification. Credential managers should validate newly registered device keys, harden recovery and device re-registration processes, and prevent master keys from becoming accessible in browser memory.
The researchers disclosed the Google Password Manager attacks to Google and reported related user-verification flaws to affected services, including eBay, before publishing their findings. BleepingComputer contacted Google for comment on Unit 42's findings and to ask whether the described attacks have been fully addressed, but a response was not immediately available.
For security and compliance analysts working through their Threats Vulnerabilities Assets worksheet, here's the practical checklist:
- Audit your organization's passkey usage. Which services support Google Password Manager? Which require user verification? Which properly validate the User Verified flag?
- Review your Known Exploited Vulnerabilities Catalog tracking. Are you tracking cloud credential manager vulnerabilities as actively exploited threats?
- Harden endpoint security. These attacks require malware already on the device. Strong endpoint detection and response (EDR) remains your first line of defense.
- Monitor for suspicious re-registration activity. Silver Pass-ta-key requires forcing Chrome to re-register with the cloud authenticator. Watch for unusual passkey synchronization behavior.
- Advocate for better credential manager design. Organizations should push Google and other credential providers to implement key rotation and revocation capabilities for the security domain secret.
Passkeys remain significantly safer than traditional passwords. But these attacks demonstrate something important: they don't eliminate the risks posed by malware already running on a compromised device. If your Windows machine is already owned, passkeys offer less protection than you might assume.
Source: New Pass-ta-key attacks let malware hijack Google-synced passkeys by Lawrence Abrams, BleepingComputer, August 3, 2026. Research by Palo Alto Networks' Unit 42.
