Inside a .claims Phishing Kit: a reCAPTCHA-Skinned Turnstile Gate and a First-Party XOR Exfil Channel

A cross-sector phishing campaign has been registering victim-named lookalike domains in a company.claims / company-claims.com pattern since late July 2026. ReliaQuest described its shape on 2026-08-17 with no domains attached. Flare then enumerated the infrastructure — 61 domains, 48 brands, all one registrar, none ever serving content — and made the point that there was “no phishing kit to fingerprint, no lure text to quote and no landing page to screenshot, because none of that exists yet.”

We have the kit. It was recovered from a live deployment that targeted us before the domain was torn down. This post is a teardown of that kit, not an indicator dump — the victim-named domains are withheld here for the same reason Flare withheld them: publishing a consolidated target list helps the operator more than it helps defenders, and the affected organizations were already notified through their sector ISACs. What is published in full below is the operator’s own machinery.

Flare’s account of infrastructure that was “provisioned and idle” — “not one of the 61 domains has served content” — was accurate for the set and window it watched, and Flare was explicit that the campaign’s state “may be further along.” This is that further state. A campaign domain observed idle, holding a same-day certificate and serving nothing, is ambiguous in passive data: indistinguishable from one that went live against a target for a few hours and was burned back to a parked hostname. This kit’s whole pattern is short-lived activation — ours served the flow, was used, and reverted to a dead name any later scan reads as dormant. “None served content” is exact only as “none was observed serving content in the collection window,” which fits both never-used scaffolding and already-spent infrastructure. The difference decides whether a named organization blocks a domain or hunts an intrusion that already happened.

That reading is no longer inference. Two organizations named in this campaign’s domain set have publicly confirmed activation. McKesson filed an SEC Form 8-K on 2026-08-25 disclosing a cybersecurity incident that reporting ties to a mckesson.claims lookalike and a vishing-to-Okta compromise (Mind; the group claimed roughly a terabyte over four days). ReliaQuest — which published the advisory that first exposed the campaign — was itself targeted days later through a reliaquest.claims SSO page; that intrusion was caught and blocked by device-trust controls, with no systems accessed (BleepingComputer). One breach, one blocked attempt, both against domains from the same set that passive collection observed serving nothing. “Provisioned and idle” is a snapshot of the quiet moments between activations, not a description of the campaign. The kit Flare reasoned must exist, does.

Two things in this kit are worth more than the intrusion.

First, the gate that hid it. The anti-bot challenge is a real Cloudflare Turnstile dressed as a Google reCAPTCHA — and because the Turnstile is real, only a human who solves it is served the phishing page. Scanners and sandboxes fail it and are bounced to the real okta.com, which is exactly why this campaign has read as “provisioned and idle” to everyone collecting it passively. The content is real; the gate only shows it to a live victim.

Second, where the credentials go. Exfiltration is first-party — POSTed to the operator’s own server over an XOR-obfuscated channel keyed off a cookie the page sets, with no Telegram relay. That is a hard break from the Work Panel / Doko kits that dominate this ecosystem and forward every capture to a Telegram bot.

Delivery

Delivery is a phone call, not an email. A caller works a help-desk, IT, security-update, or passkey-enrollment pretext — and, newer in this campaign, legal-team impersonation and posing as a known internal colleague — and directs the target to a victim-named domain in the .claims TLD or a -claims.com / claims- construction. None of the campaign domains carries an MX record; across the set we verified, mail exchange records are universally absent. These domains are destinations, not senders. Whatever routes a target to them originates elsewhere — the phone call — which is why the email-security layer never sees the attack.

The caller steers the target to open the link on their phone. That is a deliberate choice, not an incidental one: a mobile browser sits outside the corporate proxy and the endpoint agent, so the request to the phishing host never crosses the controls that would inspect it, and the page renders on a screen where a lookalike domain and a clean TLS padlock are harder to scrutinize. By the time credentials are typed, the whole exchange has happened off the managed estate.

The gate

The kit is a Next.js single-page app wrapped with obfuscator.io (base64+RC4 string array, checksum rotator). Deobfuscated, the entry component LoginHandler first bounces automation before any phishing content renders:

if (navigator.webdriver === true || !navigator.languages || navigator.languages.length === 0) {
  window.location.replace("https://www.okta.com");   // send scanners to the real site
  return;
}

then renders the gate and polls an operator status endpoint every three seconds:

turnstile.render(node, { sitekey: "0x4AAAAAAD_QLVtvi0dxDbRU", theme: "light" });
// every 3000ms:
const s = await fetch("/z").then(r => r.json());        // adminStatus
if (s.isPaused || s.banned) window.location.replace(s.redirectUrl || "https://www.okta.com");

The /z poll is a live kill switch: the operator can pause or ban a session in real time and redirect the victim away. The captcha response (/w) returns a panelType, so the server — not the client — decides which brand panel to render next.

The reCAPTCHA-skinned Turnstile

The gate draws a faithful Google reCAPTCHA: the checkbox, the spinner keyframes, the reCAPTCHA logo, a “Terms” link to google.com/intl/en/policies/terms. Over that visible widget, the kit mounts the real Cloudflare Turnstile element and drops it to 1% opacity:

(0, r.jsx)("div", {
  ref: n,                        // the Turnstile mount
  style: {
    position: "absolute",
    top: "-2px", left: "4px", right: "-4px", bottom: "2px",
    opacity: .01,                // invisible, but it's what the click lands on
    cursor: "pointer",
    zIndex: 10
  }
})

The victim clicks Google; Turnstile is what actually validates. The technique defeats the same automated analysis that a genuine reCAPTCHA would, while presenting a more familiar and less suspicious challenge than a bare Cloudflare interstitial.

This resolves an open question in prior reporting. Bridewell’s analysis of the shared kit (From a Vishing Call to a Shared Com Ecosystem) flagged a legitimate Turnstile sitting behind an unexplained “wrapper page.” The wrapper is a brand-swap disguise, and in this variant the brand it wears is Google reCAPTCHA. The individual parts are all documented elsewhere — clickjacking opacity overlays, fake CAPTCHA skins, real Turnstile used as an anti-scanner gate — but we have not found the specific inversion, a fake Google skin laid over a live hidden real Turnstile in one DOM, documented for any named kit. Treat it as a finding of this teardown, not a known technique.

The sign-in and the relay

Past the gate, the victim reaches a pixel clone of their own organization’s Okta sign-in — a real-time adversary-in-the-middle relay, not a passive collector. The victim types username and password into the page; the kit relays them to the genuine Okta tenant. The tenant demands MFA, the page presents the matching field, and — in the flow we observed — the victim enters the one-time code directly into the phishing page. The kit relays that too; authentication completes; the session is captured. The caller stays on the line throughout, narrating the steps so the prompts feel like the legitimate flow they imitate.

Because the page shown next is server-chosen (the panelType from /w), the kit can drive whichever factor screen the real tenant returns. We only saw the OTP path exercised. MirageSec’s playbook describes the number-matching variant, where the page “retrieves the live challenge digit from the operator’s server and shows it to the victim” — a method common to Google and Microsoft number-match, not only Okta. The consistent rule across all of them: “every factor the kit accepts can be relayed, every factor it refuses is origin-bound.” SMS and TOTP codes pass; FastPass, FIDO2 keys, and PIV/CAC cannot be replayed against a different origin and fail. The kit also rewrites the visible URL to resemble an Okta /saml/sso redirect, which we observed. Phishing-resistant MFA is the control that turns the whole chain into a failed call — ReliaQuest’s device-trust block is the worked example.

The control channel and its exfil

Deobfuscated, the client exposes a compact single-letter route map:

/w  captcha (returns panelType)   /e  login  (POST captured creds / OTP)
/d  visit beacon                  /u/<id>  per-victim session channel
/y  heartbeat                     /x  pushStatus
/m  events (operator redirects)   /z  adminStatus (gate / kill switch)

Request bodies are sent Content-Type: text/plain with an X-Enc: 1 header and a base64 payload. The transform looks like encryption and is not — it is an XOR keystream derived from the _fbc cookie the page itself sets, recovered verbatim from the kit:

// 32-byte keystream from the _fbc cookie value
for (let e = 0; e < 32; e++) key[e] = fbc[e % fbc.length] ^ (158 * e + 55 & 255);
// body = base64( XOR(JSON.stringify(payload), key) )   // responses decode identically

Because the _fbc cookie travels in the same session, a defender holding a full capture recovers the plaintext of every credential submission (/e) and every operator command (/m) offline. There is no key exchange and no server-held secret. The obfuscation is theatre; the transport has no secret.

Two properties of this scheme appear to be genuinely undocumented. First, the relay is absent: the dominant PhaaS in this ecosystem — the PHP “Work Panel” / “Doko” family — forwards every capture to an operator Telegram bot, while this kit forwards to its own origin only. Second, the keystream is seeded off _fbc, the Meta Pixel click-identifier cookie. Searching the kit literature, we found no phishing kit keying its obfuscation off _fbc, _fbp, or fbclid — the closest analogues use a page-generated key (Whisper 2FA) or an anti-bot token that is not an exfil channel (ARToken). Keying off _fbc is quietly clever: the value reads as ordinary Meta advertising telemetry, it makes the keystream victim-specific with no static key baked into the bundle, and it softly gates sandboxes that arrive without one. This _fbc-keyed first-party X-Enc channel is the single strongest trackable discriminator for this kit.

Persistence: a rogue authenticator on a virtual machine

Capturing a live session is transient — it dies when the token expires. So the step that follows credential capture, and the last one this post covers, is the operator using the fresh session to enroll their own MFA authenticator, which grants access independent of the victim’s device and survives a password reset.

In the activation we observed, that enrollment came from a Windows QEMU virtual machine. The Okta Verify enrollment carried a user-agent naming the hypervisor outright:

OktaVerify/6.12.2.0 WPFDeviceSDK/6.12.2.0 Windows/10.0.19045.6466 QEMU/Standard_PC_i440FX_+_PIIX_1996

and the enrolled device object carried the tells of a throwaway guest rather than a managed endpoint: no SMBIOS serial number (serialNumber = Unknown), no TPM (tpmPresent = false), and unmanaged (managed = false). The factor they bound on that guest was Okta Verify with FastPass — the device-bound, phishing-resistant one. The irony is exact: FastPass enforced on the victim’s account would have refused the relay at the front door, since it is one of the origin-bound factors the kit cannot replay; but having gotten in on a relayed OTP, the operator enrolls that same factor for themselves, turning the strongest control into their own durable, legitimate-looking access. The relay and the enrollment both originated from a hosting ASN flagged for remote-desktop use (AS399629, BL Networks) — not from the target’s network or the victim’s device. A defender who baselines where their users actually authenticate from has, in that ASN mismatch, a reputation-independent signal that does not depend on the domain, the kit, or any prior knowledge of the campaign.

That is where the attack chain is picked up here. What an operator does after binding an independent authenticator is the subject of other reporting on this ecosystem and is out of scope for a kit teardown.

Indicators

Victim-named domains are deliberately omitted (see the opening). The durable, attacker-side fingerprints — the parts that survive domain rotation — are:

# Kit fingerprints (from the reversed build)
Turnstile sitekey     0x4AAAAAAD_QLVtvi0dxDbRU
Gate disguise         Google reCAPTCHA clone with a Turnstile mount at opacity:.01, zIndex:10
Headless bounce       navigator.webdriver / empty navigator.languages -> https://www.okta.com
Route map             /w /d /y /m /e /u/<id> /x /z   (single-letter, Next.js SPA)
C2 transport          POST text/plain, header "X-Enc: 1", base64 body
C2 keystream          key[i] = _fbc[i % len] ^ (158*i + 55 & 255)

# Infrastructure conjunction (per Flare; verified against our sample)
Registrar             Dynadot
Front / NS            Cloudflare
Certificate           Google Trust Services (WE1), issued same-day as registration
Mail                  no MX record on any campaign domain
Naming                <brand>.claims / <brand>-claims.com / claims-<brand>.com / us-<brand>.com

Detection

Because the domains rotate and the activation window is short, detection is layered across three stages — cert issuance, page visit, and authentication — so evading one still trips another. Each stage is earlier and cheaper than the last.

Three of these are worth their weight independently of everything else in this post. Non-Okta host serving oktaverify.svg has effectively no legitimate baseline — a host that is not Okta has no reason to serve Okta’s authenticator icon — so it is close to a zero-false-positive, inline-blockable signature, and it survives every domain rotation because the kit self-hosts the asset. The AiTM relay tunnel rule is reputation-independent: it keys on where the authentication comes from — a remote-desktop, proxy, or Tor tunnel — rather than on any domain or ASN reputation list, so it fires mid-relay with no prior knowledge of the campaign. It is stronger still when scored against each user’s own history of authentication networks, but a flat tunnel-type match is the portable floor. And the hypervisor MFA enrollment rule catches the persistence step directly — a real user does not enroll Okta Verify from a serial-less, TPM-less QEMU guest.

Two of the pre-registration signals come straight from Flare’s analysis and hold up against our sample: the same-day GTS certificate on a Dynadot domain with no MX record, and a new certificate covering an authentication or legal subdomain beneath a known campaign apex. Certificate Transparency is the place to watch both.

One consequence of the short-lived activation described earlier: a cluster domain bearing your organization’s name is a reason to hunt, not only to block. Because an already-used domain reverts to a dormant hostname, finding one idle tells you nothing about whether it was used. Pull IdP logs around the domain’s certificate-issuance date and look for the two at-auth signatures above — a session arriving through a relay tunnel, an MFA device enrolled from a hypervisor — rather than treating an idle apex as proof nothing happened.

Attribution

The campaign is attributed to the ShinyHunters / “The Com” ecosystem in public reporting — ReliaQuest’s 2026-08-17 advisory and Flare’s 2026-09-10 enumeration. We inherit that attribution and treat it as descriptive: the infrastructure is coordinated and adversarial and matches the published company.claims shape exactly, but no public content had been served to compare against known tradecraft — until this kit. The broader public record has filled in around it since — Health-ISAC’s healthcare alert, coverage of the ReliaQuest targeting (BleepingComputer, The Register), the McKesson disclosure, and MirageSec’s behavioral playbook — but the fullest of those, MirageSec’s, describes the relay behavior without the reCAPTCHA-skinned gate or the _fbc-keyed exfil. Those two remain, to our knowledge, undocumented outside this teardown.

The kit places within a documented family, at the architecture level. Its entry component is LoginHandler and its brand rendering is server-driven (panelType, brand.id, brand.successRedirect) — the same skeleton Bridewell documents for the shared “Com ecosystem” Next.js kit, which self-identifies internally as an “Okta Dashboard” across every brand it wears. We treat that as a family match, not an identity: the distinctive asset conventions Bridewell fingerprints (/brands/<tenant-id>/ favicon and logo paths, decoy forms, zero-width-character stuffing) do not appear in the chunks we captured. That is consistent with their living in the operator-facing panel module, which loads only after the gate and a valid session and which we did not capture — so it is unconfirmed, not contradicted.

The nearest documented sibling is PoisonSeed (NVISO): a per-brand SPA with first-party AiTM exfil and no Telegram, a faux Cloudflare Turnstile, and encrypted-token-in-cookie server-side validation — which NVISO links to the Scattered Spider / CryptoChameleon corner of The Com. It is a design-family sibling, not our build: PoisonSeed uses descriptive routes (/verify, /api/check-email), a static fake Turnstile rather than a hidden live one, and no _fbc key. Together with the Datadog AWS-console kit and 1Phish, it establishes a documented “Com first-party-exfil SPA” lineage; our kit reads as the most evasion-hardened member of it.

Distinct from that lineage is the other branch of this ecosystem’s tooling — the PHP “Work Panel” / “Doko” kit behind the parallel CORDIAL SPIDER / UNC6671 vishing-AiTM activity, which uses api_FyekIDWY.php, relays to Telegram, and registers through NiceNIC. Our kit is none of those. Same ecosystem, different tooling branch.

To our knowledge this is the first public reversal of this kit’s code; Flare noted its 61 enumerated domains never served content, so there was no code fingerprint to compare against. What would move attribution from descriptive to established: recovering the operator-panel module — the lazy-loaded chunk holding the full MFA page-flow, which we did not capture — to test the Bridewell asset conventions directly, and infrastructure pivots linking a specific deployment to a named operator account rather than to the campaign shape.