Security researchers have discovered that malware can steal Google-synced passkeys from infected systems without requiring user passwords, biometric authentication, or any interaction. The attack exploits the way Google Chrome syncs passkey data, allowing attackers to extract and reuse credentials on different machines. This undermines the fundamental security promise of passkeys as phishing-resistant authentication, revealing a critical gap between theoretical security models and real-world implementation. Organizations relying on passkeys as their primary authentication mechanism need to reassess their security posture immediately.
Introduction
The cybersecurity community has championed passkeys as the solution to credential theft, phishing attacks, and password reuse. Tech giants including Google, Apple, and Microsoft have invested heavily in passkey infrastructure, promoting it as the passwordless future. However, recent research has shattered this illusion of invulnerability.
Malware operating on compromised Windows systems can now extract Google-synced passkeys silently, without triggering any authentication prompts. The attacker requires neither the victim’s Google password nor biometric verification. Once stolen, these passkeys can be used to authenticate on entirely different systems, granting unauthorized access to victim accounts. This discovery represents a fundamental challenge to the passkey security model and raises serious questions about the implementation of supposedly unphishable authentication systems.
Background & Context
Passkeys emerged from the FIDO Alliance and W3C WebAuthn standards as a cryptographic replacement for passwords. Unlike traditional credentials, passkeys use public-key cryptography where the private key never leaves the user’s device. This architecture should theoretically prevent phishing, as attackers cannot trick users into revealing credentials that never traverse the network.
Google implemented passkey support across its ecosystem, allowing users to store passkeys in Google Password Manager with cross-device synchronization via Chrome. This convenience feature enables users to access their passkeys from any device where they’re signed into Chrome, eliminating the need to re-register security keys on each device.
However, this synchronization mechanism creates a new attack surface. When passkeys sync through Chrome, they must be stored locally in an encrypted format. The security of this storage depends entirely on how Chrome protects the encryption keys and under what conditions it allows access to the passkey material.
Previous research has demonstrated various credential theft techniques targeting password managers and browser storage, but the assumption was that passkey theft would require user interaction—specifically, authentication prompts for the device password or biometric verification. This new attack vector bypasses those safeguards entirely.
Technical Breakdown
The attack exploits the trust model between Google Chrome’s sync infrastructure and the local operating system. When a user signs into Chrome with their Google account, the browser establishes a sync relationship that includes passkey data. Chrome stores this synchronized data locally in an encrypted database.
The vulnerability lies in how Chrome manages the decryption keys for this data. On Windows systems, Chrome uses the Data Protection API (DPAPI) to encrypt sensitive data. However, malware running in the user’s security context can access DPAPI-protected data without additional authentication. This means any malware with user-level privileges can decrypt the passkey storage.
The attack sequence proceeds as follows:
1. Malware infects victim's Windows system
- Malware identifies Chrome's passkey storage location
- Malware extracts DPAPI-encrypted passkey database
- Malware decrypts database using DPAPI calls (no auth required)
- Malware exfiltrates passkey private keys
- Attacker imports stolen passkeys on attacker-controlled system
- Attacker authenticates to victim accounts
The stolen passkey material includes the private keys used for cryptographic authentication. Once extracted, these keys can be imported into another Chrome profile on an attacker’s machine. Chrome treats these imported passkeys as legitimate, allowing the attacker to authenticate to any service where the victim had registered that passkey.
Critically, this attack requires no user interaction. There are no authentication prompts, no Windows Hello PIN requests, no fingerprint scans. The malware operates silently, extracting credentials in the background while the user remains completely unaware.
The attack also bypasses the domain-binding protection that makes passkeys resistant to traditional phishing. While an attacker cannot trick a user into using their passkey on a fake domain, they don’t need to—they simply steal the passkey itself and use it on the legitimate domain.
Impact & Risk Assessment
This vulnerability fundamentally undermines the security model organizations have been sold regarding passkeys. Security teams deployed passkeys specifically to eliminate credential theft and phishing risks. The discovery that malware can steal passkeys as easily as it steals passwords negates much of the advertised security benefit.
High-Impact Scenarios:
- Enterprise Account Compromise: Corporate users with synced passkeys on company devices become vulnerable to credential theft through any malware infection, potentially exposing critical business systems.
- Privilege Escalation: Attackers who gain initial access through other means can now escalate by stealing passkeys for administrative accounts.
- Persistent Access: Stolen passkeys provide long-term access unless explicitly revoked, unlike session tokens that expire.
- Cross-Platform Attacks: Passkeys stolen from Windows machines work seamlessly on other platforms, expanding the attacker’s reach.
The risk is particularly severe for organizations that have eliminated legacy authentication methods in favor of passkey-only authentication. These organizations have no fallback defenses when passkeys are compromised.
From a threat modeling perspective, this attack has a low barrier to entry. Commodity malware can be updated to include passkey theft capabilities. No sophisticated exploitation is required—just user-level code execution, which represents the most common malware scenario.
Vendor Response
Google has acknowledged the research but maintains that the issue represents the inherent limitations of malware defense rather than a passkey-specific vulnerability. The company’s position emphasizes that any malware with user-level access can compromise user data, and passkeys are no exception.
In statements to security researchers, Google has argued that:
- The threat model for passkeys assumes device integrity
- Malware with user-level access represents a comprehensive compromise
- Synced passkeys still provide superior protection against phishing compared to passwords
- Users must employ endpoint protection to prevent malware infections
Google has not announced any immediate changes to Chrome’s passkey storage mechanism or sync infrastructure. The company instead directs users toward existing security features like Enhanced Safe Browsing and Chrome’s built-in malware scanning.
This response has generated controversy within the security community. Critics argue that Google marketed passkeys as dramatically more secure than passwords without adequately disclosing the malware theft vector. The “assume device integrity” position is particularly contentious, as real-world environments routinely face malware infections despite best efforts at prevention.
Mitigations & Workarounds
Organizations and individuals can implement several strategies to reduce exposure to passkey theft:
Disable Passkey Sync:
Users can prevent synced passkeys by using platform authenticators that don’t sync. This means managing passkeys individually per device, sacrificing convenience for security.
Chrome Settings → Sync and Google Services → Manage What You Sync
Uncheck "Passwords and Passkeys"Use Hardware Security Keys:
Physical FIDO2 security keys store passkeys in hardware that cannot be extracted via software. This represents the gold standard for passkey security but requires users to carry and manage physical devices.
Implement Endpoint Detection:
Deploy robust EDR solutions configured to detect credential access patterns:
Monitor for unusual access to:
- %LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Data
- DPAPI operations targeting Chrome databases
- Unusual Chrome process injection or memory access
Apply Conditional Access Policies:
Implement risk-based authentication that requires additional verification when authentication occurs from new devices or suspicious contexts, even when valid passkeys are presented.
Restrict Chrome Sync:
Enterprise administrators can use Chrome policies to disable or restrict sync functionality:
SyncDisabled: true
SyncTypesListDisabled: ["passwords"]Detection & Monitoring
Detecting passkey theft requires monitoring for abnormal access patterns to Chrome’s data stores and subsequent authentication anomalies.
Endpoint Indicators:
Monitor for processes accessing Chrome’s storage locations:
# PowerShell script to audit Chrome data access
Get-WinEvent -FilterHashtable @{
LogName='Security'
ID=4663
} | Where-Object {
$_.Message -match "Chrome\\User Data.*Web Data"
}Authentication Anomalies:
Configure SIEM rules to detect suspicious passkey usage:
- Passkey authentication from new IP ranges
- Impossible travel scenarios (authentication from distant locations in short timeframes)
- Authentication patterns inconsistent with user behavior baselines
- Multiple failed authentication attempts followed by successful passkey auth
Network Detection:
Monitor for data exfiltration of Chrome database files:
Alert on outbound transfers of:
- Files matching Chrome database naming patterns
- Encrypted archives containing Chrome User Data directories
- Unusual volumes of data from Chrome process paths
Google Account Activity:
Users should regularly review account activity:
Navigate to: myaccount.google.com/device-activity
Review: Devices with account access
Verify: Recognition of all devices and locationsBest Practices
Security teams should adopt a defense-in-depth approach that doesn’t rely solely on passkey security:
Layered Authentication:
Continue implementing conditional access and risk-based authentication even when passkeys are primary credentials. Additional factors during high-risk operations provide defense when passkeys are compromised.
Regular Security Reviews:
Establish scheduled reviews of:
- Registered passkeys per account
- Device authorization lists
- Authentication logs for anomalies
- Endpoint security posture
User Education:
Train users to understand that passkeys, while resistant to phishing, remain vulnerable to endpoint compromise. Emphasize:
- Reporting suspicious system behavior immediately
- Avoiding risky software installations
- Maintaining system updates and security software
Segmentation:
Implement network and privilege segmentation so that compromised credentials provide minimal lateral movement opportunities.
Incident Response Planning:
Develop specific response procedures for suspected passkey theft:
1. Identify compromised accounts
- Revoke all passkeys for affected users
- Re-register passkeys on verified clean systems
- Review account activity for unauthorized actions
- Assess lateral movement and data access
- Conduct forensic analysis on compromised endpoints
Key Takeaways
- Passkeys are not theft-proof: Malware with user-level access can extract synced passkeys without authentication prompts, fundamentally challenging the passkey security narrative.
- Sync functionality creates risk: The convenience of cross-device passkey synchronization introduces a critical vulnerability absent from hardware-only implementations.
- Defense-in-depth remains essential: Organizations cannot rely solely on passkeys for security; layered controls and endpoint protection are critical.
- Implementation matters more than standards: The FIDO2/WebAuthn standards are sound, but specific vendor implementations may introduce vulnerabilities.
- Threat model assumptions require scrutiny: The assumption of device integrity doesn’t reflect real-world environments where malware infections occur despite preventive measures.
Security professionals must recognize that passkeys represent an improvement over passwords for specific threat scenarios—particularly phishing—but they are not a comprehensive authentication security solution. Deploying passkeys requires the same rigorous endpoint security, monitoring, and incident response capabilities as any other authentication mechanism.
References
- FIDO Alliance WebAuthn Specifications: https://fidoalliance.org/specifications/
- Google Chrome Passkey Implementation Documentation: https://developers.google.com/identity/passkeys
- Microsoft DPAPI Security Considerations: https://docs.microsoft.com/windows/security/
- W3C Web Authentication Working Group: https://www.w3.org/Webauthn/
- NIST Digital Identity Guidelines SP 800-63B: https://pages.nist.gov/800-63-3/
Stay updated at https://cydhaal.com — Your Daily Dose of Cyber Intelligence.
📧 Subscribe to our newsletter at https://cydhaal.com/newsletter/
