Malware can steal Google passkeys and hijack accounts

Passkeys were meant to end the era of stolen passwords. New research from Palo Alto Networks' Unit 42 shows that once malware is running on a Windows PC, an attacker can still take over a passkey-protected account, and in the worst case walk off with copies of every passkey the victim has synced to the cloud.

Unit 42's Arie Olshtein published the analysis on 3 August 2026, the third part of a series examining passkey adoption from a security perspective. The work focuses on Google's synced passkey ecosystem, and specifically on Google Password Manager in Chrome on Windows, running on machines fitted with a Trusted Platform Module (TPM), the security chip meant to keep private keys beyond an attacker's reach. Unit 42 says every exploit described was responsibly disclosed before publication.

What's affected

A passkey replaces your password with a pair of cryptographic keys, one held by the website and one held by your device, so there is no shared secret left to phish or reuse. Google raises the bar further by generating and using the private key inside a cloud enclave, and by requiring a hardware-backed key on your own machine to attest that you are really there. Three promises follow from that design: you consent on the device, you unlock the device with a biometric or a PIN, and the private key can never be copied. Olshtein's research challenges all three.

How the attacks work

Unit 42 groups them under the nickname Pass-ta-key, and every one of them assumes the attacker already has malware running on the victim's computer.

The starting point is reconnaissance that needs no special privileges. Chrome keeps synced passkey records in its own sync database under %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB, and reading those records tells an attacker where the victim uses passkeys, along with the associated usernames, credential identifiers and the encrypted private key.

The first attack then simply mimics what Chrome itself does. To prove the device is present, Chrome signs data with a hardware-backed identity key. Olshtein found that Chrome creates that TPM-backed key without giving it a name, which keeps it out of the TPM's own storage, then exports it as an opaque blob that the TPM encrypts with a TPM-resident key and writes to disk as wrapped_identity_private_key inside the passkey_enclave_state file. Malware can lift that blob from disk or from Chrome's memory and call the standard Windows cryptography APIs to sign with it, running as an ordinary user and never triggering the device unlock protections.

What you should do

None of this is a reason to go back to passwords. Every attack in the paper starts from code already running on the endpoint, which is the real message: passkeys move the attacker's target off your password and onto your PC. Unit 42 also points at implementation gaps on the other side of the login, where relying parties fail to validate the User Verified flag, reducing MFA to a single factor. Site operators should confirm their WebAuthn checks actually enforce that flag instead of accepting any successful assertion. Defenders should treat browser profile directories as sensitive data stores, alert on processes reading Chrome's sync database or its passkey_enclave_state file, and assume an infostealer infection now carries an account takeover risk that a password reset will not clear.

The finding lands alongside evidence that attackers are already working around multi-factor authentication in the field. Cisco Talos reported in July that phishing now starts most intrusions as attackers beat MFA, and recent research showed malware reaching straight into browser profiles to hijack logged-in sessions.

This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.

Read the full analysis on IntelFusions