VaultJacking — Google Password Manager Vault Theft via Single Captured 6-Digit PIN (PhishU Framework) — Threadlinqs Intelligence
As of 2026-05-30, VaultJacking — Google Password Manager Vault Theft via Single Captured 6-Digit PIN (PhishU Framework) is a high-severity phishing threat attributed to PhishU Framework operators, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 20 indicators of compromise.
Threat ID: TL-2026-0620 · Severity: HIGH · Status: ACTIVE · Category: PHISHING
Attribution: PhishU Framework operators · UNKNOWN
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
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
Weaknesses (CWE)
CWE-294, CWE-308, CWE-1390, CWE-345, CWE-602
Target sectors: government, financial, healthcare, technology, defense, energy, education, retail, media, manufacturing, cryptocurrency, professional-services
Target regions: Global
Detections & IOCs
As of 2026-07-28, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 20 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
PHISHING, HIGH, threat intelligence, cybersecurity, T1583.001, T1587.004, T1588.002, T1566, T1566.002, T1204.001, T1059.007, T1098, T1098.005, T1098.001