Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault | PhishU Blog
We are calling it Vaultjacking. One captured Google Password Manager PIN, and a phishing attacker walks away with the victim's entire passkey and password manager vault. Banking, email, source code, workplace single sign-on, crypto exchange, anywhere the user chose to lean on Google Password Manager (Chrome) to remember them. One phishing engagement, total compromise.
Post-publication note: After this article published we became aware of Browser Syncjacking, a separate technique that reaches the same Google sync layer using a malicious browser extension installed on the victim's machine. Vaultjacking requires no foothold on the victim's device and no extension. It is fully inline with standard Adversary-in-the-Middle phishing. We tested the technique end to end against live GPM accounts, including replay of captured third-party passkeys regardless of whether the original credential was hardware-backed.
1 PIN.<br>One captured 6-digit PIN unlocks the entire Google-managed credential vault on a device the operator controls. Every synced password and every synced passkey the victim has ever saved, decrypted in one operation, on infrastructure the operator owns. No per-site retry. No rate limit. One phish, N credentials.
Passkeys do their job at the per-site login layer. The WebAuthn handshake binds the credential to the site's origin, and that binding cannot be relayed. Vaultjacking targets a different layer: the sync layer underneath. Google Password Manager (GPM) synchronizes passkeys and passwords across every device that joins the user's security domain. The store on each device decrypts with a key called the Security Domain Secret (SDS), which Google's cloud authenticator releases to a device when that device joins the security domain. The join is governed by one short secret: the user's 6-digit GPM PIN. Capture that PIN during a normal Adversary-in-the-Middle (AiTM) sign-in, replay it later from operator infrastructure, and the entire synced credential vault decrypts on the operator's machine.
The PhishU Framework now ships Vaultjacking end to end. The AiTM proxy captures the PIN alongside the session cookies on the phishing Landing Page. A background worker automatically adds an operator-owned passkey to the victim's Google account for long-term persistence. A second worker joins the security domain from operator infrastructure, types the PIN at the unlock prompt, and writes the unwrapped credentials back to the engagement database. The operator clicks one icon in the Captured Credentials view and sees the entire vault.
This research extends a thread Curtis Brazzell, PhishU's Flounder and CEO, has been pulling on since 2020. That year he published Phishing Your Password Manager on Medium, documenting how subdomain autofill rules in major password managers allowed a shared apex domain plus a JavaScript-controlled subdomain to harvest stored credentials directly from the autofill engine. That technique targeted the local per-site decision a password manager makes when it decides whether to fill a form. Vaultjacking targets the same class of trust-boundary problem one layer up: the cloud-side decision about which devices get to read the entire synced vault, governed by a single short secret rather than per-site origin matching.
How Synced Passkeys Actually Work
A Google account has a security domain. Devices that join the security domain can read every synced passkey and password on the account. A review of the Chromium source (chrome/browser/webauthn/enclave_manager.cc and components/trusted_vault/) shows the join flow on a new device requires two server-validated checks: a normal Google account sign-in, and a successful entry of the user's GPM PIN.
Google does enforce reauthentication at the sign-in step for new-device flows, and that reauthentication is a genuine security measure that challenged the technique during development. The Framework gets through it using the operator-owned passkey added in Step Two: by the time the sync-dump worker signs in from new infrastructure, that passkey is already registered on the account, so Google's reauth ladder accepts the passkey assertion (silently answered by the worker's virtual authenticator) rather than demanding a push or SMS challenge to the legitimate user. Past that one gate, there is nothing else. No push to existing devices, no "approve from another device" prompt. The PIN verifies, the cloud releases the SDS, and the new device decrypts every passkey on the account.
The structural choice that makes this work is the absence of cross-device approval. Apple iCloud Keychain prompts every existing device to approve a new one joining the keychain. Google does not. This is not an oversight: Google chose 6-digit PIN with a low server-side retry cap over Apple's push-to-existing-devices model because lost-device recovery is a real UX problem the push model makes...