Threat reportPhishingTL-2026-0620
VaultJacking — Google Password Manager Vault Theft via Single Captured 6-Digit PIN (PhishU Framework)
VaultJacking (TL-2026-0620), also tracked as Vaultjacking, is a high-severity phishing campaign, first published 2026-05-28. It is attributed to PhishU Framework operators with high confidence, affects Google Google Password Manager, maps to 27 MITRE ATT&CK techniques (T1041, T1059.007, T1070.008), and is covered by 9 detection rules and 20 indicators of compromise.
- Severity
- HIGHAssessed severity
- CVEs
- 0None referenced
- Techniques
- 27MITRE ATT&CK
- Actors
- 1PhishU Framework operators
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 20Indicators of compromise
Key facts for TL-2026-0620
- Threat ID
- TL-2026-0620
- Also known as
- Vaultjacking, GPM Vault Theft, Google Password Manager Sync-Layer Phishing, GPM PIN Phishing
- Severity
- HIGH
- Status
- ACTIVE
- Category
- PHISHING
- First published
- Last reviewed
- Attribution
- PhishU Framework operators
- Attribution confidence
- HIGH
- Motivation
- UNKNOWN
- Target sectors
- government, financial, healthcare, technology, defense, energy, education, retail, media, manufacturing, cryptocurrency, professional-services
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 20
Malware and tooling in VaultJacking
Malware and tooling: Chrome DevTools Protocol (CDP) Virtual Authenticator, PhishU Framework, Playwright
How VaultJacking works
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.
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 techniques used in TL-2026-0620
Exfiltration
T1041 Exfiltration Over C2 Channel
Execution
T1059.007 Command and Scripting Interpreter: JavaScript; T1204.001 User Execution: Malicious Link
Defense Evasion
T1070.008 Indicator Removal: Clear Mailbox Data; T1564 Hide Artifacts; T1684.001 Impersonation
Command and Control
T1071.001 Application Layer Protocol: Web Protocols
Discovery
T1087.004 Account Discovery: Cloud Account
Persistence
T1098 Account Manipulation; T1098.001 Account Manipulation: Additional Cloud Credentials; T1098.005 Account Manipulation: Device Registration
Credential Access
T1111 Multi-Factor Authentication Interception; T1539 Steal Web Session Cookie; T1555.003 Credentials from Password Stores: Credentials from Web Browsers; T1555.005 Credentials from Password Stores: Password Managers; T1557 Adversary-in-the-Middle; T1606.001 Forge Web Credentials: Web Cookies
Collection
T1114.002 Email Collection: Remote Email Collection
Lateral Movement
T1550.001 Use Alternate Authentication Material: Application Access Token; T1550.004 Use Alternate Authentication Material: Web Session Cookie
defense-impairment
T1556 Modify Authentication Process
Initial Access
T1566 Phishing; T1566.002 Spearphishing Link
Resource Development
T1583.001 Acquire Infrastructure: Domains; T1587.004 Develop Capabilities: Exploits; T1588.002 Obtain Capabilities: Tool
Impact
Affected products and versions in VaultJacking
- Google — Google Password Manager
Vulnerable versions: all currently shipping versions as of 2026-05-28 - Google — Google Chrome (sync layer)
Vulnerable versions: all stable versions including Chrome 148+ enclave-mediated passkey signing - Google — Google Account security domain
Vulnerable versions: current production - Google — WebAuthn passkeys synced via GPM
Vulnerable versions: all GPM-synced passkeys including hardware-backed credentials (enclave-mediated signing replay) - Google — Device Bound Session Credentials (DBSC)
Vulnerable versions: all rollouts — bypassed inline at AiTM proxy per W3C DBSC threat model
Remediation for VaultJacking
Patches
- No vendor patch available. Google has not committed to scoping SDS release to the specific credential being registered (the surgical fix that would break Stage Three) or to adopting cross-device push approval for new device adds (the Apple iCloud Keychain model). Defender pressure on Google is the only path to a vendor-side fix; treat as long-term ask, not near-term remediation.
Immediate actions
- Audit Google Workspace Admin audit logs for unfamiliar 'device added to security domain' / 'new passkey added' events; alert at the same severity as new admin account creation.
- For administrator, IT staff, finance, executive, and source-code-committer accounts: enforce hardware-bound device-bound passkeys with no sync, no fallback (Workspace Admin > Security > Authentication > Advanced Protection or equivalent tiered policy).
- Brief high-risk users that any 'New passkey added' or 'New sign-in on Windows' email from Google must be verified out-of-band immediately; treat as authentication event, not informational notice.
- For high-value populations, evaluate migration to a dedicated third-party password manager (1Password, Bitwarden) whose vault is not coupled to Google's security-domain join or SDS architecture; VaultJacking does not apply to credentials never synced into GPM.
Workarounds
- Disable Google Password Manager sync entirely for high-risk populations via Workspace policy (Chrome Browser Cloud Management > User Settings > Password manager > Disabled).
- Disable WebAuthn passkey enrollment to GPM for sensitive roles; require platform-bound or hardware-token passkeys only.
- Force re-authentication windows shorter than current Google defaults for sensitive applications fronted by Google SSO; this does not stop VaultJacking but limits downstream session lifetime if downstream RP detects anomaly first.
- Where Google Workspace context-aware access is licensed, deny GPM-backed authentication from devices not in the trusted device inventory; this reduces (does not eliminate) the operator's path to the security-domain join from arbitrary infrastructure.
Longer-term hardening
- Deploy tiered authentication-strength enforcement across the identity provider: hardware-bound non-syncing passkeys for sensitive roles, synced passkeys with sync-layer monitoring for general workforce, residual sync-layer risk explicitly accepted in writing for low-risk populations.
- Stand up detection engineering around the Google security-domain join event: ingest Workspace Admin audit logs into the SIEM, baseline device-add cadence per tenant, alert on geographic / ASN / user-agent anomalies on device adds.
- Train workforce on Chrome profile hygiene: one Google account per Chrome profile, personal credentials never in a work profile, work credentials never in a personal profile — a captured personal-profile PIN otherwise compromises any work credentials the user synced to that profile.
- Roll AiTM-resistant proxy detection into web-gateway / SWG policy: block known phishing-as-a-service infrastructure categories, alert on TLS/SNI anomalies for accounts.google.com look-alike domains.
Weaknesses (CWE) in VaultJacking
Timeline of VaultJacking
- Curtis Brazzell publishes 'Phishing Your Password Manager' on Medium, documenting subdomain autofill abuse in major password managers — the same class of trust-boundary problem VaultJacking later exploits one architectural layer up at the cloud sync trust boundary.
- Google announces Device Bound Session Credentials (DBSC) Origin Trial in Chrome and publishes the W3C draft. DBSC is positioned as a defense against post-compromise infostealer cookie replay but, per the W3C threat model, does not defend against AiTM where the proxy is the legitimate client during live authentication — a property the PhishU Framework's Google AiTM proxy already exploits transparently.
- Chrome 148 transitions account-backed GPM passkeys to enclave-mediated server-side signing via the passkey_enclave_state profile blob; raw private-key bytes no longer touch the local Passkeys SQLite file. This change makes enclave-mediated replay from any enrolled device equally effective against hardware-backed and software-backed passkeys, an architectural property VaultJacking later weaponizes.
- Browser Syncjacking publicly described — a related technique that reaches the same Google sync layer using a malicious browser extension installed on the victim's machine. Distinguished from VaultJacking, which requires no foothold on the victim's device, no extension, and is fully inline with standard AiTM phishing.
- PhishU, LLC publishes 'Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault' authored by Curtis Brazzell, documenting the end-to-end implementation of GPM PIN capture, operator-owned passkey persistence, virtualized-TPM Windows VM security-domain join, and SDS-mediated full vault decryption. The PhishU Framework simultaneously ships 'Capture GPM PIN (Google AiTM)' as a one-click toggle on every Google-targeted Landing Page, with operator-owned passkey registration default-on.
- PhishU Framework operators report Vaultjacking is generally available in active engagements; the single 'Capture GPM PIN (Google AiTM)' toggle activates the runtime shim, the persistence worker, the virtualized-TPM sync-dump worker, and the Captured Credentials drilldown UI with one click.
- Threadlinqs Intelligence Platform catalogs the technique as TL-2026-0620 with full MITRE ATT&CK mapping, detection guidance for Google Workspace Admin audit logs, and tiered authentication-strength remediation playbook.
- GBHackers publishes mainstream news coverage 'VaultJacking Attack Exposes Google Password Vaults via Single PIN,' amplifying the disclosure and emphasizing that the attack works against hardware-backed passkeys via enclave-mediated signing replay.
- As of 2026-05-29, VaultJacking remains a live, unpatched concern: it has no CVE and is an accepted-design tradeoff in Google's security-domain join, so there is no vendor fix and Google has not scoped SDS release or added push approval. The technique ships default-on in the commercial PhishU Framework, works against hardware-backed passkeys, and is generally available in active engagements per 2026-05 reporting.
Sources cited for VaultJacking
- Vaultjacking: One Captured PIN, the Entire Google Password Manager Vault
- VaultJacking Attack Exposes Google Password Vaults via Single PIN
- Phishing Your Password Manager (Curtis Brazzell, 2020) — prior art referenced by PhishU
- Chromium source: chrome/browser/webauthn/enclave_manager.cc (security-domain join + TPM-sealed device identity)
- Chromium source: components/trusted_vault/ (GPM sync trust anchor + SDS handling)
- Device Bound Session Credentials (DBSC) — W3C Web Application Security Working Group draft
- Origin Trials: Device Bound Session Credentials (Chrome)
- PhishU Framework — vendor home (commercial offensive AiTM platform shipping Vaultjacking default-on)
- Browser Syncjacking (related sync-layer technique via malicious browser extension — distinct from VaultJacking which needs no extension)
Detection coverage for TL-2026-0620
As of 2026-05-28, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-0620 across Splunk SPL, Microsoft KQL and Sigma, covering 20 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.