Google Password Manager Hijacked

Overview

Researchers at Unit 42 have revealed three attack paths against Google Password Manager in Chrome on Windows, showing how malware running as an ordinary user can hijack passkey‑protected accounts without requiring fingerprints, PINs, or visible prompts. These techniques — dubbed Pass‑ta‑key, Silver Pass‑ta‑key, and Golden Pass‑ta‑key — exploit how Chrome handles device keys, re‑enrollment, and master secrets, rather than breaking cryptography itself.

Attack Paths

1. Pass‑ta‑key
   • Extracts Chrome’s wrapped device identity key.
   • Uses TPM via Windows CNG calls to sign attacker‑controlled requests.
   • Produces valid assertions but leaves the User Verified (UV) flag unset.
   • Sites enforcing UV checks (e.g., GitHub) block the attack; those that don’t (e.g., eBay before patching) are vulnerable.
2. Silver Pass‑ta‑key
   • Forces Chrome to re‑enroll the device.
   • In the re‑enrollment window, malware registers its own user‑verification key.
   • Assertions signed with this attacker‑controlled key carry the UV flag, enabling logins without the victim’s device.
   • Mitigation: enforce hardware attestation for newly registered keys.
3. Golden Pass‑ta‑key
   • Targets the Security Domain Secret (SDS), a 32‑byte master key.
   • Malware reads SDS from Chrome’s memory during re‑enrollment.
   • SDS can decrypt synced passkey private keys, enabling persistent account takeover.
   • Exposure confirmed in Chromium source; reliable extraction remains under investigation.

Technical Insights

• Chrome stores credential metadata in %LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB.
• Malware can read relying parties, usernames, credential IDs, and encrypted private keys.
• Corners of Chromium source corroborate the architecture, including deferred_uv_key_creation and SDS handling.
• These are post‑compromise techniques — they require malware already running on the victim’s endpoint.

Risks & Implications

• Silent hijacking: Malware can log into accounts without user prompts.
• Reusable access: Silver and Golden paths allow attackers to authenticate from their own environment after initial compromise.
• Validation gaps: Sites not enforcing UV checks remain vulnerable.
• Unclear remediation: No CVEs assigned, and Google has not confirmed whether all paths are closed.

Defensive Guidance

• Relying parties: Set userVerification=required and validate the UV bit.
• Credential providers: Attest newly enrolled keys and strengthen re‑registration checks.
• Users: Treat compromised endpoints as high‑risk; avoid using corporate credentials on untrusted devices.
• Google Password Manager: Needs SDS rotation/revocation controls to invalidate stolen secrets.
• Organizations: Adopt phishing‑resistant MFA and passkeys, restrict local passkey state access, and monitor for suspicious re‑enrollment.

Expert in the Cloud Insight

Pass‑ta‑key attacks highlight a critical truth: endpoint compromise can undermine even the strongest cryptography. By exploiting how Chrome manages keys and secrets, attackers bypass user verification entirely. For defenders, the lesson is clear — security must extend beyond cryptographic strength to cover implementation details, validation checks, and endpoint hygiene.