From a Fake IT Ticket to Scattered Spider: Inside a Com-Affiliated Vishing Campaign

An employee received a vishing call using a fabricated "IT ticket" pretext and was directed to a phishing site impersonating Okta. Security controls blocked the page before any credentials were entered. Detailed analysis of the domain uncovered a favicon, redirect behaviour, and a DOM that led us to over 100 related domains spanning four distinct naming conventions, tied to a phishing kit likely shared across multiple "Com"-affiliated criminal groups. The strongest, most consistent evidence points to Scattered Spider (UNC3944), or a closely affiliated actor using Scattered Spider-consistent infrastructure and tradecraft.

This post summarises findings from a full technical investigation. We'll be publishing a follow-up analyst blog covering our detailed methodology covering threat-actor comparison tables, pivot rule construction, and sector/timeline analysis.

A Call From 'IT'

An employee received an unsolicited call to their personal cell phone from a number displaying a New York-area caller ID, later confirmed to be a legitimate, in-service Verizon landline, almost certainly spoofed rather than attacker-owned.

The caller claimed there was an internal support ticket that needed to be reviewed and closed. When the employee checked the internal ticketing system, no such ticket existed. Instead of treating that as a red flag, the caller pushed forward: the ticket, they said, could only be accessed through an external site. When the employee tried to redirect the call to the official service desk, the caller refused, insisting they'd been specifically routed to this employee directly.

Finally, the caller offered an "alternate way" to access the ticket. When the employee attempted it, the destination site was blocked by existing security controls before any credentials were entered.

What Was Behind the Block

We never fully resolved the malicious page itself. Our own controls blocked it before it could load, and our subsequent attempts to analyse the domain directly were met with anti-sandbox logic. What we could confirm directly from the incident domain was narrower, but still useful: an Okta-branded favicon, and a redirect to google.com whenever the site was accessed by anything that looked automated or non-human.

Additional subsequent information arose from pivoting on this known behaviour - taking those two traits and using them to find and examine other domains built on the same underlying infrastructure, which we could observe in more detail.

Analysis and pivoting uncovered a larger cluster of infrastructure allowing for deeper analysis of the underlying kit. On related domains sharing the same fingerprints, we found:

• A fake Okta and Microsoft login portal, gated behind a convincing but fraudulent Cloudflare CAPTCHA; a real, attacker-owned Cloudflare Turnstile widget wrapped in custom HTML built to visually mimic Cloudflare's own challenge page.

Figure 1. Fake Okta CAPTCHA on credential harvesting page

• A templated, multi-tenant phishing kit. A client-side JSON config dynamically re-brands the page per target organisation — logo, colours, and app name all swap based on which company is being impersonated, while the underlying panel internally refers to itself as an "Okta Dashboard" regardless of which identity provider it's spoofing. We confirmed the same kit also impersonates Microsoft Entra ID on other domains. We can't say for certain whether this is a commercial Phishing-as-a-Service product being sold or rented, or tooling that's simply being shared or reused informally across affiliated operators. However, the templating itself and its reuse across naming conventions tied to different documented threat actors is well evidenced.
  
• The same google.com anti-analysis redirect we'd already seen on our own incident domain, confirmed again on unrelated domains. This is evidence this is a deliberate, built-in evasion feature of the kit itself, not a one-off configuration.

Figure 2. malicious domain with google.com redirect·        The DOM is padded with decoy login forms — hidden, non-functional, deliberately noisy — likely intended to confuse automated phishing-detection tooling that scrapes pages for credential-harvesting form patterns.

None of these individual characteristics were new to us on their own, but the specific combination — favicon, redirect behaviour, CSS naming, decoy forms, and Next.js build architecture — gave us a fingerprint precise enough to hunt with and uncover a larger cluster of domains matching patterns across historical activity linked to multiple COM-affiliated groups.

Analysis Reveals Additional Infrastructure

Using that fingerprint, we ran additional pivots across public datasets. Together, we surfaced over 100 domains tied to the similar activity and the same kit - a much larger footprint than the single incident we started with.

What stood out wasn't just the volume. It was the pattern. The domains split cleanly into four distinct naming conventions, running concurrently on what appears to be shared infrastructure:

Figure 3. table highlighting different domain naming conventions and best threat actor matches

This is strong evidence that the underlying kit isn't exclusive to one operator. Instead it shows it's being run in parallel by multiple financially motivated groups loosely affiliated under the "Com" cyber criminal ecosystem, each stamping it with their own naming habits.

The passkey* cluster is worth calling out specifically. It isn't just a loosely similar naming style: it's a close match to domains previously and independently attributed to Pink (CL-CRI-1147), a separate active extortion group, in prior public reporting (assignpasskey.com, passkeyadd.com, passkeydeploy.com). That's the clearest single piece of evidence in this entire investigation that the kit isn't exclusive to one group: a second, independently documented actor's own naming convention shows up running on what looks like the same underlying infrastructure as the domain that targeted our customer.

Our incident's own domain sat squarely in the largest, most recent and actively growing of these clusters.

Who is responsible?

We evaluated four candidate groups against the full body of evidence: BlackFile (UNC6671), now retired but relevant for lineage; Pink (CL-CRI-1147), an active BlackFile successor; Helix, another active, adjacent cluster; and Scattered Spider (UNC3944), the long-running, well-documented Com-affiliated actor.

Two independent lines of evidence converged on the same answer:

Infrastructure

The incident domain's registrar (NameSilo), naming convention, and Cloudflare-fronted hosting all align with Scattered Spider's documented patterns. Critically, it uses the combination of registrars (NameSilo, Dynadot, NICENIC) seen across the wider pivoted domain set, all of which independently appear in reporting on Scattered Spider and its documented collaboration with ShinyHunters.

Targeting pattern

The sector spread across the pivoted domains with a particular focus in finance, technology, and retail, all of which closely matches Scattered Spider's own documented targeting profile (roughly 70% concentrated in those three sectors). Registration dates cluster most heavily in the two weeks immediately preceding this incident, meaning we caught this campaign mid-acceleration, not at its tail end.

Figure 4. Pie chart demonstrating the targeting distribution linked to the activity

Across every technical and behavioural comparison, we ran, Scattered Spider was the only candidate with zero direct contradictions. Pink and BlackFile's lineage both show up clearly, but in their own naming conventions and pretexts - not this one.

Our assessment: this incident is most likely attributable to Scattered Spider (UNC3944), or a Com-affiliated actor operating shared or rented phishing-kit infrastructure with Scattered Spider–consistent domain naming, registrar selection, and targeting pattern.

That last caveat matters. Given the demonstrated evidence of one kit running under four naming conventions simultaneously, this is best understood as infrastructure and tradecraft attribution — not a courtroom-grade claim that one specific group's operators made this specific call.

What Scattered Spider Typically Does Next

We did not observe any successful compromise in this incident — access was blocked before any credential was entered. But based on Scattered Spider's well-documented playbook, organizations facing similar activity should watch for:

·        Rapid registration of a new MFA method on any compromised account, often within minutes of a successful login

·        Use of legitimate remote-access tools (TeamViewer, AnyDesk, ScreenConnect) rather than custom malware, to blend into normal IT activity

·        Enumeration and lateral movement inside Microsoft 365/Azure or Okta-federated environments

·        In more advanced intrusions, direct targeting of virtualization infrastructure (VMware vCenter/ESXi) as a precursor to fast, targeted ransomware deployment

·        Data staged from cloud storage and collaboration platforms (SharePoint, OneDrive, Teams) ahead of an extortion demand, sometimes delivered through the victim's own compromised communication channels

Recommendations

·        Verify the targeted account. Even where access was blocked, review sign-in logs, MFA/device registration events, and active session tokens for the relevant window to rule out partial capture.

·        Hunt for the kit fingerprint across your own environment. The favicon hash, redirect behaviour, and DOM signature described above can be applied against email security and web proxy logs to check for delivery to other employees.

·        Block and monitor the full indicator list (below) at the email gateway, DNS resolver, and web proxy — not just the domain involved in this specific incident.

·        Scrutinize personal-device contact. This attack specifically avoided the corporate phone system. Consider whether "IT support" calls to personal devices should trigger mandatory callback verification through a known internal number.

·        Treat a missing ticket as an escalation trigger, not a workaround prompt. The pretext here relied on the employee not treating "the ticket doesn't exist" as suspicious enough to end the call.

·        Watch for lookalike domains against your own brand. Given the naming conventions identified here (helpdesk-, sso-, tickets-<yourcompany>), a standing detection rule for new registrations matching this pattern is a low-cost, high-value addition.

Indicators of Compromise

Full List of Targeted Organisationshelpdesk- / sso- / tickets- Convention

it.<company>.support / .help Convention

passkey* Convention

Legacy <brand>-okta.com Typosquat Convention