Finding and Notifying a ShinyHunters Claims Impersonation Campaign Before It Activated: 61 Domains, 48 Brands

By Adrian Cheek, Senior Cybercrime Researcher

ReliaQuest Threat Research published a short public advisory about a ShinyHunters campaign on August 17, 2026. This campaign was built on domains following a company[.]claims pattern, and reported that the group had added legal team impersonation to its established help desk and IT pretexts. The advisory had no domains, and described a shape that left the reader to find the instances.

Over the following three weeks we enumerated that shape. The result: 61 domains impersonating 48 organizations, all registered through one registrar, none of them ever used. We notified every organization in the set through H-ISAC, FS-ISAC, RH-ISAC, IT-ISAC, ME-ISAC, A-ISAC, and MS-ISAC, most of them within hours of the domain being found. None is named here.

The registration phase has now ended. The last domain was taken on August 31, 2026 and nothing has been registered in the six days to September 6, across all four naming constructions under monitoring. That is the longest silence in the campaign, and it arrived with no tapering beforehand. The figures below therefore describe a completed acquisition phase, which is a firmer position than this piece could have taken a week earlier.

This is a study of pre-attack infrastructure. Not one of the 61 domains has served content at any point in the collection window. Every one holds a live hostname and 57 hold a valid publicly trusted certificate, and none has ever presented a page to anybody. There is no phishing kit to fingerprint, no lure text to quote and no landing page to screenshot, because none of that exists yet. What exists is the scaffolding, and the scaffolding is what this piece describes.

That is the state of the infrastructure. The state of the campaign may be further along. Three organizations have reported voice phishing calls in which the caller named a domain from this cluster. Those reports reached Flare through sector information sharing channels and none has been independently confirmed. They are recorded in this piece as third-party accounts, they are identified as unconfirmed wherever they appear, and no finding depends on them.

Passive registration data establishes that infrastructure was built, by whom it is held in common, and when. It does not establish what the operator intends to do with it, and no claim of that kind is made here on the strength of this dataset alone. The value of pre-attack analysis is not explanatory. It is that domains which have not yet been used can still be blocked, and the organizations they name can be told before anybody calls them.

At a Glance

Table 1. Campaign at a glance as at September 6, 2026. These are floor figures. Each naming construction was found by testing a candidate string, so the true set is at least this size and may be larger.

A note on language. This piece uses “the operator” for whoever registered and holds this infrastructure. That is a claim about a single registering party, supported by the shared attributes set out below. It is not the same claim as the attribution to ShinyHunters, which is inherited from public reporting and is treated separately throughout.

Two themes run through what follows. The first is method: infrastructure of this kind can be identified before it activates, but only if defenders stop treating the first observed naming pattern, or the first infrastructure relationship they pivot on, as complete. Every construction here was found by guessing a string, three of the four after the first notifications had gone out, and two groups initially counted as part of the campaign turned out to belong to somebody else.

The second is disclosure. We ran notification alongside collection, issuing individual alerts through four sector information sharing bodies as the picture changed and reissuing them when it changed again. The section on it sets out what that produced and what it cost.

All findings derive from passive sources. We performed no active scanning, no port probing, no interaction with the identified infrastructure and no retrieval of hosted content.

Key Findings About the ShinyHunters Campaign

• The published naming pattern was incomplete. Four constructions are used against a target brand, and three of them were identified only after notification had begun: the brand alone, us-[organization], claims-[organization] and [organization]-claims, across the .claims and .com extensions.
• Nameserver similarity is a grouping signal and not an attribution signal. 12 nameserver-pair groups hold between one and 10 domains each, 11 organizations have domains split across more than one group, and one has three domains in three separate groups registered on the same day.
• Not one of the 61 domains carries a mail exchange record. Whatever delivers a victim to these domains does not originate from them, which is inconsistent with an email-led operation run from this infrastructure.
• Targeting is concentrated in healthcare and insurance. 16 organizations are within the health sector and 12 in financial services, of which eight are insurers, reinsurers, or brokers and three are banks or consumer finance.
• On August 22, five days after the advisory that exposed the campaign, a domain impersonating the security vendor that published it was registered within the campaign infrastructure.
• Matching on a single Cloudflare nameserver hostname returned 629 candidates for five genuine domains, under 1% precision. Matching on the exact pair is far better but still not sufficient on its own, as the two groups later excluded demonstrate.
• Notification improved collection. The first batch of alerts produced a new naming construction that continued enumeration of the original pattern would not have found. 48 organizations received individual alerts through four sector bodies over 19 days, and six were reissued as further domains surfaced.
• Three organizations have reported voice phishing calls naming a domain from this cluster. We have not confirmed those reports. If they are accurate, delivery is running ahead of the landing page: a caller names a destination that is provisioned, certificated and empty.
• Registration ran for 36 days and then stopped. The last domain was registered on August 31, 2026, and six days of monitoring across all four constructions have produced nothing since.

Where This Started

ReliaQuest published the advisory reproduced in Figure 1. It is worth reading closely, because almost everything Flare did afterward was an attempt to convert its description into a list.

Figure 1. ReliaQuest Threat Research advisory, August 17, 2026, reproduced as published. We identified the cluster described in this piece independently of that advisory.

The advisory gives three things: a naming pattern, a pretext, and an actor attribution.

We took the naming pattern and treated the other two as context to be tested.

The obvious first move was to enumerate the .claims top level domain in full. It is a small Identity Digital namespace, which makes a complete census tractable in a way it would never be for .com. That enumeration covered approximately 14,750 registered domains and produced the initial cluster. It also produced a great deal of material that looks like the cluster and is not.

Any analyst who follows the advisory to its obvious conclusion will run a .claims sweep and immediately encounter three unrelated abuse populations. They are larger and older than the campaign, and separating them out is most of the work:

• The largest is a cryptocurrency drainer cluster of roughly 190 domains registered since July 2025 through a different registrar, impersonating wallet brands and token projects for airdrop themed pages, around thirty of which already carry a content delivery network phishing interstitial. An analyst triaging .claims will hit this set first because it is the loudest thing in the namespace.
• A freight and dispatch operations using claims-prefixed names against load boards and transport management platforms.
• Aa bankruptcy and creditor claims portal cluster. Neither is connected to the campaign described here.

There is also a legitimate population that will contaminate a block list if it is not identified. Two insurers registered their own names under .claims on August 18, the day after the advisory. A health technology vendor registered its entire acquired brand portfolio on August 20, ten names in one day. A maritime terminal operator did the same across roughly 40 names on September 1. All three waves are separable by registrar and risk profile, and all three are evidence that the advisory and the notifications propagated quickly.

Volume alone does not identify the campaign. Over the 24 months to August 2026 the .claims namespace averaged 186 registrations per month. July 2026 saw 131 and the first 18 days of August saw 82. There is no spike.

What there is instead is a share. 25 of the 82 .claims registrations in the first half of August, close to a third of everything registered in the namespace, belong to a single operator.

What Holds the Cluster Together

No single attribute identifies campaign infrastructure. The cluster is defined by a conjunction, and it is worth being explicit about which elements carry weight.

Table 2. The conjunction that defines the cluster. No element is sufficient alone.

The certificate timing deserves particular attention because it is easily overlooked and it did more work in this investigation than any other single attribute. Within this investigation, same-day certificate issuance combined with absent content was the strongest discriminator between campaign infrastructure and the false-positive populations examined, including the domain investment portfolio described later, where certificates were issued seven days after registration and one domain was already serving a page. No baseline for the wider domain population has been established here, so the combination is offered as a discriminator that worked against these specific false positives and not as a universal signature.

The absence of mail records across all 61 is the second load-bearing observation. Nothing in this infrastructure is configured to send, so whatever brings a victim to one of these hostnames originates somewhere else. The domains are destinations. What routes a target to them is not visible in registration data and is not asserted here.

Four Constructions, Two Extensions

The advisory described one pattern. There are four.

Table 3. Construction by extension. The two empty cells were tested and returned nothing.

The sequence in which these were found matters more than the distribution.

The bare form came from the advisory. The us- form arrived through a targeted organization that told its sector body what it had seen, three days after that body distributed the first batch of alerts. The prefix and suffix forms were found by an analyst typing a candidate string into a search box, eight days after the first notifications had already been issued.

The suffix form alone accounted for four organizations that were invisible until it was tested. Those four had no domain under any other construction.

Had nobody thought to try a suffix, they would never have been notified.

Two cells were tested and came back empty. There is no claims-[organization] under .claims and no [organization]-claims under .claims. The bare form under .com is largely blocked by prior registration, since the obvious .com for a large brand belongs to the brand.

Twelve Nameserver-Pair Groups

Cloudflare assigns each account a distinct pair of nameserver hostnames drawn from a shared pool. Domains sharing an exact pair are probably held in the same account, and within a set already filtered on registrar, term and hosting pattern that pairing is a reliable grouping key. Account ownership itself cannot be confirmed from outside the platform. Throughout this piece, the 12 groups are therefore described as nameserver-pair groups and treated as probable account groupings, which is the strongest claim the evidence supports.

The 12 groups hold between one and 10 domains each, which is unremarkable on its own. The distribution of targets across them is not.

11 of the 48 organizations have domains in more than one group. One organization has three domains, in three separate groups, all registered on the same day. Another has three domains across two groups registered on three consecutive days. A third has three domains in three groups spread over two days.

Fragmenting a target across several groups costs convenience and would limit the effect of an account-level suspension, since removing one group would take down part of the infrastructure aimed at a target and not all of it. Whether that is the reason for the separation cannot be established from registration data, and no intent is asserted here. What the data shows is that the registering side is organized around infrastructure groups. Individual victims are not the organizing unit, and targets are distributed across groups without an evident pattern.

The practical consequence for a defender is that finding one hostile domain bearing your brand tells you very little about how many exist. 11 organizations in this campaign had more than one, and none of them could have inferred the others from the first. It is also the reason six alerts had to be reissued.

What the Nameserver Pair Does and Does Not Prove

This section exists because we got it wrong in the first round of notifications as we were prioritizing speed based on indicators and understanding at the time.

The original notifications told recipients that domains sharing a nameserver pair are held in the same account and are under the control of the same party. That claim is too strong. Cloudflare draws pairs from a pool of a few hundred names, which yields on the order of tens of thousands of possible pairs against tens of millions of zones. Unrelated accounts share pairs routinely, and there is no external way to confirm account ownership.

Two measurements from this dataset put numbers on it.

First, single hostname matching is close to useless on its own. In a population of 12,997 Dynadot domains on Cloudflare nameservers, 629 used at least one of the 28 hostnames associated with the campaign groups. Five matched an exact pair. All five were campaign domains. Matching on a single hostname would have produced 634 candidates for five true positives.

Second, exact pair matching is far better but still insufficient. Across a larger unfiltered pull, 849 domains matched an exact campaign pair. Roughly 58 were campaign infrastructure. Two of the fourteen pairs originally identified turned out to belong to other people entirely: one to a domain investor holding 758 names across a vocabulary portfolio, another to a generic hosting operation holding 29. Both had passed the earlier filters because only the two or three domains from each that happened to appear in a .claims sweep had ever been seen.

The lesson is not that nameserver pairing is unreliable. It is that pairing groups rather than identifies.

Applied to a set already filtered on registrar, registration term, certificate timing and absent mail records, it reliably tells you which domains sit together. Applied to raw DNS, it tells you almost nothing.

Targeting

Sector distribution is skewed, and the skew is stable across the whole registration window.

Table 4. Organizations by sector information sharing body. Assignment reflects the most probable notification route. It does not assert formal membership.

Healthcare and financial services together account for 28 of the 48 targets. Both are sectors in which the word “claims” is core operational vocabulary rather than a peripheral term. A claims-themed domain bearing an insurer’s name is more likely to appear credible to that insurer’s staff as an internal or partner system. The same domain aimed at a manufacturer would carry far less plausibility.

Several targets sit in supply chain positions where a credential capture reaches well beyond the victim: a core banking technology provider, a systems integrator, a commerce platform, a claims administrator, a pharmaceutical distributor, a hospitality management platform. Whether that reflects deliberate selection or coincidence cannot be resolved from registration data.

One pattern in the labels is worth noting. Several domains use a stock ticker or a common abbreviation in place of the full corporate name, and two use a subsidiary brand in place of the parent. That is consistent with an operator working from a source that records how organizations are referred to in practice, though the registration record does not establish how any label was chosen.

Timeline and Cadence

The campaign ran for 36 days, of which 25 saw at least one registration. Daily volume ranged from one to five domains. There is no weekly rhythm in the sense a reader might expect: registrations occurred on Saturdays and Sundays, and the eleven inactive days fall on Sundays, Mondays, Tuesdays and a Friday.

If anything, the weekend is busier. The three highest volume days in the campaign carried five domains each, and two of those three are Saturdays.

The earliest artifact predates the first brand domain. On July 26, the operator registered a .com consisting of an apparently random keyboard string, in a group that would go on to hold campaign infrastructure. It took a certificate the same day and never served content.

It reads as a test of the pipeline, one day before the first brand name was taken.

Five pauses interrupt the window:

• two days from August 2
• one day on August 11
• two days from August 16
• one day on August 21
• five days from 25 August

The August 16 pause is the one that invites interpretation, because it began the day before the ReliaQuest advisory and ended the day after it. Registration resumed on August 18 at the previous cadence.

With that said, two days is not evidence of anything. The campaign took a two day pause a fortnight earlier with no advisory to react to, and the intervals between pauses run nine, five, five, four and four days without settling into a rhythm. The timing is worth recording and will not carry an inference.

The window closes on August 31, and this time the close appears to be real. Monitoring has continued across all four naming constructions and returned nothing for the six days to September 6, exceeding the previous longest gap of five days. Every earlier pause ended without warning, so a resumption cannot be excluded.

What is notable is the absence of a wind-down. The operator did not taper. The five-day pause from August 25 ended with a resumption on August 30 that added four new organizations, then a single domain on August 31, then nothing. Whether the acquisition phase simply finished, or the campaign was abandoned after being enumerated and its targets notified, is not resolvable from registration data. Public disclosure on August 17 did not halt the campaign, and neither, in the fortnight that followed, did the notification of 48 organizations. Registration continued for a further two weeks before it stopped.

What did follow the advisory is less ambiguous. On August 22, a domain impersonating the security vendor that had published it was registered. That domain sits in a nameserver-pair group already holding six other campaign domains, matches the cluster attributes in every respect, and was registered five days after the advisory appeared. Flare assesses that the registration was a response to the advisory, on the basis of the timing and the group membership.

That registration creates a pretext that did not previously exist. Organizations across four sectors had just been told to expect this campaign. Contact purporting to come from the vendor that named the threat, or a link to a page appearing to host advisory content, is credible to a security function in a way that an approach to another department is not. A team trained to challenge unexpected help desk contact may not challenge what looks like follow-up from a threat intelligence provider.

Pre-Attack Posture and the Blocking Window

At the date of collection, none of the 61 domains serves content. Every one holds a live hostname. 57 of the 61 held a valid publicly trusted certificate: 52 issued on the registration day itself and five within one day of registration. Four held no certificate. We have not observed any of these domains serving content or capturing credentials.

A domain that holds a certificate and serves nothing has been provisioned for use. What that use is intended to be is not visible in this dataset. What is visible is that the work which normally precedes a campaign going live has already been done, and the step that has not happened is the one a defender can still get ahead of.

The practical consequence is a window that is open now and will close. Because none of these domains was observed serving legitimate content during collection, blocking them is likely to carry little or no operational impact, subject to local validation. Certificate transparency provides a useful signal for changes in provisioning. A new certificate covering a subdomain associated with authentication, legal services or another expected pretext would warrant review, though it would not by itself establish activation. At the apex, with no content, these domains cannot yet capture anything. Blocking them today is cheap. Blocking them after a page appears is incident response.

Reported Delivery Activity

Three organizations have reported receiving voice phishing calls in which the caller named a domain from this cluster. The reports reached us through sector information sharing channels.

We have not independently confirmed any of them. No call recording, transcript or telephony record has been reviewed, and it cannot be established which domain was named in which call, whether the caller spoke a bare domain or a fuller hostname, or whether any employee visited the destination. The organizations concerned are not identified here. These are third-party accounts and are treated as such throughout.

If the reports are accurate, they change the state of the campaign, but not the state of the infrastructure. The domains still serve no content. What would have changed is the sequencing: delivery running ahead of the landing page, with a caller naming a destination that is provisioned, certificated, and empty. It would also narrow the alternatives, since speculative registration, third-party defensive registration, and domain investment all remained available as explanations for individual names while the domains sat idle, and a caller reading a domain aloud to an employee removes them for the domains concerned.

The case for blocking also gets stronger. A domain that a victim is being directed to by telephone is intercepted at the resolver whether or not a page exists behind it. Blocking early stops the operation at the one point in the chain the defender controls outright.

That window is the reason notification ran alongside the collection rather than after it.

Notification in Near Real Time

Research of this kind normally ends with publication and an indicator list. Here, the notifications came first and the publication is the residue.

The first batch of 24 alerts went out on August 18, the day after the ReliaQuest advisory and the same day the initial cluster was assembled. Each was an individual document covering one organization, naming only that organization’s domains and carrying restrictive handling markings. They travelled as three packages, to the financial services, health, and retail and hospitality sharing bodies, each with a manifest instructing that the alerts be distributed singly and that the package not be forwarded intact, because the package as a whole names every targeted member in that sector.

Notification then tracked collection rather than concluding it. Further alerts followed on August 21 and 26 , on August 31 and on September 2 , as new naming constructions were tested and as registration resumed after the longest pause in the campaign. Six earlier alerts were reissued when additional domains surfaced against organizations already notified.

By the time registration stopped, 57 Flash-Alerts had been issued across seven sector information sharing bodies: financial services, health, retail and hospitality, information technology, media and entertainment, and both the aviation and multi-state bodies for a municipal airport authority. We notified one organization directly, because no sharing body covers professional staffing.

What the Approach Produced

The most useful return was not gratitude. It was a naming construction.

Three days after the first batch, a recipient organization told its sector body that alongside the pattern we had described, it had also seen a domain of the form us-[organization][.]com, registered at the same time and through the same registrar. That report is the sole origin of the second construction. It came from a defender reading an alert and recognizing something adjacent to it, and no amount of further collection on the original pattern would have produced it.

The second return was corroboration of the attribution logic. Across 48 notified organizations, not one identified a domain named to it as its own defensive registration. For a campaign built entirely on inference from registration data, with no content and no observed use, that is the strongest available check on whether the set was correctly assembled, and it is only obtainable by asking the organizations concerned.

The third was visible in the namespace itself. Defensive registration under .claims rose sharply in the days after the notifications began, including an organization outside the target set that registered its parent brand, its legal entity abbreviation and one subsidiary hospital in a single sitting. That organization had never had a domain registered against it by the operator. It was acting on a pattern rather than an incident, which is what a notification effort is for.

What the Approach Cost

Notifying while collecting means notifying from an incomplete picture, and the record shows exactly that. 11 organizations had more than one domain, and none could have inferred the second from the first, so six alerts had to be reissued with corrected domain counts. Four organizations were reached only because a suffix construction was tested eight days after the first batch, and four more only after registration resumed on August 30.

One reasoning error also reached recipients. A sentence in the first three weeks of alerts described two generic insurance vocabulary domains as evidence that the operator was preparing lure content. Those domains belong to an unrelated domain investment portfolio. The statement was withdrawn in the manifest of the final batch, which also recorded that neither domain had ever been listed as an indicator and that no recipient had been advised to block either, so no action was required. The correction is described in full in the section below.

The cost is churn and the risk of propagating a mistake at speed. The alternative was to hold everything until the picture stabilized, which would have meant notifying nobody until September 6, three weeks after the first domains were found and after the operator had finished registering. For pre-attack infrastructure that trade is worth making: the value of the finding decays as the infrastructure activates, and a partial notification that arrives before activation is worth more than a complete one that arrives after it. That judgment follows from the specific fact that these domains were provisioned and idle, and does not generalize to every kind of research.

Crossover Analysis Against a Contemporaneous Campaign

On August 6, 2026, ten days before the ReliaQuest advisory, Google Threat Intelligence Group published an analysis of UNC6671, a vishing-led extortion operation using adversary-in-the-middle credential harvesting and exfiltration from enterprise cloud environments. Public threat actor profiling maps UNC6671 into the same ShinyHunters ecosystem to which this campaign is attributed. We tested the two datasets against each other.

There is no infrastructure overlap. Every root domain and network indicator published by GTIG was checked against 43,169 domains collected during this investigation. No domain matched and no address matched.

There is no target overlap either. Passive DNS against f14 of the GTIG root domains yielded 250 victim-named subdomains registered from March 2026 onward. Not one corresponds to any of the 48 organizations in this campaign. The eight victims named publicly in the January 2026 activity attributed to the same ecosystem appear in neither set. Across three related bodies of activity the target lists are disjoint.

Zero overlap across 298 organizations is inconsistent with the two datasets being drawn from the same broad target population. It does not establish that the operators are unrelated, and the subdomain set recovered from passive DNS is not necessarily the whole of the UNC6671 target list.

The architectures are also inverted. UNC6671 places the victim name in a subdomain of a generic authentication themed root, so one root serves many targets and burning it costs a cohort. This campaign places the victim name in the second-level domain, so one domain serves one target. The first is cheaper and more fragile, the second more expensive and more durable. Registrar, hosting spread and semantic theme differ throughout, and the tempo relative to registration is opposite: GTIG records domains stood up and used within minutes, while these have sat empty for weeks.

Where the two converge is behavior, not infrastructure. Both are vishing led with an identity pretext, both rely on adversary-in-the-middle credential capture, and both are documented as exfiltrating from the same enterprise cloud platforms. GTIG offers the simplest explanation in its own alternatives: separate actors using commoditized phishing panels and voice phishing services can deploy matching pretexts without organizational alignment.

The comparison supports a narrower claim than a shared operator. The tradecraft in this ecosystem is commoditized. The target lists are not.

What We Got Wrong

Three errors in this investigation are worth publishing, because each is a class of mistake rather than a one-off slip, and because two of them reached recipients before they were caught.

Reading Purpose into Proximity

Two domains built from generic insurance vocabulary appeared in the first .claims sweep, registered together, four days before the earliest brand domain. They matched the registrar and hosting pattern. They were read as lure vocabulary staged ahead of the branded infrastructure, and that reading went into every notification issued in the first three weeks.

They belong to a domain investor. The same portfolio contains hundreds of names across automotive, legal, and financial vocabulary under a dozen extensions.

The discriminators were present in the data already held. Both took a certificate seven days after registration, where every cluster domain takes one on the day, and one was already serving a descriptive page. A filter that would have excluded them was overridden by a narrative that fit.

Letting Group Membership Confer Campaign Membership

After the nameserver-pair groups were identified, two domains surfaced in a confirmed campaign group bearing target brand names under unrelated extensions. Every infrastructure attribute matched, so they were briefly counted as campaign infrastructure on that basis, then excluded on review because neither carries claims semantics and a brand under a review extension is a different proposition entirely. Membership in a confirmed campaign group does not make everything inside it part of the same operation.

Assuming a Sampled Enumeration was Complete

One phase of collection paged through a filtered population 500 records at a time. Measured against domains already known from other sources, that approach achieved 71% recall: two of seven confirmed campaign domains in the sampled window never appeared in any page taken. Any total derived that way is a floor, and stating it as a total would have been wrong by roughly a third.

ATT&CK Mapping

Table 5. Technique mapping. “Direct” indicates evidence present in this dataset. “Inferred” indicates the technique follows from the observed data without being directly evidenced by it. “Reported” indicates a third-party account received through sector channels and not confirmed by Flare. “External” indicates documented tradecraft attributed to this ecosystem in public reporting, included for completeness and not observed here.

Key Judgments

High Confidence

• The 61 domains constitute a single coordinated registration campaign. Shared registrar, uniform one year terms, a common privacy service, a continuous registration window, a common hosting pattern, universally absent mail records, and overlapping nameserver-pair groups support this jointly.
• The infrastructure is adversarial, not defensive brand protection. Defensive registrations are held in the organization name through corporate registrars, and are not placed behind privacy protection at a low cost registrar inside a cluster of unrelated brands. Across 48 notified organizations, none identified a domain named to it as its own registration.
• Infrastructure associated with individual targets is distributed across multiple nameserver-pair groups. This fragmentation is consistent with compartmentalized infrastructure and would limit the effect of an account level takedown. Whether the separation was deliberate, operationally convenient or incidental cannot be established from this dataset.
• This campaign and the UNC6671 activity documented by GTIG do not share infrastructure or targets. No domain, address or targeted organization is common to both, across 43,169 domains and 298 organizations examined.

Moderate Confidence

• The cluster belongs to the ShinyHunters campaign reported by ReliaQuest. The pattern match against the published description is exact and the timing is consistent. No indicators were published against which to confirm overlap, and no content has been served from these domains that could be compared against known tradecraft.
• The registration of a domain impersonating the reporting security vendor is a response to the advisory rather than coincidence. The timing is five days, the group is a known campaign group, and no comparable registration appears earlier in the window.
• The infrastructure is intended to support credential harvesting reached through a pretext delivered outside this infrastructure. The universally absent mail records establish that delivery does not originate here. Three unconfirmed reports of calls naming cluster domains point the same way. The specific mechanism of capture rests on documented tradecraft for the named ecosystem and not on anything in this dataset.

Low Confidence

• Delivery has begun against part of the cluster. This rests entirely on three third-party reports that Flare has not confirmed and cannot corroborate from registration data. Nothing else in this piece depends on it, and it should be discounted by any reader who weighs unconfirmed reporting differently. (Low to moderate confidence)
• The concentration in healthcare and insurance reflects deliberate sector prioritization. The skew is pronounced and stable across the window, but a 36 day sample is a short base from which to infer strategy.
• The two day pause beginning August 16 was a reaction to public disclosure. The timing is suggestive, but the campaign took an equally long pause a fortnight earlier with no advisory to react to, and two days sits well within the ordinary variation of a window containing eleven inactive days.

Recommendations for Security Teams

• Check all four naming constructions, not the one that was published. Test your name, common abbreviations and ticker as [organization], [organization]-claims, claims-[organization] and us-[organization], across both .claims and .com. Three of the four were found only by manually testing strings after notification began, and one accounted for four organizations that appeared under no other form.
• Assume more than one if you find one. 11 of the 48 had domains under multiple constructions, often in different infrastructure groups and registered days apart. None could have inferred the second from the first.
• Extend social engineering training past the help desk pretext, and include your own security team. The functions that handle claims, benefits, and legal correspondence are the target population this naming implies, and they are rarely covered by awareness programs built around password resets. A domain impersonating the vendor that first reported this campaign was registered five days after the advisory, which is a pretext aimed at people who have just been briefed on the threat.
• Instrument the whole identity chain, including the cleanup. Authenticator enrollment or replacement straight after a sign in from an unfamiliar location is the detection that matters. Public reporting on this ecosystem also documents deletion of the resulting notification emails, so enrollment alerting alone can fail silently.
• Use certificate transparency as the provisioning signal. If you find a domain naming your organization, watch for further issuance beneath it. A certificate covering an authentication or legal subdomain warrants review, though it does not by itself establish activation.
• Block the name, not the address. Three domains in this campaign resolved to commodity shared hosting carrying over a thousand unrelated hostnames. An address block would have hit legitimate traffic and stopped nothing.

On Notifying Affected Organizations Before the Campaign Went Live

What makes that window worth writing about isn’t just that it exists, but also what happened inside of it. Notification ran alongside collection, rather than the typical process of after it. Every one of the 48 organizations named in this campaign was alerted through its sector information sharing body, most within hours of their domain being identified, over 19 days. That ordering matters. Research usually publishes first and notifies second, by which point the infrastructure has often had months to sit unremarked. Here, the alerts went out while the picture was still forming, because an incomplete warning delivered early is worth more than a complete one delivered late, provided the gaps get closed as they’re found.

That’s the part worth taking away above the domain counts and the confidence ratings. Notification here distributed and improved findings, because the people it was protecting furthered the research.

The infrastructure may still activate. Every earlier pause in this campaign’s registration history ended without warning, and the six days of silence observed since August 31 don’t rule out a seventh day that breaks it. But for now, the estate is mapped, the certificates are issued, and nothing has been served. The notified ISACs have what they need to close it, and organizations outside this specific target list have a pattern worth checking their own brand against before somebody else finds it first.

Methodology and Limitations

Collection used commercial domain registration data, passive DNS, certificate metadata, and public reporting. We performed no active scanning, no port probing, no interaction with the identified infrastructure, and no retrieval of hosted content. Nothing in this piece required touching the operator’s systems.

Enumeration began with a census of the .claims top level domain covering approximately 14,750 registered domains, then extended through nameserver pivoting and targeted string testing once further naming constructions were identified. Each construction was found by testing a candidate string. Coverage should therefore be read as a floor, and further constructions may exist that nobody has thought to try.

All figures are current as at September 6, 2026. The last registration observed was on August 31 and monitoring returned nothing in the six days to publication, so the counts describe a registration phase that appears to have closed. Every earlier pause in this campaign ended without warning, and a resumption cannot be excluded.

Two of the five certificates issued within a day of registration carry a not-before value one day earlier than the recorded registration date, which is consistent with a timezone boundary between the two sources and not with issuance preceding registration.

One phase of collection sampled a filtered population by paging and achieved 71% recall when measured against domains known from other sources. Totals in this piece are drawn from the nameserver pass, which is bounded rather than sampled, but the sampling limitation applies to any figure derived from a paged export.

Two nameserver pairs initially grouped with the campaign were excluded on review, having been identified as an unrelated domain investment portfolio and a generic hosting operation. Two further domains in a confirmed campaign group were excluded because they carry no claims semantics. One second level label maps to more than one plausible organization and has been left unattributed instead of guessed.

Attribution to ShinyHunters is inherited from the public reporting shown at Figure 1 and has not been established independently. What we have established is that the infrastructure is coordinated and adversarial. Whether it is operated by the group named in that reporting, by an affiliate, or by an unrelated actor following the same pattern, is not resolvable from registration data alone. The crossover analysis in this piece bears on that question only to the extent of showing that one other body of activity attributed to the same ecosystem is separate from this one.

No targeted organization is named in this piece. Each was notified individually through its sector information sharing body under restrictive handling markings, and those notifications contain the specific domains, nameserver pairs and addresses relevant to that organization. Naming them here would provide an attacker with a consolidated target list and would offer defenders nothing their own sector body has not already given them. The aggregate figures are what generalize; the names are not.

We have observed no attack associated with this infrastructure. The three voice phishing reports recorded here are third-party accounts received through sector channels, are unconfirmed, and are identified as such at every point they appear. Any organization that observes activity connected to these domains, whether phishing content, lure text, sender detail or telemetry, is encouraged to share it through the appropriate sector information sharing body, under whatever handling that organization judges appropriate. That will help characterize the activation timeline and pretext wording for the wider community.