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.
Passkeys are a passwordless authentication method that uses cryptographic keys stored on a user’s device to sign in to online accounts.
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.
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 can be done without administrator privileges, user interaction, biometrics, or unlocking the device.
Google’s cloud authenticator then treats the request as coming from the victim’s trusted computer and returns a signed authentication response, known as an assertion, that can be used to log in to the targeted account.
However, the assertion includes a User Verified flag indicating whether biometric or PIN verification occurred. This causes the attack to fail if a service requires and properly validates that user verification was successful.
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. Although eBay required user verification, it did not properly validate the flag indicating whether that verification occurred.
eBay has since fixed the issue after the researchers reported it.
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.
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.
Unit 42 initially found 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 says it is 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,” explains Unit 42.
“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. 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 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.
While the researchers say passkeys remain significantly safer than traditional passwords, the attacks demonstrate that they do not eliminate the risks posed by malware already running on a compromised device.
Unit 42 recommends that websites require and properly validate user verification. Credential managers should also 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.
Security teams log 54% of successful attacks and alert on just 14%. The rest move through your environment unseen.
The Picus whitepaper shows how breach and attack simulation tests your SIEM and EDR rules so threats stop slipping by detection.
