# Bypass MFA without unlocking: The stealth trick of malware targeting Google Password Manager

## Overview

Just by reading a local LevelDB file on the computer without requiring administrative rights (Admin/System), a common malware can now completely bypass Google's anti-phishing-resistant multi-factor authentication (Phishing-resistant MFA) protection layer.

This shocking discovery of a new attack surface called "Pass-ta-key" from Unit 42 (Palo Alto Networks) raises a big question: Is the glamor of passwordless authentication really as completely secure as we think? By abusing the private key synchronization mechanism, hackers can steal authentication information, simulate biometrics and bypass all MFA barriers. Below is a detailed analysis of how malware bypasses the law, why the current Passkey architecture exposes weaknesses, and what we need to do to prevent it.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/2018b736-0312-4d28-82ab-85b9fc5ab94c.png align="center")

## Passkey Decoding

Before diving into the hole, we need to understand the nature of Passkey. Passkey was born to completely replace passwords, completely solving the problem of password reuse and Phishing campaigns.

### Meaning and Nature

Instead of using a shared secret that both the server and user know, Passkey is based on Public-Key Cryptography according to the WebAuthn/FIDO2 standard.

*   All information on the server is only the Public Key. Server hacking or data leakage will not reveal authentication information.
    
*   An attacker who creates a phishing website cannot obtain a certificate, because the browser's signing process is always tied to the original domain name.
    

### Technical structure

A complete Passkey authentication flow includes the following components:

1.  Relying Party (RP): The service server (e.g. Google, Microsoft) requests authentication.
    
2.  Authenticator: Key management component (can be TPM chip on computer, phone, or YubiKey).
    
3.  Client/Browser: Intermediary bridge to forward challenge from RP to Authenticator.
    

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/0c2bc2ed-1f4f-42e1-b45f-b3ec87f8162b.png align="center")

When you log in, RP sends a random piece of data (Challenge). The Authenticator will use the Private Key deep in the hardware to sign this Challenge and send it back to the verification server. For the signing command to be executed, the Authenticator requires User Presence (touching the device) and usually User Verification (fingerprint, face scan or PIN code).

## Context: When Private Key "Goes to the Clouds"

In the original design (FIDO U2F / Security Key), the private key resides on a single hardware chip. This is extremely safe but brings a "nightmare" to the user experience: if you lose your device, you lose your account.

To solve this problem, Apple, Google and Microsoft introduced Synced Passkey.

*   Private keys are no longer locked to one device, but are encrypted and synchronized to the Cloud (eg Google Password Manager, iCloud Keychain).
    
*   Even though synchronizing to the Cloud, Google protects these private keys with an isolated environment (cloud-enclave) and controls decryption with a "Master Key" attached directly to the hardware (hardware-backed) of each endpoint device.
    

It was this shift from "hard lock" to "synchronous lock" that created a gap. Unit 42 demonstrated that if an endpoint device has been controlled by malicious code (Malware/Infostealer), the complex defense layers behind it can be completely disabled.

## Technical Details

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/f3d6857e-1ca0-4a15-a60c-d397c40b7a26.png align="center")

These attacks target directly Google Password Manager on Chrome browser (Windows) using the TPM chip. The scenario assumes that the victim's device has been infected with malware before.

### Step 1: Information collection process

Execution flow:

1.  Malware operates on an endpoint that silently accesses Chrome's synchronization database at the path: %LocalAppData%\\Google\\Chrome\\User Data\\Sync Data\\LevelDB.
    
2.  Extract WebauthnCredentialSpecifics records (containing encrypted WebAuthn sync data).
    
3.  Lists the services where the victim uses the passkey, user identifier, and encryption private key. Note: This process operates entirely in user-space, does not require Admin/System\* rights.\*
    

### Step 2: Pass-ta-key

The goal is to abuse the "Identity Key" to authenticate on behalf of the victim without them taking action. Execution flow:

1.  Initiation: The attacker selects a target service and clicks "Login with Passkey" on their machine. The service server (RP) returns a Challenge code.
    
2.  Handshake: The attacker initiates a WebSocket connection with Google Cloud Authenticator.
    
3.  Silent Signing: The attacker commands the malware to interact with the victim's TPM. It exports the encrypted identity key from the passkey\_enclave\_state file and uses standard Windows Cryptographic API (CNG API) functions to sign the request without requiring a password or biometrics.
    
4.  Spoofing: The attacker sends a signed request to Google Cloud Authenticator. The cloud mistakenly thinks this is a valid device and returns a valid signature (Assertion).
    
5.  Complete: This signature is sent back to the RP to complete the account takeover (ATO). The disadvantage of this technique is that the User Verified (UV) flag will have a value of 0. If the RP requires UV=1, authentication will fail.
    

### Step 3: Silver Pass-ta-key - Aided by CVE-2026-34348

To bypass the User Verified = 1 barrier (biometrics/PIN required), the attacker registers a fake "User Verification Key". Execution flow:

1.  Delete traces: Malware deletes the passkey\_enclave\_state file on the victim's computer, forcing Chrome to reset the device (re-onboard) the next time the passkey is used.
    
2.  Taking advantage of the waiting state: During the reset process, Chrome puts the system into the uv\_key\_pending state (waiting to create a biometric key later to avoid asking for the PIN code multiple times).
    
3.  Fake key injection: The attacker immediately sends the command device/add\_uv\_key along with a Public Key created by them to Cloud Authenticator. The cloud accepts this key without checking whether it comes from secure hardware or not.
    
4.  Barrier bypass: The attacker uses a fake key (in his hand) to sign requests. The cloud returns Assertion with the UV flag = 1, allowing complete bypass of MFA.
    

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/82903478-b8de-463b-aa63-7d665b370958.png align="center")

Notably, to support the manipulation and collection of fake service data during this process, hackers can further abuse CVE-2026-34s348 (CVSS Score: 6.5) — an information leak vulnerability in the Windows Event Logging service. Reading sensitive operating system logs helps malware mimic the system smoothly.

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/405e790f-2541-4a4c-a61f-48d03ebcf7fc.png align="center")

### Step 4: Golden Pass-ta-key

This is a fatal attack: Steal the "Master Key" (Master Key - SDS) to decrypt all synchronized passkeys. Execution flow:

1.  Force reset: Similar to Silver, the malware forces the browser to re-onboard the device with Cloud Authenticator.
    
2.  Memory Dumping: When Chrome performs connection recovery, it will pull the Master Key (Security Domain Secret - SDS) from Google's recovery repository. This 32-byte long SDS key appears as plaintext for a short period of time in the Chrome process's memory.
    
3.  Stealing SDS: Malware dumps (extracts) Chrome memory and gets SDS.
    
4.  Offline decryption: Using SDS, the attacker decrypts all WebAuthn data (obtained from Stage 0).
    
5.  Appropriation: The attacker holds all the raw private keys of every service the victim uses. They can be used, duplicated, or sold on the black market, completely breaking the core tenets of FIDO.
    

![](https://cdn.hashnode.com/uploads/covers/6777abffdb647396c7d71de4/294dcdb2-f38e-41b0-9f22-d5e296849f5b.png align="center")

## **MITRE ATT&CK Mapping**

*   T1555.003 - Credentials from Password Stores: Credentials from Web Browsers: Malware reads data from Chrome's LevelDB to collect WebauthnCredentialSpecifics.
    
*   T1552.001 - Unsecured Credentials: Credentials In Files: Searching and abusing database files that store local authentication data.
    
*   T1528 - Steal Application Access Token: Although Passkey is not a Token, abusing the signing mechanism in place is equivalent to stealing and maintaining an unauthorized authentication session.
    
*   T1003 - OS Credential Dumping: Chrome process memory dump technique (Golden Pass-ta-key) to extract plaintext SDS key.
    

## Expert opinion

The appearance of Pass-ta-key is a harsh reminder of reality: Passkey solves the Phishing problem very well, but it transfers all risk to Endpoint Security.

In Vietnam, many organizations are tending to "jump" to passwordless to protect end users. However, the infection of malware (especially infostealers like RedLine, Lumma, etc.) through extremely popular cracked/pirated software is the "Achilles heel" of this strategy. If the endpoint has been compromised, Passkey cannot protect users.

In particular, a serious execution vulnerability lies on the Relying Parties (RP) side. Many applications deploying WebAuthn do not require or strictly verify the User Verified (UV) flag in the Authenticator data packet returned. This carelessness accidentally turns multi-factor authentication (MFA) into single-factor authentication.

## Recommended action

The Pass-ta-key attack technique exploits the weakness when the device is infected with malware. Therefore, defense requires a coordinated strategy between both the Technical Team (RP) and the End Users.

### For End-users

*   Be careful with Infostealer malware: Most information-stealing malware (such as RedLine, Lumma) is spread through pirated software (cracks), pirated games, or suspicious email attachments. Absolutely avoid downloading and running executable files from unknown sources.
    
*   Update your system regularly: The fact that malware can take advantage of operating system vulnerabilities (like CVE-2026-34348) to support attacks shows the importance of always keeping Windows and the Chrome browser on the latest version.
    
*   Be wary of unusual PIN requests: If Chrome or Google Password Manager repeatedly asks you to enter "Recovery PIN" or randomly requests biometric scans when you're not actively logged in, it could be a sign that malware is trying to force the system to reset (re-onboard) to steal the Master Key.
    
*   Use anti-virus software (AV/EDR): Make sure your computer is always protected by reputable security software with real-time behavior monitoring features.
    

### For Organizations, Technical Teams & SOCs

*   Patch system errors (Urgent 0-24 hours): Immediately install the latest security updates from Microsoft to patch vulnerabilities. Closing this vulnerability will cut off a link that helps attackers collect event logs.
    
*   Required User Verification configuration (0-24h): Identity Teams/Developers must re-check the WebAuthn/FIDO2 authentication process. Require userVerification="required" and strictly check the UV=true flag on the backend.
    
*   Configure SOC monitoring (0-24h): Set up rules on SIEM/EDR to monitor and block strange processes (not Chrome.exe) that try to read into the %LocalAppData%\\Google\\Chrome\\User Data\*\\Sync Data\\LevelDB folder.
    
*   Update signature (1-7 days): Update the organization's Endpoint Protection/EDR system to identify infostealer patterns targeting WebAuthn data.
    

### For Long-term Strategy

*   Incorporate Device Trust / Zero Trust Conditional Access policy. Passkey authentication should only be approved by the server if the device generating the request is a "clean" device (EDR installed, complies with company policy, no signs of malware infection).
    

## References

[New Attack Methods Enable Malware to Hijack Passkey-Protected Accounts - SecurityWeek](https://www.securityweek.com/new-attack-methods-enable-malware-to-hijack-passkey-protected-accounts/)

[New Passkey Attacks Can Recover Synced Private Keys or Bypass Phishing-Resistant MFA](https://thehackernews.com/2026/08/new-passkey-attacks-can-recover-synced.html)

[Pass the Passkey: A Novel Attack Surface in Passwordless Authentication](https://unit42.paloaltonetworks.com/passwordless-authentication-security-risks/)