Google Password Manager Attacks Could Let Malware Hijack Passkey-Protected Accounts

Recent news from Palo Alto Networks' Unit 42 confirms what many security engineers feared: Google Password Manager attacks could let malware hijack passkey-protected accounts even when biometric verification is enabled. The findings - widely reported across hacker news outlets - show that the very convenience of Chrome's passkey sync creates exploitable gaps. Malware running under the victim's user context can decrypt synced private keys, intercept WebAuthn assertions. Or silently restore passkeys to an attacker‑controlled device. For senior engineers and identity architects, this research demands a hard look at the real‑world trust boundaries of FIDO2 credentials when software‑based key storage replaces hardware‑bound authenticators. This deep dive Translate the Unit 42 report into architectural threats, replication lab notes. And actionable mitigation strategies, ensuring you understand exactly how a hacker with low‑privilege access can compromise what were assumed to be passwordless defenses.

The Promise and Shortcomings of Google's Passkey Sync Architecture

Google Password Manager stores passkeys as end‑to‑end encrypted blobs that roam between Chrome profiles via your google Account. When a passkey is created, the platform authenticator-such as Windows Hello or macOS Touch ID-generates a key pair. The private key is sealed into a credential record that can optionally be uploaded to the cloud. The sync mechanism employs a "splitting" model: the key material is wrapped with a recovery key known only to the device and an account‑level key derived from Google credentials. This architecture, by design, keeps raw private keys invisible to Google's servers.

In practice, however, three engineering decisions undermine that protection. First, the local SQLite database holding the encrypted passkey blobs is accessible to any process running with the user's privileges, with no additional OS‑level sandbox. Second, Chrome delegates the user‑verification check to the platform authenticator but remains willing to sign assertions after a simple device unlock, often treating a login password as sufficient identity proof. Third. Because the entire sync state can be reconstituted from cloud backups once malware grabs a fresh Google OAuth token or session cookie, the passkey's hardware independence becomes its greatest liability. None of these are WebAuthn spec bugs-they are side effects of trading security for seamless cross‑device convenience.

Unit 42's Research: Three Attack Vectors That Expose Passkey‑Protected Accounts

The Palo Alto Networks Unit 42 team published a proof‑of‑concept analysis that I have partially validated in a controlled Windows 11 lab. Their work focuses on the current stable Chrome channel and the default passkey enrollment flow. The three distinct vectors they uncovered-UI‑based assertion interception, direct DPAPI‑wrapped private key decryption. And cloud‑sync token reuse-all lead to full account takeover without ever needing to compromise biometric sensors. Here, I break down each path and what it means for your authentication stack.

Environment and Preconditions for the Attacks

All attacks assume that the adversary has achieved low‑privilege code execution on a Windows 10/11 machine-exactly the outcome of most info‑stealer campaigns. No administrator rights are required. The malware simply reads files under the user's AppData folder, calls standard Windows APIs like CryptUnprotectData. And can inject into Chrome's process or hook accessibility interfaces. Importantly, these techniques do not require the user to re‑authenticate with a thumbprint or face scan; the local device unlock state is often sufficient.

Attack Path One - Intercepting WebAuthn Assertions Through Autofill Manipulation

Chrome's autofill engine is a perennial target for UI‑spoofing. When a relying party invokes navigator credentials get(), Chrome queries the platform authenticator but also offers to fill credentials via Google Password Manager if a synced passkey matches the site. Unit 42 showed that malware can hook the browser's rendering pipeline-or abuse an accessibility API such as UI Automation-to present a fake autofill dialog. The victim, believing they're authenticating to their bank, selects a legitimate passkey that's then signed for an attacker‑controlled origin. Because the credential record is never copied, this path doesn't require decrypting any private key-it simply weaponizes Chrome's eagerness to autofill.

Attack Path Two - DPAPI‑Based Decryption of Synced Private Keys

The most destructive path requires no user interaction at all. On Windows, Chrome writes the encrypted passkey into the Login Data SQLite database, using the same table structure that holds ordinary passwords. The field password_encryption_key inside the logins table is protected by the Data Protection API (DPAPI) tied to the current user profile. By calling CryptUnprotectData with the logged‑in user's context, malware can recover the master encryption key that wraps the private key bytes. The recovered key is hardware‑agnostic and can be loaded into any WebAuthn library to generate valid assertions. Because Google's passkeys don't enforce device‑bound attestation by default, the receiving service has no signal to distinguish a stolen key used from a remote machine.

Attack Path Three - Cloud‑Sync Token Reuse to Restore Passkeys

The third exploit chain leverages Google's passkey sync infrastructure itself. When you initialize a new device and sign in to your Google Account, Chrome can download all synced passkeys. Malware that steals a fresh OAuth refresh token or a session cookie-using well‑known techniques like Token Insider or commodity info‑stealers-can silently spawn a Chrome instance on the attacker's machine, authenticate to the same Google Account. And trigger a full passkey sync. The newly restored credentials become immediately usable. And Chrome treats the initial account login as equivalent to a user‑verification gesture, often without any additional biometric prompt. Unit 42 demonstrated this by cloning a victim's Chrome profile directory onto a clean machine after extracting a valid authentication cookie. Once the sync completed, all passkeys were available for use on websites. And the victim received no notification because Google's security model assumes a successful account login is proof of possession. This attack bypasses even the DPAPI encryption barrier because the cloud‑side key‑wrapping depends solely on the account credentials, not on local TPM binding.

How Malware Bypasses Biometric Verification in Password Manager Sync

The key insight is that biometric verification on Windows, macOS. And Android occurs only at the platform authenticator level, not at the credential‑storage layer. When a passkey is synced, the raw private key is released from the enclave (or equivalent secure memory) into software‑managed storage. After that initial export, the OS treats the encrypted blob as just another user‑data file protected by user‑session controls. Malware running as the user can therefore retrieve the blob without ever triggering a fingerprint or facial scan. This architectural reality means that a passkey stored in Google Password Manager is as vulnerable as the operating system's ability to protect the user's credentials at rest-which is often far weaker than the isolated hardware environments that biometric sensors are supposed to represent. In effect, the google password manager attacks turn the convenience of sync into a direct path for malware to hijack passkey-protected accounts.

Architectural Differences from Hardware‑Bound Passkeys

Not all passkeys are created equal. When a FIDO2 credential is created on a physical security key or a platform authenticator that enforces TPM‑based key sealing, the private key never leaves the hardware boundary. The credential is strictly device‑bound, and any assertion must be performed on that specific device. Google Password Manager's approach, while compliant with the WebAuthn "multi‑device" credential model, purposely decouples the key from the hardware to enable sync. This shifts the trust anchor from a tamper‑resistant chip to the user's Google Account security-a trust anchor that infosec veteran NIST SP 800‑63B guidelines would classify as much weaker. For accounts requiring high assurance, relying parties could enforce attestation checks to reject synced passkeys altogether. But today few services do so.

The Role of TPM and Secure Enclaves

Hardware‑bound authenticators use the Trusted Platform Module (TPM) on Windows or the Secure Enclave on Apple devices to seal the private key to the device