Vishing Call to a Shared Com Ecosystem: Full Methodology and Findings banner image
Blog
BCON COLLECTIVE

Vishing Call to a Shared Com Ecosystem: Full Methodology and Findings

By Joshua Penny 30 July 2026 66 min read
This is a companion to our earlier post, "From a Fake IT Ticket to Scattered Spider: Inside a Com-Affiliated Vishing Campaign." This post is written for fellow analysts and covers the full investigative methodology: our indicator ratings, pivot construction, threat-actor comparison tables, victimology, and possible attribution.


1. Incident Summary & Attribution Assessment

An employee at one of Bridewell’s customers received an unsolicited call to their personal cell phone, the agent on the other end used a fabricated "IT ticket" pretext to direct them toward what we assess to have been a fraudulent Okta login page. Security controls blocked the destination before any credentials were entered.

During our analysis, the domain’s anti-sandbox logic redirected automated tooling to google.com. What we could confirm directly on the incident domain was: an Okta-branded favicon and the redirect behaviour. Everything else in this report was built by pivoting on those two characteristics.

Our investigation surfaced a phishing kit and 100+ operational domains clustered within four distinct naming conventions, and at least two independently documented threat clusters. We were able to identify and analyse live samples to understand build configurations and behaviour which we could only infer from the original incident. Subsequent research also tied three organisations in our target list to confirmed ShinyHunters data-leak-site extortion listings, with as few as 4 days elapsing between a targeted organisation’s impersonation domain’s most recent WHOIS activity and the organisation's public listing on the extortion site. It is assessed with moderate confidence that these domains were likely used as the initial access vectors by ShinyHunters however, we cannot confirm this.

1.1 Attribution assessment

This incident is most likely attributable to Shiny Hunters or a Com-affiliated actor operating a shared phishing-kit infrastructure consistent with SLH's documented tradecraft. This should be read as infrastructure/tradecraft attribution, not a definitive single-actor claim. The same kit was found running concurrently under naming conventions independently tied to at least two other documented clusters (Pink/CL-CRI-1147, and the retired BlackFile/UNC6671 lineage), and a confirmed victim (Abbott) attributes its own compromise directly to ShinyHunters via vishing and an Entra SSO compromise, a vector closely matching this kit's confirmed capabilities, and consistent with SLH's self-described division of labour (Scattered Spider providing initial access, ShinyHunters handling exfiltration and extortion).

Note: we are tracking this intrusion under the threat cluster name BR-UNC-036.


2. Key Incident Observations

The following observations are split by source: what was directly observed during the incident itself (human interaction, infrastructure, kit behaviour), versus what was established only via pivoting.

2.2. Incident Details – A Call From ‘IT’

An employee received an unsolicited vishing call to his personal cell phone, from a caller ID displaying a New York-area number for an in-service Verizon landline. The caller claimed there was an internal incident ticket requiring review and closure. When the employee checked the internal ticketing system, no matching ticket could be found. The caller then redirected him to an external site to access the ticket. When the employee attempted to redirect the caller to the official Service Desk, the caller refused, insisting they had been specifically routed to the employee directly, and offered an "alternate way" to access the same ticket. On attempting this alternate access, the destination was blocked by existing security controls before any credential entry could occur. The employee informed the caller he would gather more information before proceeding; the caller disconnected and made no further contact. No credentials, MFA approvals, or session tokens are known to have been entered or captured.

Below are the attributes that are comparable against documented threat-actor tradecraft and feed the Section 3.1 mapping: 

ID Observation
INC-01 Target contacted on his personal cell phone
INC-02 Caller used a general IT/helpdesk impersonation pretext to establish legitimacy
INC-03 Pretext was specifically framed as an internal ticket requiring closure
INC-04 Caller redirected the target to an external site to resolve the pretext
INC-05 Caller offered an "alternate way" to access the same resource when the primary path failed

Figure 1. Table of Incidents Details

2.2 Known Infrastructure

The following are characteristics observed directly on the incident domain (tickets-[companyname].com): registration, hosting, and certificate data pulled from WHOIS, DNS, and TLS records.

ID Observation
INF-01 Domain observed: tickets-[companyname].com
INF-02 Domain registered via NameSilo
INF-03 Domain uses Cloudflare-delegated nameservers; all resolving IPs are Cloudflare addresses
INF-04 TLS certificate issued by a Google-affiliated CA (Google Trust Services)

Figure 2. Table of domain details

Figure 3. STIX graph relating to incident details[
Figure 3. STIX graph relating to incident details

2.3 Kit Behaviour Analysis

The following describes the kit's client-side behaviour and architecture. Each is tagged by source: direct observations were made on the incident domain itself before it redirected; pivot-derived observations were made on related domains discovered by using the direct observations as a fingerprint and are treated as high-confidence for the kit family as a whole but inferential, not independently confirmed, for the incident domain specifically.

Figure 4. Example of Okta login page

Figure 4. Example of Okta login page

ID Source Observation
KIT-01DirectPage presented an Okta-branded favicon, loaded successfully despite the subsequent anti-sandbox redirect.
KIT-02DirectAnti-analysis JavaScript redirected non-human/sandboxed traffic to google.com before the login/dashboard interface loaded.
KIT-03Pivot-derivedInternal kit config self-identifies as "appName":"Okta Dashboard" regardless of impersonated brand. The kit is a multi-identity-provider, brand-agnostic panel rather than Okta-exclusive.
KIT-04Pivot-derivedConsistent asset path convention: /brands/{tenant-id}/favicon.*, /brands/{tenant-id}/logo.png.
KIT-05Pivot-derivedCSS block explicitly named okta-panel-mobile-styles.
KIT-06Pivot-derivedHidden decoy <form> elements present (randomised hex-suffix IDs, tabindex="-1", autocomplete="off").
KIT-07Pivot-derivedKit built on Next.js, with consistent LoginHandler component naming and asset convention across tenants.

Figure 5. Table of kit attributes identified either directly through incident of via pivoting

2.4 Pivoting

KIT-01 and KIT-02 were behaviour observations used to generate fingerprints as they were observed directly from incident for pivoting to related domains, since the incident domain itself redirected before its own DOM could be fully retrieved. Three pivot methods were applied in total, each a method that expanded the known domain set building from KIT-01, KIT-02 and the SSL Jarm fingerprint for INF-04. This subsection defines the methodology and what each surfaced; Section 4.1 rates the resulting naming-convention evidence against each candidate threat actor.

2.4.1 PIV-01: Favicon Hash + Anti-Sandbox Redirect Behaviour

Combines KIT-01 (Okta-branded favicon) with KIT-02 (anti-analysis redirect-to-google.com behaviour). One matching-tenant domain identified by this method impersonates Microsoft/Entra ID rather than Okta, confirming the kit is a multi-identity-provider panel rather than Okta-exclusive.

2.4.2 PIV-02: HTML/DOM Kit Architecture Fingerprint

Applying PIV-01 to related domains surfaced their full DOM and configuration. KIT-03 through KIT-07 were observed and, combining those attributes lead to PIV-02.

2.4.3 PIV-03: Favicon Hash + SSL JARM Fingerprint

In addition to PIV-01 we also combined the favicon hash with an SSL/TLS JARM fingerprint without requiring the redirect behaviour, surfacing kit deployments where redirect logic was disabled, varied, or unobserved. 34 of ~44 PIV-01/PIV-02 domains were recovered by this method, plus a substantially larger new set spanning four distinct naming conventions: the incident's own helpdesk-/sso-/tickets- convention, an it.<company>.support convention, a passkey* convention, and a separate, notably older Okta-typo squat convention.

Figure 6. STIX graph showing domains mapped against pivot indicator objects to show overlap

Figure 6. STIX graph showing domains mapped against pivot indicator objects to show overlap


3. Threat Actor Mapping

This section attempts to map incident observations from Section 2 against the documented TTPs of four candidates threat clusters: BlackFile (UNC6671) — retired brand as of April/May 2026, included for lineage only; Pink (CL-CRI-1147) — active, assessed UNC6671 successor; Helix — active, assessed adjacent/successor cluster; and Scattered LAPSUS$ Hunters (SLH).

We used a four-value scale to match each element against the above threat actors:

  • MATCH (directly documented, aligns with the incident),
  • PARTIAL (directly documented, differs on specifics),
  • NO MATCH (directly documented, contradicts the incident),
  • NOT DOCUMENTED (no public reporting either way).

3.1 Vishing/Human Interaction

The following observations are drawn directly from the target's account of the phone call and his subsequent actions (Section 2.1), cross-referenced against each candidate's documented pretext and targeting behaviour.

ID BlackFile (retired) Pink Helix Scattered LAPSUS$ Hunters (SLH)
INC-01: Personal cell contact MATCH NOT DOCUMENTED NOT DOCUMENTED MATCH
INC-02: General IT/helpdesk impersonation MATCH MATCH MATCH MATCH
INC-03: Ticket-closure specific pretext MATCH NO MATCH
(passkey enrollment)
PARTIAL
(general "IT assistance")
MATCH
INC-04: Redirected to external site MATCH MATCH MATCH MATCH
Figure 7. Table of Incident details mapped to threat groups

SLH matches strongly and consistently across the general vishing/IT-impersonation and Okta-themed-page rows.

3.2 Known Infrastructure

The following are technical characteristics observed directly on the incident domain (tickets-[companyname].com); registration, hosting, and certificate data pulled from WHOIS, DNS, and TLS records is cross-referenced against each groups documented infrastructure.

ID BlackFile (retired) Pink Helix Scattered LAPSUS$ Hunters (SLH)
INF-01: tickets-[company].com naming PARTIAL
(ticket-<co>[.]support)
NO MATCH
(passkey-themed)
NO MATCH
(oskeysync[.]com)
MATCH
(documented keyword set includes "help," "servicedesk," "support," "ticket"-style themes)
INF-02: Registrar NO MATCH
(Tucows)
NO MATCH
(Tucows, NiceNIC)
NO MATCH
(NICENIC)
MATCH
(NameSilo and Dynadot)
INF-03: Cloudflare NS/hosting NOT DOCUMENTED MATCH
(Cloudflare + DDoS-Guard)
NOT DOCUMENTED MATCH

Figure 8. Table of incident infrastructure information mapped against threat actors

SLH is the clearest infrastructure match because collaborative reporting documents the registrar overlap (NameSilo, Dynadot) as joint SS/ShinyHunters infrastructure specifically, not two isolated single-actor observations.

3.3 Kit Behaviour

The following describe the observed client-side behaviour of the incident domain itself (Section 2.3), cross-referenced against each candidate's documented phishing kit capabilities and targeting.

ID BlackFile (retired) Pink Helix Scattered LAPSUS$ Hunters (SLH)
KIT-01: Okta impersonation MATCH MATCH
(dedicated Okta-tailored kit variant)
NO MATCH
(absence of evidence)
MATCH
KIT-02: Sandbox redirect to google.com PARTIAL NOT DOCUMENTED NOT DOCUMENTED PARTIAL
(documented redirect logic for the Scattered Spider component; not google.com specifically)
KIT-03: Multi-IdP capability (Microsoft/Entra ID impersonation, confirmed alongside Okta) MATCH MATCH MATCH MATCH
Figure 9. Table of Kit attributes mapped against threat actors
Across 3.1-3.3, general social-engineering tradecraft does not reliably separate the candidates, while specific detail does — and it does so consistently across all three categories of direct incident evidence. On the human-interaction side (3.1), the vishing call itself, personal cell contact, IT/helpdesk framing, the specific ticket-closure pretext, and the redirect to an external "alternate way", now matches SLH on every single row, no other candidate achieves this.

On infrastructure (3.2), incident domain details: NameSilo registration, Cloudflare-fronted hosting again points to SLH specifically, while directly contradicting both BlackFile's and Helix's own documented registrars. Pink shares the Cloudflare hosting pattern but not the registrar.

On kit behaviour (3.3), the Okta-branded favicon and its later-confirmed extension to Microsoft/Entra ID impersonation is shared across BlackFile, Pink, Helix and SLH on the Okta-specific evidence.

Put together, SLH is the most consistently and completely documented match across every subsection, with zero direct contradictions in this section. Pink is the clearest secondary candidate, credible on kit behaviour grounds specifically but diverging from this incident on registrar and pretext specifics. Helix is the weakest active candidate throughout, with no confirmed Okta association and infrastructure that actively contradicts the incident, though the KIT-03 finding gives it a genuine foothold. BlackFile is excluded as a standalone attribution candidate given its retirement, with its matches read as establishing tradecraft lineage rather than live candidacy for this specific incident.


4. Domain & Victimology Analysis

This section characterises the full dataset of domains recovered across PIV-01, PIV-02, and PIV-03 (Section 2.4) covering sector targeting, registration timeline, and hosting/registrar distribution. Like other sections, these are cross-referenced with characteristics documented against threat actor profiles.

4.1. Domain Convention × Pivot ID Mapping, with Threat Actor Alignment

Convention PIV-01 PIV-02 PIV-03
helpdesk-/sso-/tickets- 42038
it.<company>.support (+.help) 20538
passkey* 0013
Okta-typosquat (older, Nov 2025-Feb 2026) 0015

Figure 10. Table of domain naming conventions mapped against pivot rules

ID BlackFile Pink Helix SLH
CONV-01: helpdesk-/sso-/tickets- naming NO MATCH NO MATCH NO MATCH MATCH
CONV-02: .support/.help naming MATCH NO MATCH NO MATCH NO MATCH
CONV-03: passkey* naming NO MATCH MATCH MATCH
(Thematic match with no direct use of passkey*)
NO MATCH
CONV-04: Okta-typosquat naming (older cluster) NO MATCH NO MATCH NO MATCH MATCH
Figure 11. Domain of naming conventions mapped against threat actors

The four conventions split cleanly by which pivot methods recovered them, not just by the associated actor. helpdesk-/sso-/tickets- (SLH's current convention) and .support (the BlackFile lineage) are both recovered by all three pivots (PIV-01 and PIV-02). passkey* (Pink) and the older Okta-typosquat cluster are clustered only by PIV-03, the broadest pivo.

SLH’s current helpdesk-/sso-/tickets- wave is tightly fingerprinted, but the older Okta-typosquat cluster (Nov 2025–Feb 2026, also rated MATCH for SLH under CONV-04) is only loosely fingerprinted, the same as Pink's passkey* domains. The suggests that the tightly-fingerprinted pair (SLH-current and BlackFile) are likely running the same current kit build based on the same favicon, same redirect logic, same DOM/config signature as the incident domain itself while the loosely-fingerprinted pair (Pink and SLH's own older wave) may be running an earlier or variant build that shares underlying hosting/TLS characteristics with the current kit but not its surface-level fingerprint. Whatever that variant is, it isn't actor-specific, since it spans both Pink and SLH's own historical domains.

The incident's own domain (tickets-[companyname].com) falls in the helpdesk-/sso-/tickets- convention. This cluster is the most consistently and directly tied to SLH's documented naming pattern across all three pivots. Combined with the fingerprint-tightness pattern above, the incident domain sits within the cluster most likely to be running the current, fingerprinted kit build, not the earlier variant.

Figure 12. STIX graph mapping domain naming into clusters and pivot indicator objects

Figure 12. STIX graph mapping domain naming into clusters and pivot indicator objects

4.2. Sector/Victimology Analysis

Sector was inferred from target brand for all uniquely identified domains across PIV-01 – PIV-03.

Alignment to documented actor targeting:

  • The broad, cross-sector spread (finance, retail, tech, and healthcare all well-represented) matches documented reporting that 70% of Scattered Spider's targets concentrate in technology, finance, and retail trade sectors. This dataset's overall shape fits that profile closely, especially once the .support and passkey* sub-clusters are set aside.
  • The heavy healthcare/insurance concentration specifically within the .support and passkey* conventions align with Pink's documented focus on healthcare, technology, and financial services.
  • The Okta-typosquat cluster's tech-vendor concentration is consistent with Scattered Spider's earlier-stage, IT/SaaS-vendor-focused campaigns and its older registration window supports this being an earlier phase of the same actor's activity rather than a separate operator.
Sector Approx. Domain Count Dominant Convention(s) Notable Targets
Healthcare/Pharma/MedTech ~24 .support, helpdesk- Regeneron, Tenet, Labcorp, Guardant Health, Express Scripts, Insulet, Intuitive Surgical, Abbott
Finance/Insurance/Fintech ~20 helpdesk-, sso-, .support, passkey* BlackRock, KKR, Vanguard, Chime, Affirm, Pacific Life, Guardian Life, Palomar
Technology/SaaS ~15 Okta-typosquat, helpdesk- Databricks, Asana, SmartBear, Dialpad, Intercom, 1Password, ServiceNow, RingCentral
Retail/Consumer/Hospitality ~12 helpdesk-, tickets- Uber, Nike, Ralph Lauren, Nordstrom, Soho House, Choice Hotels
Gaming/Casino ~5 .support Caesars, Station Casinos, Light & Wonder, bet365
Aviation ~4 .support, helpdesk- JetBlue, Sun Country, Air Methods
Energy/Industrial ~4 .support, passkey* PSEG, Energy Transfer, DNOW
Legal/Professional Services 1 passkey* Dechert LLP
Figure 13. Table of domain naming conventions against perceived sector and organisation targets

Alignment to documented actor targeting:

  • The broad, cross-sector spread (finance, retail, tech, and healthcare all well-represented) matches documented reporting that 70% of Scattered Spider's targets concentrate in technology, finance, and retail trade sectors. This dataset's overall shape fits that profile closely, especially once the .support and passkey* sub-clusters are set aside.
  • The heavy healthcare/insurance concentration specifically within the .support and passkey* conventions align with Pink's documented focus on healthcare, technology, and financial services.
  • The Okta-typosquat cluster's tech-vendor concentration is consistent with Scattered Spider's earlier-stage, IT/SaaS-vendor-focused campaigns and its older registration window supports this being an earlier phase of the same actor's activity rather than a separate operator.

4.3 Domain Creation Timeline

Convention Earliest Observed Latest Observed Pattern
Okta-typosquat 2025-11-19 2026-03-13 Earliest, most spread out; consistent with a longer-running, lower-tempo operation.
passkey* 2026-04-21 2026-07-10 Begins shortly after the Okta-typosquat cluster tapers off.
.support 2026-04-03 2026-07-12 Sustained, steady registration throughout the campaign window.
helpdesk-/sso-/tickets- 2026-04-29 2026-07-16 Heaviest concentration in the final two weeks (late June-mid July), coinciding with the incident date and continuing into the live case study sample.
Figure 14. Table of domain naming clusters mapped to creation and observation times

All four conventions overlap in April–May 2026, but the helpdesk-/sso-/tickets- convention shows a clear late-campaign acceleration. Of the domains in this cluster, a large portion were registered in the final two weeks before our incident. This places the incident squarely inside an active, escalating wave of this specific naming convention, rather than at the tail end of a campaign.

4.4 Hosting Distribution

Resolved hosting/ASN data across the combined PIV-01–03 domain set.

Hosting Share Actor Alignment

Cloudflare (majority)

Dominant across all conventions

Documented for both Pink and Scattered Spider

DDoS-Guard (AS57724/AS49612)

Minority, concentrated in Pink-documented infrastructure

Documented specifically for Pink

Figure 15. Table of hosting distribution

4.5 Registrar Distribution

Registrar data is analysed per naming convention below, rather than as a single pooled figure.

4.5.1 helpdesk-/sso-/tickets- convention

Registrar Count Share
Dynadot Inc / DYNADOT LLC 10 50%
NICENIC INTERNATIONAL GROUP CO., LIMITED 7 35%
NameSilo, LLC 3 15%

Figure 16. Table of WHOIS registrar distribution by domain naming pattern

4.5.2 support/.help convention

Registrar Count Share
Dynadot Inc / DYNADOT LLC 13 44.8%
NameSilo, LLC 11 37.9%
NICENIC INTERNATIONAL GROUP CO., LIMITED 4 13.8%
CentralNic 1 3.4%
Figure 17. Table of WHOIS registrar distribution by domain naming pattern

This is a near match to the helpdesk-/sso-/tickets- convention's registrar mix, with similar proportions across the same three registrars. BlackFile is historically documented using only Tucows and none of these 29 .support domains use it. Either this convention isn't run by the same operators who registered BlackFile's own confirmed domains, or those operators have since moved onto SLH's registrar pool either of which points toward the .support convention being closer to SLH-adjacent infrastructure than a continuation of BlackFile's own original operation.

4.5.3 passkey* convention 

Registrar Count Share
NICENIC INTERNATIONAL GROUP CO., LIMITED 6 75%
Tucows 1 12.5%
Unresolved 1 12.5%

Figure 18. Table of WHOIS registrar distribution by domain naming pattern

Of the domains with resolved data, all fall under one of Pink's two independently documented registrars (INF-02).

ID BlackFile Pink Helix SLH
REG-01: Registrar distribution, per candidate's own naming convention NO MATCH MATCH PARTIAL MATCH

Figure 19. Table of Registrar distribution against threat actors

SLH and Pink both show direct, convention-specific registrar matches to their own independently documented patterns. BlackFile shows a direct contradiction, not an absence of data, since its own registrars actively exclude Tucows in favour of the same pool SLH uses.

Helix is a partial match on this row simply because it has no multi-domain naming convention in this dataset to test against; this reflects Helix's narrower footprint in the pivoted data generally; note Helix's registrar overlap noted elsewhere in this report rests on Helix's own single documented domain, not on convention-level data, and is weaker evidence for that reason.

The most notable finding overall is the near-identical Dynadot/NameSilo/NICENIC registrar pool shared between the SLH and BlackFile-lineage conventions specifically, despite those conventions otherwise pointing at different naming patterns and different actors. 

4.6 Summary

Across sector, timeline, hosting, and registrar analysis, the incident's own domain sits within the largest, most recently active, and most consistently SLH-aligned cluster in the dataset (helpdesk-/sso-/tickets-), registered during a period of accelerating campaign activity in that specific convention.

The broader dataset, spanning across four distinct clusters supports the Section 3 conclusion that this is shared kit infrastructure used across multiple Com-affiliated actors, rather than a single group's exclusive campaign. Victimology reinforces rather than overturns that conclusion: the overall sector spread matches SLH's documented broad targeting profile, while the two sub-clusters most clearly tied to other actors show narrower, more sector-concentrated targeting consistent with their own separately documented focus areas.

4.7 Unified Cross-Table Summary

This combines the 10 rated rows from Section 3.1–3.3 (INC-01 through KIT-03) with the 5 rated rows added in this section (CONV-01–04, REG-01) for a full 15-row tally.

Candidate MATCH PARTIAL NO MATCH NOT DOCUMENTED Total Rows
BlackFile (UNC6671) — retired, lineage only 725116
Pink (CL-CRI-1147) 706216
Helix 425416
Scattered LAPSUS$ Hunters (SLH) 1212016

Figure 20. Table of threat actor mapping scoring totals

Most likely attribution for our incident: Scattered LAPSUS$ Hunters (SLH) remains decisively the best-supported candidate across the full 16-row evidence base: 12 MATCH, 1 PARTIAL, 2 NO MATCH, and 0 NOT DOCUMENTED. The two NO MATCH rows are worth being explicit about, since SLH is not a spotless zero-contradiction candidate: CONV-02 and CONV-03 are the .support and passkey* naming conventions independently and specifically tied to BlackFile and Pink respectively.

KIT-03 (multi-IdP capability) remains the most self-correcting row in this table: it gives Helix its first unambiguous MATCH, on grounds that Helix's documented M365/Entra-only scope is consistent with — not absent from — this kit's actual capabilities, even though Helix still shows no Okta-specific association. Pink strengthens to a clear second place once its own naming convention (CONV-03) and Entra-kit history (KIT-03) are counted in its favour, alongside BlackFile similarly gaining from CONV-02 and its own M365 targeting history. Helix remains the weakest candidate overall, with the most gaps of any candidate by a wide margin but is no longer a near-total blank.

4.7.1 Cross-affiliate Kit Sharing and Scope of Evidence

This attribution should still be presented as tradecraft/infrastructure attribution, not a definitive single-actor claim. Section 4.1 demonstrates that the same underlying phishing kit runs concurrently under naming conventions independently consistent with three different candidates (SLH, BlackFile/UNC6671 lineage, Pink) meaning the kit itself is shared across the broader Com ecosystem, not exclusive even to SLH; SLH's own two NO MATCH rows above are direct evidence of this, not an artifact of the table.


5. Data Leak Site Correlation

Three organisations in the Section 4 target list, Abbott, RingCentral and Ralph Lauren, were confirmed as ShinyHunters extortion victims within days of each other in mid-July 2026 – as demonstrated by the graph below.

 Figure 21. STIX graph showing connection between ShinyHunter victims and domain name registrations

Figure 21. STIX graph showing connection between ShinyHunter victims and domain name registrations

5.1 Abbott - Confirmed Extortion, Strong Vector Corroboration

Field Detail
Domain in dataset helpdesk-abbott[.]com (created 2026-05-08, updated 2026-07-11), tickets-abbott[.]com (created 2026-05-08)
ShinyHunters DLS listing 2026-07-15
Extortion deadline 2026-07-18, extended to 2026-07-21
Reported entry vector Vishing against Abbott employees mid-June 2026, compromising a corporate Microsoft Entra SSO account
Claimed data Internal documents, contracts, customer information, 22M+ doctor-patient notes, 20M+ medical orders

Figure 22. Table of details relating to Abbott domain and Shiny Hunters DLS post

ShinyHunters told BleepingComputer directly that access came via vishing and an Entra SSO compromise. This closely matches the vishing pretext, Entra ID impersonation capability, and fake-SSO architecture we observed. This is also a strong single piece of corroborating evidence in our investigation for ShinyHunters.rmed.

5.2 Ralph Lauren - Confirmed Extortion, Vector Unconfirmed

Field Detail
Domain in dataset helpdesk-ralphlauren[.]com (created 2026-06-05)
ShinyHunters claim date 2026-06-11 (six days after domain registration)
Data published/HIBP 2026-06-18
Reported entry vector Compromise of Ralph Lauren's Salesforce instance
Figure 23. Table of details relating to Ralph Lauren and ShinyHunters DLS post.

Confirmed victim on ShinyHunters DLS and tightly timed domain registration, but the reported vector (Salesforce/OAuth compromise) is not confirmed.

5.3 RingCentral - Confirmed Extortion, Vector Unconfirmed

Field Detail
Domain in dataset helpdesk-ringcentral[.]com (created 2026-06-29)
ShinyHunters DLS listing 2026-07-27
Claimed data Not yet specified in the DLS post at time of writing

Figure 24. Table of details relating to RingCentral and ShinyHunters DLS post.


Event Timeline

Figure 25. Event timeline covering domain registrations and single events relating to domain registrations and ShinyHunters victims

Figure 25. Event timeline covering domain registrations and single events relating to domain registrations and ShinyHunters victims


 

MITRE ATT&CK Mapping

Report ID(s)TacticTechniqueATT&CK IDEvidence TypeRationale
INC-01ReconnaissanceGather Victim Identity InformationT1589DirectPersonal cell number and employee identity known prior to the call.
INF-02, PIV registrar findings (4.5)Resource DevelopmentAcquire Infrastructure: DomainsT1583.001Direct/PivotRegistration across NameSilo, Dynadot, NICENIC and Tucows across the full domain set.
KIT-03–07, 6.9Resource DevelopmentDevelop CapabilitiesT1587Pivot-derivedMulti-tenant kit templating and shared compiled build artefacts.
INC-02, INC-03Initial AccessPhishing (Voice)T1566 (vishing, T1598-adjacent)DirectVishing call using a fabricated IT-ticket pretext.
KIT-01, INC-04, INC-05Initial AccessPhishing: Spearphishing via ServiceT1598.003DirectFake Okta credential portal reached via the vishing workflow.
6.3, 6.5Credential AccessAdversary-in-the-MiddleT1557DirectLive session relay, OTP capture and OAuth authorisation abuse.
6.4, 6.6Credential AccessMFA InterceptionT1111DirectOTP capture confirmed directly; MFA selective-failure behaviour requires further validation.
KIT-02Defense EvasionImpair Defenses DirectAnti-sandbox redirect to google.com observed on the incident domain.
KIT-05, KIT-06, 6.7Defense EvasionObfuscated Files or InformationT1027Pivot-derived / DirectDecoy DOM elements and zero-width Unicode text stuffing.
INF-03, KIT-03 (unconfirmed)Command and ControlWeb ServiceT1102DirectLegitimate Turnstile widget observed; wrapper-page control remains an open discrepancy.
5.1ExfiltrationExfiltration Over Web ServiceT1567AssessedConfirmed for Abbott via a compromised Entra session.
5.1, 5.2ImpactFinancial Theft/ExtortionT1657Direct (victim/DLS listing confirmed)"Pay or Leak" DLS model confirmed for Abbott, RingCentral and Ralph Lauren.


Conclusion

This investigation began with a single blocked vishing call and expanded into a dataset of approximately 100 domains, revealing a broader picture of a shared phishing ecosystem operating across multiple Com-affiliated threat actors.

For the specific incident that initiated this investigation, the strongest evidence supports attribution to ShinyHunters. The incident domain aligns with the helpdesk-/sso-/tickets- convention most closely associated with infrastructure independently linked to ShinyHunters elsewhere in the dataset. Abbott's reported intrusion closely matches capabilities directly confirmed within the phishing kit, while RingCentral's appearance within the same convention and registration wave further strengthens this assessment.

For the wider campaign, the evidence indicates a shared infrastructure model rather than infrastructure operated exclusively by a single actor. The same phishing kit appears across at least three naming conventions independently associated with distinct threat clusters. Shared compiled build artefacts provide the strongest evidence linking the SLH convention, while common DOM structures and configuration architecture extend those links to other domain clusters at lower confidence levels.

Attribution associated with the .support convention remains less certain than historical reporting suggests. Registrar analysis identified infrastructure patterns that differ from historically documented BlackFile infrastructure and instead align more closely with the registrar ecosystem used by SLH-linked domains. This raises the possibility that historic naming conventions are continuing under different operators.

From a defensive perspective, the key finding is that the phishing kit itself appears to be shared across multiple actors. Detection and blocking strategies should therefore focus on the kit's behavioural and technical characteristics rather than assuming every matching domain belongs to a single threat actor.

Across the confirmed victim examples analysed in this report, the gap between relevant domain registration activity and subsequent publication on the ShinyHunters data leak site ranged from four to twenty-eight days, averaging less than two weeks where those domains were assessed as potential initial access infrastructure.

Detection must happen inside that window to matter.


Recommendations

Detection & Monitoring

  • Block and monitor the full IOC list at email gateway, DNS resolver, and web proxy.
  • Treat any organisation appearing in the Section 4 target list as time-sensitive: the observed window between a domain's most recent activity and public DLS listing ranged from 4 to 28 days across the confirmed cases; a slow response risks missing the window entirely.
  • Establish (or confirm the maturity of) a standing domain impersonation monitoring capability. Automated detection of newly registered lookalike/brand-plus-keyword domains targeting your organisation, including a specific watch for helpdesk-/sso-/tickets-<yourorg> naming patterns, rather than relying on ad hoc discovery.
  • Monitor ShinyHunters and Pink DLS listings as a supply-chain signal. Watch for critical vendors and suppliers appearing.

Vishing-Specific Mitigations

  • Restrict what a phone-only caller can achieve at the helpdesk: require a second, independent verification channel (callback to a pre-registered number, video verification, or manager approval) before any MFA reset, device enrolment, or password reset is actioned.
  • Train helpdesk and general staff specifically on this pretext pattern: spoofed internal caller ID, urgency framing, "ticket closure" or "mandatory update" language, rather than relying on generic phishing awareness training alone
  • Treat a missing/non-existent ticket as an automatic escalation trigger, not a prompt to seek an "alternate way" to access it.
  • Move toward phishing-resistant MFA (FIDO2 security keys, or passkeys enrolled only through a verified, pre-authenticated flow).
  • Alert on anomalous MFA enrolment events (a new device or method added shortly after a helpdesk interaction) as a standing automated detection rule, not a manual review item.

 


Indicators of Compromise

https://github.com/Bridewell-CTI/IOCs/blob/main/2026/07/From%20a%20Fake%20IT%20Ticket%20to%20Scattered%20Spider%3A%20Inside%20a%20Com-Affiliated%20Vishing%20Campaign

References

Turn threat intelligence into action.
Contact our CTI team to discuss threat monitoring, investigations and intelligence-led security improvements.
Joshua-Penny (2)

Joshua Penny

Senior Threat Intelligence Analyst

Joshua Penny is a Senior Threat Intelligence Analyst with 5 years’ experience working within C...
About the Author