Passkeys aren't magic: Analyzing Unit 42's 'Pass-ta-key' Findings
Has anyone had a chance to deep dive into the Unit 42 report regarding Google Password Manager? It really challenges the narrative that passkeys are the silver bullet for phishing resistance.
The research details three distinct attack paths—Pass-ta-key, Silver Pass-ta-key, and Golden Pass-ta-key—all targeting Chrome's cloud authenticator on Windows. What struck me most is that malware running with standard user privileges can bypass the user verification (UV) requirement. This means no PIN prompt, no Windows Hello biometric popup—just silent authentication.
The "Golden" variant is particularly critical as it targets the master key directly. If an attacker gains access to the user's context, they can essentially decrypt the vault and sign requests as if they were the legitimate user.
Detection seems difficult since this abuse happens at the application logic level rather than the network layer. We might need to start monitoring for unexpected process handles or memory injection attempts targeting Chrome's token storage. I'm currently testing a Sigma rule to catch unsigned binaries interacting with the GPM database paths:
detection:
selection:
TargetFilename|contains: 'Google\User Data\Local State'
ImageLoaded|endswith: '.dll'
condition: selection
Are we seeing this in the wild yet, or is everyone still treating passkeys as infallible? How are you handling the risk of cloud-synced authenticators versus hardware-bound FIDO2 keys only?
This highlights a fundamental tension between usability and security. By defaulting to cloud syncing for passkeys, Google introduces a single point of failure on the endpoint. If the keys were strictly hardware-bound (e.g., never leaving a YubiKey), this specific attack vector wouldn't exist. For high-privilege accounts, we've moved to enforcing security keys-only enrollment and disabling the phone/software backup option in the admin console. It's less convenient, but it eliminates the 'Golden Pass-ta-key' risk entirely.
From a SOC perspective, detecting this is going to be rough. If the malware is running as the user, the API calls look legitimate. We're focusing heavily on the initial access vector instead. If we stop the malware execution via Application Whitelopping, the passkey theft becomes moot.
I'd recommend blocking access to the specific Chrome profile directories from non-chrome binaries using AppLocker, though that might break some legitimate extensions.
It's fascinating that this is specific to the Windows implementation of Chrome's authenticator. I tested this on macOS with the Chrome Canary build, and the Keychain integration seems to handle the user verification prompt differently—it still pops up for UI access.
For pentesters, this is a great post-exploitation module to add to your toolkit. If you have a foothold, dumping the 'Local State' and 'Token Store' is faster than trying to phish the MFA code.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access