- What: Researchers detailed "Pass-the-Key" attacks in which infostealer-class malware on an already-compromised endpoint abuses Google Password Manager's passkey sync and device-enrollment flows to place an attacker device inside the victim's credential sync fabric.
- Impact: Any account protected by a synced passkey — Google, Microsoft, GitHub, banking, SaaS admin consoles — can be authenticated into from attacker infrastructure without the victim's phone, password, or an MFA prompt they would recognize.
- Fix / mitigation: No CVE has been assigned because this abuses designed sync behavior; mitigate with device-bound passkeys or FIDO2 hardware keys for privileged accounts, enforce Google Advanced Protection, and treat any endpoint infostealer detection as a full passkey-reset event.
- Who's at risk: Organizations that moved admins and executives onto synced passkeys in Google Password Manager and assumed the credential was hardware-bound.
The pitch for passkeys was that stolen credentials stop mattering. Pass-the-Key breaks that pitch — not by cracking cryptography, but by walking through the sync layer that makes passkeys usable in the first place. Malware sitting on a machine you already lost can enroll attacker-controlled hardware into the victim's Google Password Manager sync group and then produce valid WebAuthn assertions for every synced passkey on that account. No credential phishing. No push-bombing. No prompt the user would recognize as hostile.
With more than 15 billion accounts now passkey-enabled across the major identity providers, and with most enterprise rollouts defaulting to synced rather than device-bound credentials, the exposed population is not niche. If your privileged users authenticate with a passkey that lives in Google Password Manager, this is your threat model now.
What actually breaks
A passkey is a WebAuthn credential: a private key that signs a challenge from the relying party. The phishing resistance comes from origin binding — the browser will not sign a challenge from evil-corp-login.com for an origin of accounts.google.com. That property is intact. Pass-the-Key does not attempt to defeat it.
Instead it attacks the layer beneath: the synchronization fabric. To move a passkey between a laptop, a phone, and a tablet, the provider wraps the private key material and replicates it through the user's account, gated by a recovery secret and a device-enrollment ceremony. That ceremony is the target. Malware with local access to browser process memory, the Chrome profile directory, and the OS-level token store can harvest the material needed to satisfy enrollment and present itself as a legitimate new device. Once enrolled, the attacker's machine receives the same synced credentials the victim has, and every subsequent signature is cryptographically valid because it is cryptographically valid. The relying party has nothing to reject.
There is no patch to apply, no CVE to close, and no vendor advisory that resolves it. Sync-enrollment is intended behavior. The attack requires prior endpoint compromise, which means the industry's answer — "assume the endpoint is trusted" — is exactly the assumption that fails. Treat every infostealer hit on a passkey-enrolled endpoint as an authenticator compromise, not just a session-cookie cleanup.
The chain, step by step
- Initial access via commodity loaders — malvertising, fake installers, ClickFix-style paste-to-run lures, or a trojanized dev tool. Nothing exotic.
- Local collection: the Chrome profile directory, DPAPI-protected state on Windows, Keychain items on macOS, and in-memory browser artifacts are pulled in a single pass alongside conventional cookie and password theft.
- Sync-state extraction: the malware recovers the material needed to satisfy Google Password Manager's device-enrollment check rather than trying to lift a raw private key.
- Attacker device enrollment: an attacker-controlled browser or emulated client joins the sync group and pulls down the synced passkey set.
- Assertion replay: the attacker authenticates to relying parties directly from their own infrastructure, producing signatures that pass origin and signature-counter checks cleanly.
- Persistence: because the attacker device is a legitimate sync participant, a password reset alone does not evict it.
Why your detections will miss it
Post-enrollment, there is no anomalous authentication artifact at the relying party. The assertion is well-formed, the AAGUID is a legitimate software authenticator, and the signature counter increments normally. Impossible-travel and IP-reputation logic will fire only if the attacker is sloppy about proxying — and infostealer operators have been buying residential proxy pools in the victim's ASN for years. Conditional access policies keyed on "phishing-resistant MFA satisfied" will happily wave the session through, because it was satisfied.
The only high-fidelity signal is the device-enrollment event itself. Pull Google Workspace admin audit logs for new device additions and password-manager sync joins, correlate against known endpoint inventory, and alert on any enrollment from an ASN, OS build, or client fingerprint that does not match a managed asset. In identity providers, alert on new authenticator registration for privileged accounts as a P1, not an informational event.
Fixes that actually change the outcome
- Move admins, executives, finance, and anyone with production access to device-bound credentials — YubiKey, Titan, or platform authenticators configured non-syncable. A hardware key cannot be enrolled into a sync group by software.
- Enable Google Advanced Protection Program for high-value accounts; it enforces hardware-key attestation and restricts recovery paths the attack depends on.
- In Workspace, restrict which devices may join sync via context-aware access, and require managed-device posture for credential sync.
- Rewrite your infostealer playbook: revoke sessions, rotate passwords, and additionally deregister every authenticator on the account and re-enroll from a known-clean device. Cookie invalidation alone leaves the attacker enrolled.
- Shorten session lifetimes and require step-up reauthentication with a hardware key for privileged operations, so a valid assertion is not a permanent skeleton key.
- Instrument EDR for reads of Chrome profile and Keychain/DPAPI artifacts by non-browser processes — that access pattern remains the earliest reliable indicator.
The takeaway
Passkeys still kill credential phishing, and nobody should slow a rollout over this. But the marketing conflated two different guarantees. Phishing resistance is a property of origin binding. Theft resistance is a property of key storage — and a synced passkey is stored, ultimately, in software that malware can reach. Sort your accounts by blast radius, put hardware behind the top tier, and stop treating endpoint compromise as a containable event when your authenticators live on the endpoint.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us