# VaultJacking — Google Password Manager Vault Theft via Single Captured 6-Digit PIN (PhishU Framework)

> VaultJacking is a fully weaponized Adversary-in-the-Middle (AiTM) phishing technique disclosed by PhishU, LLC on 2026-05-20 that captures a victim's 6-digit Google Password Manager (GPM) PIN during a fake Google sign-in, registers an operator-owned WebAuthn passkey for persistence, then replays the PIN from operator-controlled Windows VM infrastructure with a virtualized TPM to join the victim's Google security domain. The join releases the Security Domain Secret (SDS), decrypting the entire synced credential vault — every password and every synced passkey, including hardware-backed credentials — on the attacker's machine. The chain bypasses Device Bound Session Credentials (DBSC) inline at the proxy and produces only two suppressible recovery emails as user-visible signal.

- **Published:** 2026-05-28T00:00:00Z
- **Last reviewed:** 2026-05-28T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-0620
- **ID:** TL-2026-0620
- **Severity:** HIGH
- **Category:** PHISHING
- **Status:** ACTIVE
- **Actor:** PhishU Framework operators
- **Detections:** 9 · **IOCs:** 20 (full data via the Threadlinqs MCP server — Purple tier)

## Description

VaultJacking targets the Google sync layer rather than the per-site WebAuthn handshake, breaking the architectural assumption that passkey synchronization across devices is safely governed by a single short secret. The technique was publicly disclosed by Curtis Brazzell, Founder and CEO of PhishU, LLC, on 2026-05-20 in a detailed engineering write-up titled 'Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault,' which documents the end-to-end implementation now shipping as a default-on feature for any Google-targeted Landing Page in the commercial PhishU Framework. GBHackers carried mainstream news coverage on 2026-05-28.

The attack proceeds in four engineered stages. Stage one phishes the GPM PIN. The PhishU AiTM proxy sits between the victim and accounts.google.com, captures the password and rotating session cookies in the standard Evilginx-class pattern, then injects a runtime-shim modal styled to match Google's own GPM PIN confirmation dialog (matching font, six-cell input layout, and the exact copy 'Confirm your Google Password Manager PIN to keep your synced passkeys available on this device'). The shim disables the underlying password field while the modal is up, so the victim cannot bypass it. The captured PIN posts back through the shim's diagnostic beacon onto the same engagement-database row as the cookies. Operator-side, a single 'Capture GPM PIN (Google AiTM)' toggle on the Landing Page Behaviors tab activates the entire chain.

Stage two registers an operator-owned passkey for persistence. Immediately after AiTM capture, a persistence worker drives a Playwright-controlled Chromium context loaded with the captured session cookies and navigates to myaccount.google.com/signinoptions/passkeys. A Chrome DevTools Protocol (CDP) virtual authenticator answers the WebAuthn registration ceremony and surrenders the private key, which is exfiltrated to the engagement database. The operator passkey is indistinguishable from a user-added passkey on the account, survives password resets and cookie expiry, and crucially is what bypasses Google's reauthentication ladder during stage three — the new-device sign-in from operator infrastructure presents the passkey assertion (silently answered by the worker's virtual authenticator), so Google's reauth accepts it without demanding a push or SMS challenge to the legitimate user's existing devices.

Stage three joins the victim's Google security domain from operator infrastructure. A sync-dump worker runs inside a containerized Windows VM provisioned with a virtualized TPM (vTPM) that presents to the guest as a standard system TPM, generates real key material, and performs real attestation accepted by Chrome's enclave manager. The Windows VM exists solely to satisfy the TPM-attestation step, because Chromium's enclave_manager.cc seals the device identity key against TPM and contacts enclave.ua5v.com (Google's security-domain enclave) with no documented software fallback. A fresh Chrome profile loads the operator passkey into a CDP virtual authenticator, drives sign-in through Google (passkey-first, no password prompt), then triggers a passkey registration against a PhishU-controlled WebAuthn Relying Party endpoint. That registration triggers the security-domain join. The captured 6-digit PIN is typed into the SDS unlock dialog programmatically. Google's cloud authenticator verifies the PIN and releases the Security Domain Secret to the VM, which decrypts every synced password and exposes enclave-mediated signing for every synced passkey on the account.

Stage four operationalizes the vault. Chrome on the VM populates its Login Data SQLite store with every synced password; the worker reads it off disk and decrypts via Windows DPAPI. For passkeys (Chrome 148 and later use enclave-mediated signing — raw key material never touches disk and lives in the passkey_enclave_state profile blob), the worker enumerates metadata (Relying Party, username hint, credential ID) via Chrome's internal chrome.passwordsPrivate API. The enrolled VM Chrome instance stays live; the operator clicks 'Use Passkey' in the captured-credentials UI and the Framework's session-hijack pipeline drives that already-authenticated Chrome to any target Relying Party, where the WebAuthn assertion is routed to Google's enclave and signed server-side. This replay path works against hardware-backed passkeys with equal effectiveness, because the original authenticator type is no longer the signer once the VM is enrolled in the security domain.

The critical architectural property is that the SDS is a master key, not a per-credential key. One successful PIN entry on the security-domain join releases every passkey the victim has ever synced, in one operation. There is no per-site retry, no per-credential PIN re-entry, no rate limit per Relying Party. The blast radius scales with how thoroughly the user adopted GPM-synced passkeys — banking, workplace SSO, source-code repositories, cryptocurrency exchanges, primary email, anywhere the user chose passkey authentication backed by GPM sync.

The chain bypasses Device Bound Session Credentials (DBSC) inline at the AiTM proxy. Per the W3C DBSC specification, DBSC is a post-compromise defense against infostealer cookie replay on a different machine; it is not a defense against AiTM because the proxy is the legitimate client from the server's perspective during the live authentication and negotiates the hardware-attested key in the normal handshake. The PhishU Framework's Google AiTM proxy already handles DBSC transparently. The operator-owned passkey then provides durable persistence that survives any future DBSC enforcement, refresh token rotation, password reset, or session cookie expiry.

User-visible telemetry across the entire chain is two emails to the recovery address: one 'New passkey added' from stage two, one 'New sign-in on Windows' from stage three. No push notifications fire on existing devices. No 'approve from another device' prompts appear. The Chrome activity log records no in-app event on other Chrome instances. SDS unlock and synced credential download produce no notification of any kind. If the AiTM engagement captured the victim's inbox (the standard case for Google AiTM), the operator suppresses both emails before the user sees them. Google chose this PIN-only-with-low-retry-cap design over Apple iCloud Keychain's push-to-all-existing-devices approval model because lost-device recovery is a real UX problem the push model makes worse, and phishability was evaluated as an acceptable tradeoff.

The technique extends Curtis Brazzell's 2020 Medium post 'Phishing Your Password Manager,' which documented how subdomain autofill rules in major password managers allowed a shared apex domain plus a JavaScript-controlled subdomain to harvest credentials directly from the autofill engine. That prior work targeted the local per-site autofill decision; VaultJacking targets the same class of trust-boundary problem one architectural layer up — the cloud-side decision about which devices get to read the entire synced vault.

VaultJacking is not a cryptographic flaw and is not patchable by changes to the WebAuthn handshake or per-site policy. It is an accepted-design-tradeoff in Google's security-domain join, and the defender lever is at the policy, monitoring, and tiering layer rather than the vendor patch cycle.

## MITRE ATT&CK

- T1583.001 Acquire Infrastructure: Domains
- T1587.004 Develop Capabilities: Exploits
- T1588.002 Obtain Capabilities: Tool
- T1566 Phishing
- T1566.002 Spearphishing Link
- T1204.001 User Execution: Malicious Link
- T1059.007 Command and Scripting Interpreter: JavaScript
- T1098 Account Manipulation
- T1098.005 Account Manipulation: Device Registration
- T1098.001 Account Manipulation: Additional Cloud Credentials
- T1684.001 Impersonation
- T1556 Modify Authentication Process
- T1564 Hide Artifacts
- T1070.008 Indicator Removal: Clear Mailbox Data
- T1557 Adversary-in-the-Middle
- T1539 Steal Web Session Cookie
- T1111 Multi-Factor Authentication Interception
- T1555.005 Credentials from Password Stores: Password Managers
- T1555.003 Credentials from Password Stores: Credentials from Web Browsers
- T1606.001 Forge Web Credentials: Web Cookies
- T1087.004 Account Discovery: Cloud Account
- T1550.004 Use Alternate Authentication Material: Web Session Cookie
- T1550.001 Use Alternate Authentication Material: Application Access Token
- T1114.002 Email Collection: Remote Email Collection
- T1071.001 Application Layer Protocol: Web Protocols
- T1041 Exfiltration Over C2 Channel
- T1657 Financial Theft

## Sources

- [Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault](https://phishu.net/blogs/blog-vaultjacking-phishing-the-google-password-manager-vault-in-the-phishu-framework.html)
- [VaultJacking Attack Exposes Google Password Vaults via Single PIN](https://gbhackers.com/google-password-vaults-via-single-pin/)
- [Phishing Your Password Manager (Curtis Brazzell, 2020) — prior art referenced by PhishU](https://phishu.net/blog.html)
- [Chromium source: chrome/browser/webauthn/enclave_manager.cc (security-domain join + TPM-sealed device identity)](https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/webauthn/enclave_manager.cc)
- [Chromium source: components/trusted_vault/ (GPM sync trust anchor + SDS handling)](https://source.chromium.org/chromium/chromium/src/+/main:components/trusted_vault/)
- [Device Bound Session Credentials (DBSC) — W3C Web Application Security Working Group draft](https://w3c.github.io/webappsec-dbsc/)
- [Origin Trials: Device Bound Session Credentials (Chrome)](https://developer.chrome.com/blog/dbsc-origin-trial)
- [PhishU Framework — vendor home (commercial offensive AiTM platform shipping Vaultjacking default-on)](https://phishu.net/)
- [Browser Syncjacking (related sync-layer technique via malicious browser extension — distinct from VaultJacking which needs no extension)](https://www.malwarebytes.com/blog/news/2026/02/password-managers-keep-your-passwords-safe-unless)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-0620