Back to all posts

The Phish That Passed Every Check: an AiTM (VoidProxy) Campaign Analysis

12 min read
securityphishingthreat intelaitmvoidproxygooglecloudflare

Summary

On 2026-09-12 the compromised Gmail account of a personal friend sent a Punchbowl-themed “SAVE THE DATE!!!!!” digital-card invitation as a blind-copy blast to its owner’s contacts, myself included. This is the detail that makes the campaign effective: the message arrived from a real, known correspondent, from her authentic account, fully DKIM-signed and validated as coming from her. It cleared both automated authentication and the recipient’s trust, because on every checkable axis it genuinely was from a trusted friend. The single link led, through an anti-analysis gate, to a live Adversary-in-the-Middle (AiTM) reverse proxy of Google’s sign-in. The proxy relayed credentials and the second factor to Google in real time and captured the resulting authenticated session cookie, bypassing 2FA. Compromised accounts were then used to re-blast the lure, producing self-propagation.

The kit’s fingerprints are consistent with the VoidProxy phishing-as-a-service framework (moderate confidence), with technique overlap with Tycoon2FA. The landing domain was a seven-day-old .cfd registration fronted by Cloudflare; the origin reverse proxy ran on an Evoxt VPS (AS149440). A controlled honeypot confirmed the central defensive result: a passkey defeated the attack outright (WebAuthn origin binding), while password plus one-time-code 2FA did not. Layered abuse reporting took the domain offline within ~15 hours (registrar suspension, NXDOMAIN).

This post documents the full chain, the attribution work and its limits, defanged indicators, and detection guidance. All indicators are defanged ([.], hxxps, %3D); the domain is already suspended. The two account-takeover victims are a friend and a family member and are anonymized here.

Delivery and authentication

The message was not spoofed. It was authored inside the compromised account and sent through Google’s infrastructure, so domain authentication passed cleanly:

Check Result
SPF pass (209.85.220.41, Google outbound mail-sor-f41.google.com)
DKIM pass (d=gmail.com, s=20251104)
DMARC pass (header.from=gmail.com)
ARC pass

Supporting signals of account takeover rather than forgery: a Gmail-composed Message-ID ([email protected]), To: undisclosed-recipients:; with a large Bcc set, and a lure whose decorative assets were genuine Punchbowl images (static.punchbowl.com) with an image-proxy cache timestamp months prior to delivery, indicating the attacker reused a real e-card’s rendered HTML as a template.

The practical implication for triage: SPF/DKIM/DMARC “pass” does not indicate a benign message when the sending account itself is compromised. Domain authentication proves custody of the sending domain, not the intent of the human at the keyboard, and here the human at the keyboard was an attacker operating a legitimate account. Worse, the same properties that satisfy the filters also satisfy the recipient: this was not a lookalike domain or a spoofed display name to be scrutinized, but genuine mail from a genuine friend, so both the technical controls and ordinary human caution had nothing to catch. The relevant question is not how the sender was forged (it was not) but how the account was taken over upstream, which the link below answers.

Every actionable element in the email (the card image, the “Open your Digital Card” button, and the “unsubscribe” link) pointed to a single host, htawxjwamiw[.]sngdtg[.]cfd, on the throwaway domain sngdtg[.]cfd. The domain was registered 2026-09-05, seven days before use, through Spaceship, on the low-reputation .cfd TLD, behind Cloudflare DNS and proxy.

The endpoint is not a static clone. It is a live reverse proxy of accounts.google.com. This was confirmed by proxied Google artifacts passing through unchanged:

  • Flow URL …/LV/lb7Fdk/…?…&flowName=GlifWebSignIn&dsh=…
  • Response header x-auto-login: realm=com.google&args=continue%3D…
  • Google’s GAIA session cookie __Host-GAPS set on the phishing origin
  • Google’s boq-identity.AccountsSignInUi JavaScript and real GAIA DOM (name="identifier", jsname="YPqjbf")

Wildcard DNS (*.sngdtg[.]cfd) let the proxy rewrite Google’s ecosystem onto matching subdomains and relay each. Observed rewrites:

Google origin Rewritten to
accounts.google.com htawxjwamiw[.]sngdtg[.]cfd
gstatic boq-identity JS jekilhubhaedeihch[.]sngdtg[.]cfd
kidsmanagement-pa.clients6.google.com kidsmanagement-pa.clients6[.]sngdtg[.]cfd
mail / drive / docs / photos / myaccount / takeout / workspace / support same prefix under sngdtg[.]cfd

Because the real login is proxied, the victim’s password and second factor traverse the attacker and are relayed to Google. Google issues a session cookie, the proxy captures it, and the attacker replays that post-authentication token without a further challenge. This is the mechanism that makes code-based 2FA insufficient: the attacker does not need to predict the code, only to relay it once. The stolen session is then used to send the same lure to the new victim’s contacts (MITRE ATT&CK T1566.002, T1557, T1539).

Anti-analysis chain

The link does not render the Google proxy immediately. It first serves an obfuscated interstitial styled as a routine “Confirm you’re human / Click to verify” check. The interstitial’s design is anti-analysis, not anti-abuse:

Client-side compressed, self-erasing payload. The functional code is lz-string-compressed and stored across hidden data-* attributes (data-jrndcoa, data-bau, data-jsohi concatenate to the JS; data-kpwm to the CSS). A small loader decompresses and eval()s it, injects the CSS, then removes the scripts and blanks the data attributes. A post-execution DOM snapshot is empty. The document also carries a randomized <title> per load and decoy filler sentences (“An octopus inside a crocodile!”, “In ancient times pandas among impartial oranges.”) to degrade text classifiers.

SHA-256 proof-of-work handshake. Clicking “verify” issues:

GET  origin?<paramKey>1=<rand>-<SHA256(<paramKey> + <rand>)>

where <paramKey> is the query-parameter name from the inbound link and <rand> is a client nonce. The server replies with a short string that is base64, reversed, using $ as the = pad. Decoding it (reverse, $→=, base64-decode) yields the next path. Observed example: $$wa4gzaJpFN582a2M3L → /s6ko94ZIk88k, which 302-redirects into the proxied Google flow. A crawler that does not execute the JavaScript, click, compute the hash, and re-request never reaches the credential surface.

The chain was mapped by replaying this handshake protocol from the command line, without executing the attacker’s JavaScript in a browser.

Honeypot walk-through and the passkey result

To observe post-compromise behavior, a disposable Google account with no real data, seeded with controlled decoy contacts, was walked through the proxy in an isolated browser and allowed to submit a working session. Two results:

A passkey defeated the attack. The proxied Google flow’s preferred factor was a passkey, and it could not complete on the phishing origin. WebAuthn assertions are cryptographically bound to the relying-party origin (accounts.google.com); presented on htawxjwamiw[.]sngdtg[.]cfd, the authenticator has no credential for that origin and will not sign. There is nothing for the proxy to relay. Passkeys are phishing-resistant against AiTM by construction.

Code-based 2FA did not. Only after falling back from the passkey to password entry and a one-time code did authentication complete. The proxy relayed both to Google in real time and captured the session. SMS, TOTP, and email one-time codes provide no protection against AiTM because they are relayable.

The operational takeaway for defenders: the presence of MFA is not the control that matters; the factor’s phishing resistance is. Migrate high-value accounts (email first, as the account-recovery root) to passkeys or hardware security keys.

Attribution

Kit family: VoidProxy, or a close variant (moderate confidence). The decisive signal is the pairing of algorithmically generated nonsensical decoy sentences plus randomized page titles with a .cfd throwaway, Cloudflare fronting, and a real-time reverse proxy of Google (the architecture also supports Microsoft). This combination is attributed to VoidProxy in Okta’s reporting.

Fingerprint (observed) Match
Nonsensical decoy sentences + randomized titles VoidProxy signature (Okta)
Low-reputation .cfd TLD one of VoidProxy’s named TLDs (Okta)
Cloudflare-fronted AiTM, human-check first stage VoidProxy (Okta)
Reverse proxy of Google/Microsoft, session-cookie theft VoidProxy (Okta)
DOM-vanishing (script self-removal) Tycoon2FA technique (Microsoft, LevelBlue)
Per-stage custom encoding; geo-gating Tycoon2FA-class technique

Divergences that cap confidence at moderate rather than high:

  • The session cookie observed here is __wkjkrc, which does not match VoidProxy’s documented Google cookie (__xxdomstate) or any published Tycoon2FA cookie. Two honest caveats: this is a single sample (the name was stable across every request to this one deployment, but I cannot confirm from one domain whether it is a fixed build constant that recurs across the operator’s fleet, or a per-deployment value), and its absence from every public feed is over-determined (equally consistent with a genuinely novel constant, a per-deployment random, or simply a domain too fresh and low-volume to be indexed). VoidProxy’s documented cookies are reported as consistent across attacks, which makes a fixed newer-build constant plausible, but that inference rests on the attribution. Treat __wkjkrc as a candidate indicator pending multi-sample confirmation.
  • Okta documented VoidProxy’s first stage as a Cloudflare Turnstile challenge; this sample used a custom “Click to verify” gate with the lz-string/eval/DOM-wipe loader and SHA-256 proof-of-work handshake described above.

Origin host. Cloudflare’s abuse response identified the origin as Evoxt Sdn. Bhd. (AS149440 / AS212083), a Malaysia-registered budget VPS provider. The Google-facing reverse proxy runs on an Evoxt VPS behind Cloudflare, matching the VoidProxy architecture (cheap VPS origin, Cloudflare front). The operator, a customer of both the PhaaS and the VPS, is not identifiable from external evidence.

Attribution limits. Passive origin/operator attribution was walled at every turn, which is itself a useful data point about the operator’s operational security and the freshness of the infrastructure:

  • Passive DNS (VirusTotal, HackerTarget): sngdtg[.]cfd resolved only to Cloudflare from registration onward; no pre-Cloudflare origin window.
  • Certificate transparency (crt.sh): no logged certificates (TLS terminated at Cloudflare’s edge).
  • urlscan.io: zero prior scans; per-load randomization and no indexed content defeat structural sibling pivots without paid intelligence.
  • WHOIS: fully privacy-redacted.
  • A ~50-name subdomain sweep found no non-Cloudflare (origin-leaking) record.

The one remaining lead was the honeypot: the attacker’s own IP would be written to the throwaway account’s activity log on any replay of the stolen session. No replay occurred in the day-plus following capture, and the domain was suspended in that window.

Takedown

Layered abuse reports were filed against each layer: Cloudflare (CDN/DNS/proxy), Spaceship (registrar), CentralNic (.cfd registry), Evoxt (origin host), and Google Safe Browsing, plus blocklist submissions.

Time (approx., after reporting) State
T+0 live kit, HTTP 200
T+~2h Cloudflare “Suspected Phishing” interstitial (HTTP 403, Turnstile bypass): a soft, bypassable block
T+~15h registrar suspension: nameservers moved to Spaceship suspension servers, host and apex NXDOMAIN, unreachable
T+1 day still suspended

Cloudflare’s response applied quickly but was a warning rather than removal; the registrar suspension was the durable takedown. The single highest-value report was to the registrar and registry (the layer that can render the domain NXDOMAIN); the origin-host report matters independently because the VPS likely serves other campaigns.

Detection and hunting

Network and content indicators useful for hunting the kit and family:

  • HTML documents whose functional logic is lz-string-compressed in data-* attributes and eval()’d, followed by removal of scripts and blanking of those attributes.
  • Nonsensical “noun-salad” filler sentences in page source, paired with a randomized alphanumeric <title>.
  • A first-request handshake of the form ?<param>1=<digits>-<64 hex chars> returning a short reversed/$-padded base64 string.
  • Requests loading Google boq-identity / AccountsSignInUi resources, or carrying flowName=GlifWebSignIn / x-auto-login: realm=com.google, from a non-Google apex domain.
  • Wildcard subdomains on a young, low-reputation TLD (.cfd, .icu, .sbs, .xyz) rewriting Google/Microsoft service hostnames, fronted by Cloudflare.
  • Newly registered domain (days old) with WHOIS privacy, Cloudflare nameservers, and an origin on low-cost VPS ASNs.
  • A response cookie named __wkjkrc on a non-Google origin, as a lower-confidence candidate (see the single-sample caveat above).

Identity-side detections that catch AiTM regardless of the front-end kit: sign-ins where the session-issuance IP/ASN differs from the user’s normal egress; impossible-travel between authentication and subsequent activity; and session tokens replayed from hosting/VPS ASNs. Preventively, enforce phishing-resistant (FIDO2/passkey) authentication for high-value accounts; non-relayable factors close the class of attack.

MITRE ATT&CK: T1566.002 (phishing: spearphishing link), T1557 (adversary-in-the-middle), T1539 (steal web session cookie), T1583.001 (acquire infrastructure: domains).

If an account was compromised

Session-cookie theft means a password change alone is insufficient; existing sessions must be revoked.

  1. Change the password.
  2. Revoke all other sessions (Google: Security, then Your devices). This invalidates the stolen cookie.
  3. Remove persistence: audit mail filters, forwarding addresses, “send mail as” aliases, and connected apps / app passwords. Attackers add these to retain access after a password reset.
  4. Confirm recovery email and phone are unchanged.
  5. Enroll a passkey or hardware key as the primary factor.

Indicators (defanged)

  • Domain: sngdtg[.]cfd (registered 2026-09-05; Spaceship / CentralNic .cfd)
  • Landing host: htawxjwamiw[.]sngdtg[.]cfd
  • Emailed URL: hxxps://htawxjwamiw[.]sngdtg[.]cfd/?Pj7iGNQK2bI%3DdXh2ZmFy
  • Front: Cloudflare (DNS + proxy; wildcard *.sngdtg[.]cfd; NS evan/meiling.ns.cloudflare.com)
  • Origin host: Evoxt Sdn. Bhd., AS149440 / AS212083
  • Kit cookie: __wkjkrc (single sample; candidate indicator)
  • AiTM subdomains: htawxjwamiw, jekilhubhaedeihch, jekilhuebehbcgcih, jekilhucbfbaijbdj, kidsmanagement-pa.clients6, mail, drive, docs, photos, myaccount, takeout, workspace, support, families, business, plus, notifications, www (all under sngdtg[.]cfd)
  • Lure: Punchbowl-branded “SAVE THE DATE!!!!!” e-card, Bcc blast from a compromised Gmail account (SPF/DKIM/DMARC pass)
  • Family: VoidProxy (moderate confidence); Tycoon2FA technique overlap

References

  • Okta, Uncloaking VoidProxy: a novel and evasive Phishing-as-a-Service framework — okta.com
  • BleepingComputer, New VoidProxy phishing service targets Microsoft 365, Google accounts — bleepingcomputer.com
  • Microsoft Security, Inside Tycoon2FA — microsoft.com
  • LevelBlue / SpiderLabs, Tycoon2FA New Evasion Technique — levelblue.com
  • Push Security, How AiTM phishing kits evade detection, Part 2 — pushsecurity.com
  • Elastic Security Labs, Tycoon 2FA AiTM detection for Entra ID and Google — elastic.co
  • MITRE ATT&CK: T1557, T1539, T1566/002