Malware already sitting on a Windows PC can slip past every safeguard. No fingerprint scan. No PIN prompt. No flicker on the victim’s screen. It simply signs into passkey-protected services. Palo Alto Networks’ Unit 42 researchers laid out the details in a report released this week. The techniques target Chrome’s implementation of Google Password Manager on systems with a Trusted Platform Module. They expose gaps not in the cryptography itself but in the surrounding code and trust assumptions.
Unit 42 named the three methods Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key. Each builds on the last in power. The strongest extracts a master secret that unlocks every synced passkey tied to the account. Once obtained, that secret travels. The attacker can decrypt private keys on their own machine, long after the initial breach. And none of these paths require privilege escalation beyond ordinary user rights.
Passkeys promised relief from passwords. They bind authentication to hardware and biometrics. They resist phishing. Yet here the threats emerge after the device falls. The attacks assume malware runs with user privileges. They manipulate how Chrome stores device keys, how it re-enrolls after state loss, and how relying parties verify human presence. The Hacker News first covered the findings hours after release. Unit 42 followed with its full technical breakdown.
Start with reconnaissance. Chrome keeps synced credential data in a LevelDB at %LocalAppData%GoogleChromeUser DataSync DataLevelDB. An unprivileged process reads the records without trouble. It pulls relying party names, usernames, credential identifiers, even the encrypted private key material. The attacker now knows exactly which accounts sit behind passkeys. Simple. Effective.
The first attack, Pass-ta-key, impersonates the legitimate device. Chrome maintains a hardware-backed identity key inside the TPM. It exports this key as an opaque blob. Later it reloads the blob with a flag that skips prompts. Unit 42 discovered the key lacks a persistent name in current Chromium source. A code comment explains the choice prevents disk writes. A TODO item flags the issue for future labeling.
Malware grabs the wrapped key. It calls Windows CNG APIs to sign a fresh challenge from the relying party. The signature heads to Google’s cloud authenticator over a WebSocket. The authenticator treats it as valid. It returns an assertion. Only one detail differs from a normal biometric flow: the User Verified bit stays unset. The WebAuthn spec tells relying parties to reject assertions when userVerification is required and that bit reads zero. Some sites do. Others did not.
“GitHub enforced the check,” the Unit 42 team noted. “eBay accepted our test assertion until the company fixed the validation gap following disclosure.” The relying party holds the final say here. Yet many still trust the cloud response too readily. That single bit decides whether passkey login collapses to something closer to possession alone.
Silver Pass-ta-key strikes harder. It targets configurations that demand the UV flag. The attacker forces Chrome into a re-enrollment state. Delete the enclave state file or use the identity key to trigger device invalidation. Next time the user triggers a passkey flow, Chrome starts onboarding again. It defers creation of the user-verification key. In that window the malware registers its own key pair instead.
The cloud authenticator accepts the replacement without checking for secure hardware attestation. The new UV key now carries the verified bit on every signature. The attacker signs in from anywhere. The victim’s device need not stay online. The UV key lives in the cloud record alongside the original identity key. Reusable. Persistent. And the original user never sees a warning.
Golden Pass-ta-key extracts the 32-byte Security Domain Secret, the master key that decrypts all synced passkeys. During re-enrollment the SDS arrives in Chrome’s process memory in plaintext. The malware watches for the enclave state file to update, dumps memory at the right moment, and grabs it. With the SDS in hand the attacker decrypts every private key from the sync database. No further device needed. The entire account portfolio moves to the adversary’s environment.
Google earlier removed the SDS from FIDO device logs after Unit 42’s initial report. The secret still reaches the client during recovery flows. Chrome must obtain it to match the behavior of its mobile counterparts, which do not rely on the cloud authenticator. The design choice creates the exposure. Even now, documentation offers no clear path for users to rotate or revoke a stolen SDS. Changing the Google Password Manager PIN does not appear to invalidate one already captured.
The research carries limits. It examines only Google Password Manager in Chrome on Windows with TPM. Every path begins with malware present. No evidence of wild exploitation has surfaced. No CVEs accompany the disclosure. Searches of the National Vulnerability Database on August 3 returned nothing matching the named techniques. Chromium source confirms architectural elements, yet Unit 42 stopped short of claiming the latest stable release remains fully vulnerable.
Still, the implications stretch beyond one browser. The cloud authenticator model appears in other passkey providers. Onboarding and recovery flows invite manipulation. Relying parties that skip strict UV validation leave doors open. And once an endpoint falls, hardware protections offer less shelter than advertised.
Unit 42 offered concrete fixes. Relying parties must require userVerification and actually check the returned UV bit. They should validate attestation on newly registered keys. They need stronger checks on re-registration events. Unexpected device re-enrollments should raise alarms. Credential providers must keep master secrets out of client memory and logs. Platform controls should restrict access to local passkey storage so malware cannot enumerate targets so easily.
Google has not yet published a detailed response on whether the paths stand closed in production. The company received responsible disclosure. eBay patched its UV validation after the report. Other sites may still lag. Enterprises running Chrome at scale will want to watch for abnormal WebAuthn signature patterns and re-enrollment spikes.
Passkeys reduce phishing risk. They eliminate reusable secrets. They raise the bar. Yet these attacks reveal how implementation details can undermine the model. The cryptography holds. The trust in device state, the deferred key creation, the memory handling, those create the openings. Attackers need only wait for the initial compromise, then operate quietly.
Security teams already preach endpoint hygiene. This research sharpens the point. A single infostealer or remote access trojan can hand over far more than passwords. It can hand over the keys to an identity that travels across every service the victim uses. And the victim may never know until accounts start moving without them.
Recent coverage echoes the urgency. Cybersecurity News detailed the VaultJacking phishing method from May that steals entire vaults with one captured PIN. That technique differs but shares the focus on Google Password Manager weaknesses. Earlier Chrome flaws, such as CVE-2026-6312 and CVE-2026-11083, exposed password data through policy and implementation gaps. The pattern suggests ongoing pressure on the component.
Unit 42’s work stands apart. It targets the passwordless future directly. It shows that even when cryptography survives, the scaffolding around it can fail. Organizations adopting passkeys at volume should review their relying party configurations today. They should demand UV enforcement and attestation checks. They should treat device compromise as a potential identity compromise and prepare revocation paths that actually work.
The findings also press browser and platform vendors. Keep sensitive material out of client memory. Validate every new key against hardware claims. Make recovery flows auditable and resistant to silent hijack. The move to passkeys will accelerate. The adversaries have already started mapping its edges.
Users cannot fix these issues themselves. They can run updated Chrome, avoid suspicious downloads, and monitor account activity. Yet the burden sits with the providers. Google, relying parties, and the WebAuthn community now hold the next moves. The question is whether they will close the gaps before the techniques spread beyond research.