Google Password Manager Exploit Enables Malware To Hijack Passkey-Protected Accounts

Security researchers have uncovered three attack techniques that could allow malware on a compromised Windows computer to silently access accounts protected by passkeys stored in Google Password Manager, potentially bypassing the fingerprint, facial recognition or PIN verification users expect to protect passwordless logins.

The attacks target the wider infrastructure surrounding synced passkeys rather than breaking the underlying public-key cryptography. They exploit how Google Chrome stores device credentials, communicates with Google’s cloud authenticator, re-enrols devices and handles the master secret used to encrypt synchronized passkeys.

Researchers at Palo Alto Networks’ Unit 42 named the techniques “Pass-ta-key,” “Silver Pass-ta-key” and “Golden Pass-ta-key.” Each represents a progressively more serious form of post-compromise access, ranging from silently generating a valid login response on the victim’s computer to extracting passkey private keys for use on attacker-controlled systems.

The most severe attack could expose the 32-byte Security Domain Secret, or SDS, that protects the encrypted private keys associated with a Google account’s synchronized passkeys. Unit 42 said possession of that secret could allow an attacker to decrypt existing credentials—and potentially passkeys created in the future—without maintaining access to the original computer. Unit 42’s research describes the SDS as the master cryptographic key at the centre of Google’s synchronization architecture.

The findings do not mean attackers can remotely break into any account protected by a passkey. Every demonstrated route begins with malware already executing on a victim’s Windows computer, and the research focused specifically on Chrome, Google Password Manager and systems equipped with a Trusted Platform Module.

There is also no indication that the techniques have been exploited in real-world attacks. Unit 42 did not associate them with a known threat group or malware family, and the researchers did not publish CVE identifiers or a complete list of affected Chrome releases.

Nevertheless, the work highlights an important shift in the passwordless security landscape: passkeys may eliminate phishing and password reuse, but synchronized implementations still depend on local software, cloud-based recovery systems and device-enrolment processes that can become targets in their own right.

Passkeys replace passwords with an asymmetric cryptographic key pair. The website retains a public key, while the corresponding private key is controlled by an authenticator. During login, the service issues a one-time challenge that must be signed with the private key.

Because the private key is not typed into a website or transmitted as a reusable secret, conventional credential-phishing pages cannot simply capture it. A passkey is also bound to a relying-party identifier, preventing a credential created for one legitimate domain from being used on an attacker’s lookalike site.

The W3C Web Authentication specification defines the registration and authentication ceremonies used to create and exercise these credentials. It expects credential private keys to remain under the control of the authenticator and not be exposed to other parties.

Synced passkeys add convenience by allowing a credential to become available across several authorized devices. That requires an additional security system around the private key. The credential must be encrypted, synchronized, recovered and made accessible when a user signs into a new device.

It is this surrounding system—not the signature algorithm or WebAuthn’s domain binding—that Unit 42’s attacks target.

On a supported Windows computer, Chrome enrols the machine with Google’s cloud authenticator and generates two hardware-backed key pairs.

The first is a device identity key that demonstrates that a request originated from an enrolled computer. The second is a user-verification key associated with Windows Hello and intended to indicate that the user unlocked the device using a PIN or biometric check.

Chrome registers the public portions of those keys with the cloud service. Google’s system then establishes a security domain for the account and creates or recovers the SDS used to encrypt the private keys belonging to synchronized passkeys.

According to Unit 42’s earlier technical analysis of Google’s cloud authenticator, Chrome stores the resulting enrolment information in a passkey_enclave_state file within the browser profile. This includes a wrapped device identity key, the user-verification key’s public information, a wrapped copy of the SDS and information supporting Google Password Manager PIN recovery.

Google’s cloud service also maintains a device-specific wrapping key. During a normal passkey operation, the service uses that key to recover the SDS and then uses the SDS to decrypt the required passkey private key.

The private key can consequently remain encrypted while synchronized between devices, while the user’s Google Password Manager PIN provides a recovery route for bringing a new device into the same security domain.

This hybrid design attempts to combine cloud synchronization with device-bound protection. Unit 42’s research shows that weaknesses in the boundaries between those layers can undermine the security properties users associate with passkeys.

Before attempting account takeover, malware needs to determine which passkeys are available.

Chrome stores synchronized WebAuthn credential records in a LevelDB database under the user’s local Chrome profile. Unit 42 said a process executing with the same privileges as the signed-in Windows user can inspect these records without administrator access.

The stored information does not immediately reveal usable plaintext private keys. However, it can disclose enough metadata to map the victim’s passkey footprint, including relying-party identifiers, usernames, credential identifiers and encrypted key material.

That reconnaissance could tell an attacker that a victim has a passkey for a cryptocurrency exchange, developer platform, online retailer, corporate identity provider or another high-value service.

It also illustrates a broader endpoint-security limitation. Encryption can protect the private key itself, but surrounding metadata may still help malware prioritize targets and assemble the information required for subsequent authentication attempts.

The first technique targets the hardware-backed identity key Chrome uses to prove that a request originated from an enrolled device.

Chrome creates the identity key through Windows Cryptography API: Next Generation, or CNG, using the computer’s TPM. Rather than persisting the key under a conventional name, Chrome exports it as an opaque, TPM-wrapped key blob and reloads that blob when the key is needed.

The private key is not exposed in plaintext, and the wrapped object cannot ordinarily be used on a different TPM. The protection is therefore effective against simply copying the blob to another computer.

However, malware already running on the authorized computer does not need to remove the private key from the TPM. Unit 42 found that it could obtain the wrapped blob, import it through standard Windows cryptographic interfaces and ask the original TPM to sign attacker-supplied data.

Because Chrome’s access conditions do not require a Windows Hello prompt for the identity key, the operation can reportedly occur under an ordinary user account without displaying a fingerprint, PIN or approval request.

An attacker can initiate a passkey login, receive a fresh challenge from the target website and communicate with Google’s cloud authenticator. Malware on the victim’s endpoint then uses the legitimate TPM to sign the information required by the cloud service.

The cloud authenticator recognizes the signature as coming from the enrolled device and returns a cryptographically valid WebAuthn assertion.

There is an important limitation. Because the attack uses the identity key rather than the user-verification key, the assertion’s User Verified flag is not set. A correctly implemented website that requires verified-user authentication should reject it.

WebAuthn distinguishes between proof that an authenticator participated in a ceremony and proof that the user was locally verified.

The latter is represented by the UV bit inside the authenticator data. A value of one signals that the authenticator verified the user through an approved method, such as Windows Hello, a device PIN or biometric recognition.

A relying party can request userVerification: “required”, but the server must also inspect the returned authenticator data and confirm that the UV bit is set. Merely placing “required” in the browser request is not a substitute for server-side validation.

Google’s own WebAuthn developer guidance tells relying parties to check both the user-presence and user-verification flags. It notes that userVerification: “preferred” may legitimately return an assertion with UV set to false, while services requiring strong local verification should use “required” and ensure the server verifies the result.

Unit 42 tested the first attack against GitHub and eBay. GitHub rejected the assertion because user verification had not occurred. EBay reportedly requested required verification but, at the time of testing, failed to validate the returned bit correctly and accepted the login.

Unit 42 disclosed the issue to eBay, which corrected the validation gap before publication, according to the researchers.

The comparison demonstrates why passkey security is shared across multiple components. A cloud authenticator can return technically valid information, but the website must still enforce the authentication properties it asked for.

The second attack attempts to overcome UV validation by replacing the verification key itself.

Unit 42 found that Chrome’s device onboarding is not necessarily completed during the first passkey operation on a Windows computer. The browser can enter a transitional state in which the device has been registered but creation of the hardware-backed user-verification key remains deferred.

The researchers said malware could manipulate the local enrolment state and cause Chrome to register the device again. During the resulting window, the attacker supplies a newly generated verification key that the attacker controls.

According to the report, Google’s cloud authenticator accepted the replacement key without establishing that it originated from an appropriately protected hardware authenticator. Once registered, requests signed by the attacker’s key were treated as though the victim had completed Windows Hello verification.

Assertions produced through this route carry the UV flag. As a result, correctly configured websites that rejected the first Pass-ta-key technique could accept the stronger Silver attack because the cloud authenticator itself asserts that user verification occurred.

The attacker would no longer need the victim’s computer for each subsequent login. After registering the substitute key, authentication could be performed from attacker-controlled infrastructure.

This transforms a temporary endpoint infection into reusable account access and makes the technique more consequential than silently proxying an individual login from an infected device.

Unit 42 recommends that credential providers validate the provenance and attestation of newly enrolled identity and verification keys. Re-registration should also require additional proof rather than relying only on state that malware running as the user can delete or manipulate.

Boost SOC ROI 3x with TI Feeds that provide actionable IOCs for detecting latest malware & phishing. Integrate in your team now 👇🏻

The third and most severe technique targets the SDS directly.

Unit 42 initially found that Chrome exposed the secret in plaintext through FIDO diagnostic logs during cloud-authenticator registration. Google removed that logging exposure after the researchers reported it.

The researchers said the architectural problem remained, however, because the SDS continued to be delivered to Chrome and temporarily existed in the browser’s process memory during device recovery or re-enrolment.

Malware can allegedly force Chrome through a fresh onboarding sequence, monitor for changes to the passkey_enclave_state file and capture the browser’s memory when the secret is present. It can then search the captured data for the expected 32-byte SDS.

Combining that master secret with the encrypted WebAuthn records from Chrome’s synchronization database would allow the attacker to recover the private keys associated with the victim’s synced passkeys.

At that point, the attacker no longer needs Google’s cloud authenticator, the original TPM or continued access to the infected endpoint. The extracted private keys can be used by an attacker-controlled authenticator to answer challenges from the corresponding websites.

Unit 42 demonstrated the technique by using recovered material to authenticate to a cryptocurrency exchange.

The researchers further warned that Google’s current design uses the same SDS to protect credentials across the security domain. Their report says there is no exposed mechanism to rotate or revoke that secret, creating the possibility that an attacker who obtained it could decrypt credentials synchronized under the same master key in the future.

That persistence claim is particularly serious, but it currently rests on Unit 42’s analysis. Google’s public documentation does not explain the SDS lifecycle in enough detail for users or administrators to determine whether changing a Password Manager PIN replaces the underlying master secret.

Google allows desktop users to change their Google Password Manager PIN by opening Chrome’s password-manager settings and authenticating again. The company says the PIN helps users access passkeys on new devices, protects encrypted data from Google and verifies the user during passkey operations. Google’s support documentation does not say that changing the PIN rotates the SDS.

Users can also remove individual passkeys or delete all Google Password Manager data. However, Google has not publicly documented an SDS-specific revocation process or explained whether deleting stored passkeys invalidates private-key material already extracted by an attacker.

Deleting a passkey at the relying party remains important because the website can revoke the associated public credential record. Once removed from the account, signatures created with the stolen private key should no longer be accepted.

For suspected compromise, relying-party revocation is therefore likely to be more dependable than assuming that a Password Manager PIN change alone invalidates exposed cryptographic material.

The research describes post-compromise techniques rather than an initial infection method. Attackers would first need to execute malware in the victim’s Windows session through another route, such as phishing, malicious downloads, software vulnerabilities or supply-chain compromise.

That prerequisite materially limits the attack, but it does not make the findings irrelevant. Credential-stealing malware already operates with ordinary user privileges and routinely extracts browser cookies, passwords, tokens and cryptocurrency wallet data.

Passkeys have been expected to limit the value of endpoint credential theft because there is no reusable password to steal. Unit 42’s work suggests attackers could adapt by targeting device identity keys, enrolment state and synchronization secrets instead.

No evidence has been presented that commodity information stealers currently implement these specific methods. Developing reliable versions would also require detailed knowledge of Chrome’s data structures, Google’s cloud protocol and the timing of enrolment operations.

The potential reward, however, is considerable. A successful implementation could give malware developers a way to monetize passkeys through reusable account access or the resale of extracted private keys.

Organizations operating websites with passkey authentication should review the server side of their WebAuthn implementations. Sensitive services should use userVerification: “required” and independently reject any response in which the UV bit is not set.

Developers should not assume the browser or authenticator automatically enforces the relying party’s intended policy. Verification must occur after parsing the signed authenticator data on the server.

Credential providers should require attestation or equivalent cryptographic evidence when identity and user-verification keys are registered or replaced. Recovery and re-enrolment should be treated as privileged operations, with additional verification and notifications to existing trusted devices.

Endpoint defenders can monitor for unexpected deletion or modification of Chrome’s passkey state, suspicious access to its synchronization database, abnormal browser memory collection and unusual processes invoking TPM-backed CNG signing operations.

Enterprises should also consider device-bound hardware security keys for administrators, developers, finance personnel and other high-risk users. Synchronized passkeys provide substantial convenience, but sensitive accounts may benefit from credentials that cannot be exported or recovered through a cloud synchronization domain.

Users who suspect infection should isolate and rebuild the affected endpoint, review their Google account’s signed-in devices and sessions, remove unfamiliar devices and revoke affected passkeys directly from each important account. They should also establish replacement credentials from a known-clean system.

The findings do not overturn the security case for passkeys. They remain highly resistant to phishing, credential stuffing, password spraying and database breaches, and their cryptographic design prevents a compromised website from exposing a reusable password.

Instead, the research shows that the attack surface is moving.

As authentication providers synchronize credentials across devices, they must build recovery, onboarding and cloud key-management systems around the core WebAuthn protocol. Those systems can reintroduce forms of transferable trust that device-bound passkeys were intended to avoid.

The principal lesson is that passkey security depends on the complete chain: the endpoint, hardware-backed keys, browser implementation, cloud authenticator, recovery workflow and the website that verifies the final assertion.

If any layer confuses device possession with user verification, accepts an unattested replacement key or exposes the master secret to compromised software, strong cryptography alone cannot preserve the expected security outcome.