Medium cybersecurity update: New Pass-ta-key attacks let malware hijack Google-synced passkeys. NetworkFix reviewed the available source material to summarize the security issue, its potential impact and the defensive actions administrators should prioritize.
What Happened
Security researchers have discovered three attacks that allow malware on already-compromised Windows devices to abuse Google Password Manager's synced passkeys to take over accounts, bypass user verification, and extract passkey private keys. […] New Pass-ta-key attacks let malware hijack Google-synced passkeys Security researchers have discovered three attacks that allow malware on already-compromised Windows devices to abuse Google Password Manager's synced passkeys to take over accounts, bypass user verification, and extract passkey private keys. They are considered safer than passwords because they cannot be guessed, reused, or easily stolen through phishing, while also allowing users to authenticate with a PIN or biometrics, such as a fingerprint or facial recognition. "Unlike passwords, passkeys can't be shared, copied, written down, or accidentally given to someone else. This makes them more secure against phishing," reads Google's passkey documentation . However, a new report by Palo Alto Networks' Unit 42 demonstrates three novel attacks, collectively called " Pass-ta-key ," that target Google Password Manager in Chrome on Windows devices equipped with a Trusted Platform Module (TPM). All three attacks require malware to already be running on the victim's computer and do not break the cryptography used by passkeys. Instead, they exploit weaknesses in how Chrome and Google's cloud authenticator handle device trust, onboarding, recovery, and synced credentials.
Technical Details
The first technique, named Pass-ta-key , allows unprivileged malware to impersonate a trusted device and request a valid authentication response for one of the victim's passkeys. The malware abuses Chrome's TPM-backed device identity key to sign a request sent to Google's cloud authenticator. This causes the attack to fail if a service requires and properly validates that user verification was successful. Pass-ta-key fails when attempting to authenticate to GitHub Source: Unit 42 While the attack failed against GitHub, which properly checked the User Verified flag, Unit 42 said it successfully tested the attack against eBay. The second technique, named Silver Pass-ta-key , goes further by allowing attackers to 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 it by invalidating its existing verification key or deleting the local file containing its passkey state. During the re-registration process, the attacker can register a user-verification key they control because the cloud authenticator does not validate whether the new key originated from trusted hardware. Google then accepts requests signed with the attacker's key as proof that the victim unlocked the device using a PIN or biometrics. This allows the attacker to access accounts that properly require and validate user verification.
Security Impact
Organizations using the affected technology should treat the report according to its medium severity classification. Once the malicious key is registered, the attacker can authenticate from another system without needing further access to the victim's computer. The third and most severe technique, named Golden Pass-ta-key , allows malware to 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, is temporarily sent to Chrome when a device registers or recovers access to the account. Google removed the secret from the logs after the researchers reported the issue, but Unit 42 says it is still sent to Chrome and remains temporarily accessible in the browser's process memory. "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 can then use the stolen master key to decrypt the victim's synced passkey records and recover their private keys. Unit 42 warns that the stolen master key could also be used to decrypt future passkeys synced to the account. Google's current implementation reportedly provides no way to rotate or revoke the key, meaning current and future synced passkeys remain protected by the same secret.
Recommended Actions
- Identify whether the affected product, service or software is present in the environment.
- Review the original vendor or research advisory and verify affected versions before making configuration changes.
- Apply vendor-provided security updates or mitigations as soon as operationally practical.
- Review relevant security logs and monitoring alerts for signs of suspicious activity associated with the reported issue.
- Use the CVE identifiers, where available, to validate exposure through vulnerability-management and asset-inventory tools.
Security Details
- Severity: Medium
- Original source: BleepingComputer
Why This Matters
Cybersecurity teams should use reports like this as an input to risk-based vulnerability and threat management rather than relying on headline severity alone. Exposure depends on whether the affected technology is deployed, reachable by an attacker and protected by compensating controls. Confirming asset ownership, affected versions and available vendor fixes helps teams prioritize remediation while avoiding unnecessary emergency changes.
Original Report
NetworkFix recommends reviewing the complete original report from BleepingComputer for the authoritative technical context, affected versions, indicators and vendor-specific remediation details: Read the original report.
