Modus Operandi: UNC6671

On 6 August 2026, Google Threat Intelligence Group published seventy-two domain names. They were meant to be indicators — things to block. Read differently, they are something considerably more interesting: a four-month behavioural record of the people who registered them. This assessment reads them that way.

Seven findings below are original to this publication. None appear in the vendor reporting, and four of them change what a defender should do on Monday morning. The dataset and the analysis code are published at the back so that any of it can be checked or disputed.

Subject: UNC6671 / CORDIAL SPIDER / CL-CRI-1116, operating the BlackFile, Redact, Pink, Helix and Falcon extortion brands.

Evidence base: GTIG’s 6 August infrastructure tables and May 2026 lifecycle report; Push Security’s operator-panel research; Reuters and Bloomberg victim reporting; CrowdStrike and Unit 42 crosswalks. Analytic cut-off 1800 ET, 8 August 2026.

Method: Independent reconstruction and quantitative analysis of the published corpus, cross-correlated against panel research. Confidence terms follow ICD 203. Sources are graded on the Admiralty scale. Observed conduct and analytic inference are kept apart throughout and never merged inside a sentence.

Bottom line up front

The call comes to a personal mobile, not a desk line. In recent cases the number on the screen is the organisation’s own helpdesk, because the caller has spoofed it. The voice is fluent and unaccented and knows the employee’s name. There is an urgent security migration underway — passkeys, FIDO2, an MFA update that has to be completed today — and the caller will stay on the line and walk them through it. The employee is directed to a site whose name sounds exactly like something their own IT department would have stood up: [company].createssopasskey[.]com.

What happens next takes under two minutes. The employee enters their credentials. On the other end of the call, an operator watching a queue in a browser-based panel receives them over Telegram, types them into the real identity provider, sees which challenge it presents, and pushes the victim to a matching capture page — submit the SMS code, submit the authenticator code, approve the number displayed. The employee complies, because they are on the phone with IT and the page looks right. The operator completes the authentication, captures the session, and the employee is redirected to a screen confirming their ticket has been closed.

Then the operator navigates to the compromised user’s own security settings and enrols a new multi-factor device — an Android handset the employee has never seen. From that moment the identity provider believes the attacker is the employee, and will go on believing it after the password is changed.

That sequence is well documented and is not what this report is about. What this report is about is the seventy-two domain names that had to exist for it to happen, and what those names — their registration dates, their registrars, their name servers, their vocabulary — reveal about the organisation that provisioned them.

Within twenty-four hours of GTIG’s publication, Reuters had taken the seventy-two root domains, fed them into passive-DNS and URL-scanning services, and read out the victim-named subdomains Google had deliberately withheld. The resulting list became the story: Blackstone, KKR, Apollo Global Management, Bain Capital, Bridgewater Associates, TPG, CME Group, Moody’s, Clearlake Capital, and the law firms Paul Hastings and Greenberg Traurig. More than two hundred organisations in total. Greenberg Traurig said no breach occurred. None of the others confirmed one.

It was a good piece of journalism and it produced a week of headlines about Wall Street getting phoned. But it treated the corpus as a lookup table — domains in, victims out — and then discarded it. The corpus is not a lookup table. It is a behavioural artefact, and nobody has read it as one.

Analysed as a record of conduct rather than a list of indicators, those seventy-two rows describe an organisation that keeps a five-day working week; that migrated registrars not for operational security but because one of them was enforcing abuse policy and the others were not; that maintains two structurally different classes of infrastructure for two different purposes; that made a deliberate decision in late May to stop using vendor brand names and thereby rendered itself invisible to the class of monitoring most enterprises pay for; and that spent its final fortnight before publication converging on a single sector using a naming convention it had not touched since April.

None of that is opportunism. All of it is management. The most useful thing a defender can take from this campaign is not a blocklist. It is the recognition that they are facing an organisation with a provisioning function, a supplier-selection process, an internal division of labour, and a demonstrated capacity to learn from enforcement pressure and adapt within weeks. You do not out-train that. You have to out-architect it.

The seven original findings, in one place

1. The operation provisions infrastructure on a conventional five-day week. Sixty-five of seventy-two registrations fall Monday to Friday. In 121 days of continuous activity there is a single Sunday registration.

2. The registrar migration is abuse-response arbitrage, not opsec rotation. Every domain the actor registered through PublicDomainRegistry was suspended. Not one of the fifty NiceNIC or sixteen Tucows domains was.

3. There are two operations inside this corpus. Four “key-sync” domains carry four and a half times the sector breadth of the passkey mainline — prospecting instruments rather than attack instruments — and two of the four are GTIG’s named Helix bridges.

4. Vendor brand names were retired on 26 May and never returned. Combined with subdomain-based victim naming, this makes registration-based brand monitoring structurally incapable of detecting this actor.

5. Four root domains GTIG names in prose as confirmed brand-bridge infrastructure are absent from its own indicator table, and therefore from every feed derived from it.

6. The operation converged on financial services in its final fortnight and revived an April-era naming convention to do it. That is a live campaign signature, not a historical trend.

7. Push Security’s panel Clusters C and D map onto the April registrar transition row for row. The registrar change and a phishing-panel code revision are the same event, which turns WHOIS metadata into a proxy for build lineage.

ICD 203 analytic line

UNC6671 is a professionalised, centrally coordinated criminal enterprise operating a deliberate multi-brand structure — not a fragmented affiliate network that happens to share tooling.

High confidence — raised from GTIG’s baseline on independent temporal evidence

GTIG assesses coordinated multi-brand operation as most likely while carefully preserving three alternatives: splintering, shared phishing-as-a-service, and outsourced extortion. It cannot separate them, because the evidence it used — infrastructure overlap, shared templates, common victimology — is equally consistent with all four. One coordinated group and four separate groups buying the same panel produce identical domains.

Registration timing does separate them, and GTIG did not use it. The four hypotheses predict different calendars. Independent splinter cells working personal schedules generate weekend activity. A commoditised panel sold to many buyers generates registration events scattered across many buyers’ working patterns, and therefore across the week. A single provisioning function inside one organisation, working a business week, generates exactly what the corpus contains: ninety per cent weekday concentration, one Sunday in four months, and a batching pattern consistent with one operator sitting down and standing up several names in a session. This is independent evidence bearing on GTIG’s own open question, and it points one way. It does not disprove outsourced extortion — the negotiation layer may still be contracted out — but it substantially weakens the case that the intrusion layer is fragmented.

The operation runs a tiered targeting model: a small set of broad-aperture prospecting domains feeding a much larger population of narrow, victim-specific attack domains.

Moderate confidence

Sector breadth per domain is not randomly distributed, and the outliers are not scattered. Four domains — oskeysync, keysyncos, oskeyconnect, myconnectkey — average nine and a half targeted sectors against a mainline average of two. They are also the only four domains in seventy-two that abandon the passkey root token, building instead from key plus sync or connect. The lexical break and the aperture break fall on the same four rows. Two structurally independent features agreeing is what distinguishes a real cluster from a coincidence.

GTIG independently identifies two of the four as the infrastructure bridging into organisations later listed on the Helix leak site. If both observations hold, Helix sits on the prospecting tier of a tiered operation rather than being a peer brand to Falcon and Pink — a structural fact about internal division of labour rather than about marketing. That last step is inference and is offered as such. The alternative reading, that the key-sync family is a second builder with looser targeting discipline, is not excluded by the data.

Registration-based brand monitoring — the control most enterprises rely on to catch lookalike domains — provides effectively zero coverage against this actor, by design.

High confidence

Two observed decisions compound. The victim organisation’s name appears only in the subdomain, and subdomain creation produces no registration event: no WHOIS record, no registrar notification, nothing for a brand-monitoring service to alert on. Separately, vendor brand strings vanish from root domains after 26 May, and the forty-seven registrations that follow use generic authentication vocabulary that infringes no trademark and belongs on no watch list.

This is not theoretical. It was demonstrated in public on 6 August, when Reuters surfaced four months of victim names in a single day using passive DNS — names no brand-protection product had raised in all that time. The collection source that works is passive DNS keyed on the root domain. The collection source most organisations actually buy is registration monitoring keyed on their own brand string, and against this actor it never had a chance.

The August 5 hedge-fund voice-cloning wave and the UNC6671 campaign are being conflated in public reporting. On present evidence they are separable, and merging them will produce the wrong defensive investment.

Moderate confidence that they are distinct or only partially overlapping

GTIG’s three publications on this actor describe an IT-helpdesk impersonation pretext driving passkey enrolment. Not one of them mentions synthetic voice. The Bloomberg-sourced reporting of 5 August describes something materially different: cloned voices of known executives and colleagues, which requires different pre-attack intelligence, defeats a different control, and terminates in a different place. No primary source attributes the voice-cloning activity to UNC6671. Section 6 sets an explicit merge criterion, so that the two are joined when evidence justifies it rather than by headline drift.

Absent enforced origin-bound authentication, the current control set will keep failing against this actor no matter how good the user training is.

High confidence

Every documented compromise path in this campaign terminates in a human relaying a valid authentication response to an operator in real time. Push Security’s panel research shows the operator brokering each MFA step by hand, with a dedicated interface action for SMS codes, authenticator codes and push approvals. There is no step in that sequence a sufficiently convincing caller cannot talk a reasonable person through. Origin binding under WebAuthn is the only control in the observed chain that fails closed regardless of what the user believes, who the voice sounds like, or how urgent the pretext is. Session shortening, device binding and continuous access evaluation reduce blast radius. They do not prevent the relay.

Section 1

This is not a summary of the GTIG report. That report is public, well written, and does not need paraphrasing. It is treated here as a primary dataset and subjected to analysis its authors did not perform, then correlated against independent panel research and the victim reporting that followed within a day.

The distinction matters for a paying reader. Vendor threat reporting is written to a different brief than yours. It has to establish attribution, protect incident-response client confidentiality, and generalise guidance across a global customer base. It is not written to tell one specific security team what to hunt for on Monday. The gap between those two documents is where this desk works.

The corpus was reconstructed by hand from GTIG’s published indicator table into a seventy-two-row structured dataset carrying domain, creation date, registrar, name servers and targeted industries. Before anything was concluded from it, it was validated against GTIG’s own published claims about the same table. GTIG states that seven domains were operationalised between 20 and 22 July; the reconstruction contains exactly seven. Reuters describes seventy-two published web addresses; the reconstruction has seventy-two rows. GTIG gives a June to July provisioning cadence of one domain every 1.6 days; the reconstruction yields 1.49, the same figure to the precision GTIG published it.

One figure does not reproduce. GTIG describes twenty-eight root domains provisioned between 1 April and 31 May; the table contains twenty-nine. The most probable explanation is that a single row was excluded from the tempo calculation — plausibly passkeyportal[.]com, which carries no stated target industry and may have been treated as unattributed. The discrepancy is immaterial to every finding below, but it is recorded rather than quietly smoothed, because a product that reproduces three of a source’s four published figures and silently drops the fourth is not being rigorous. It is being tidy.

The three GTIG and Mandiant publications — the January cluster-separation report, the May lifecycle report, and the 6 August rebrand report authored by Tyler McLellan and Austin Larsen — are graded A1 and constitute the authoritative baseline for everything factual here. The January report matters more than its age suggests, because it is the document that establishes which behaviours belong to UNC6671 and which belong to the separately tracked UNC6661. A great many secondary write-ups have since blurred that line, importing UNC6661 procedures into UNC6671 profiles and producing hunt hypotheses with no evidentiary basis.

Push Security’s May 2026 panel research is graded B2. The firm gained direct access to live operator deployments, and its account is vendor-interested but methodologically transparent and independently verifiable through the file hashes it published. Its four-cluster infrastructure model is used here as corroboration and enrichment, never as attribution on its own.

CrowdStrike’s CORDIAL SPIDER profile is graded A2 and supplies both a cross-vendor crosswalk and an activity horizon reaching back to at least October 2025 — earlier than GTIG’s January public start. Those two dates should not be flattened into a single first-observed statement. Vendors draw cluster boundaries differently, and the gap most likely reflects collection and definition rather than proof that GTIG’s January cluster was itself operating in October.

Reuters’ passive-DNS victim enumeration is graded B2: methodologically sound and reproducible, but naming a target is not confirming a compromise. Bloomberg’s hedge-fund reporting is graded B3 as anonymously sourced; it establishes that a voice-cloning campaign occurred, and nothing about who ran it. Section 3 in its entirety is this desk’s own work, published with its dataset and code at Appendix A precisely so that it can be attacked.

A standing caveat on the corpus

GTIG states plainly that most of the IP addresses in its tables are commercial VPN nodes, that source addresses rotate continuously, and that domains are frequently used within minutes of registration. The corpus is a record of past provisioning behaviour, not a live blocklist. Every finding in Section 3 is a finding about tradecraft. None should be deployed as a static indicator with an indefinite lifetime.

Section 2

BlackFile announced its shutdown on 11 May 2026. The money never stopped moving. GTIG’s blockchain analysis, conducted with the independent researcher ZachXBT, traced 141.65 BTC — roughly $10.69 million at transaction-time valuation — across eighteen wallet addresses between 7 January and 12 May, and established that payments continued arriving after the shutdown notice was posted. Significant cash-out events occurred in late April and early May, while the rebrand was in progress. The shutdown was theatre performed over a functioning payment pipeline.

On 27 June, operators posting under the Redact name published a statement on a newly established leak site explaining themselves. The BlackFile brand, they said, had been hijacked by an exiled affiliate who ran a lookalike leak site and conducted unsanctioned extortion under unlinked Tox identities. That rogue associate had deliberately staged the May shutdown in order to confuse threat intelligence analysts and cyber-insurance negotiators and damage the brand’s reputation. They introduced a single verified Tox identity and PGP key to authenticate all future correspondence, and explicitly denied that pressure from rival groups had influenced the decision.

That document is worth reading as behaviour rather than as fact. It is a public communication aimed at an audience that includes insurers and professional negotiators, and its content is a reputational repair exercise: our brand was stolen, we are the real operation, here is how you verify you are talking to us. An organisation that issues a verified PGP key so its counterparties can be certain who they are negotiating with is not thinking like a smash-and-grab crew. It is thinking about repeat business and about the integrity of its own market. That instinct — protect the channel, protect the price — recurs throughout this actor’s conduct, and it is the same instinct that shows up later in the registrar migration and in the abandonment of trademark-infringing domain names.

GTIG’s negotiation data is the most commercially revealing material in the report. Opening demands run from $1 million to above $3 million. Reductions of fifty to seventy-five per cent are agreed as a matter of routine. In more than half of tracked cases the final payment averaged roughly $750,000, about 10.2 BTC.

A seventy-five per cent concession offered routinely is not distress. It is a pricing strategy in which the opening demand functions as an anchor and the settlement is the actual product. This actor prices to close. It would rather book $750,000 quickly and move to the next engagement than hold out for $3 million and risk the victim deciding to absorb the leak. That is a volume business making rational decisions about cycle time, and it tells you how a negotiation will go: the number will move, the deadline is a lever rather than a wall, and the person on the other end is optimising throughput rather than maximising any single case.

For planning purposes the relevant figure is the settlement distribution, not the demand. And for anyone hoping this actor will lose interest: a business converting reliably at three-quarters of a million dollars an engagement, against a domain-provisioning cost measured in tens of dollars, has no economic reason to stop.

The August reporting adds two behaviours absent from older profiles, and the second is the most consequential change in the entire document.

The helpdesk number is now spoofed. In at least some recent cases the caller presents the organisation’s own legitimate helpdesk number. This defeats the single most widely circulated piece of user guidance in existence — “check the number” — and that guidance needs removing from awareness material immediately. Advice that fails silently is worse than no advice, because it manufactures confidence in exactly the moment when doubt was the only protection available.

Persistence has moved outside the SSO boundary. Operators now use the compromised mailbox to trigger password resets on enterprise applications that do not federate, then systematically delete the reset confirmations, the secondary security notifications, the organisation-wide security alerts, and any MFA or account-security change notices generated along the way.

Consider what that does to a response. A team detects the intrusion, disables the identity, revokes sessions, strips the rogue authenticator, and declares eradication complete. The adversary still holds working credentials on every application the mailbox could reset by email — and the mailbox evidence that would have told anyone which applications those were has been destroyed. The absence of the confirmation emails is itself the finding, and almost nobody is looking for an absence.

It is also a behavioural tell. Deleting the security-alert mail is not a technique borrowed from a playbook; it is what someone does after being burned by a victim who noticed. This operation is iterating against real defensive outcomes, and the iteration cycle is measured in weeks.

If you take one action from this section

Enumerate every business application in your estate that authenticates outside SSO and supports self-service password reset by email. That list is your post-eradication residual risk register for this actor. Most organisations have never compiled it, and it is almost always longer than the identity team believes.

Section 3 — original analysis

What follows has not, to this desk’s knowledge, been published anywhere. It is analysis of GTIG’s seventy-two-row indicator table treated as a behavioural record. Each finding states what was measured, what it says about the organisation, and what a defender does with it. The code is at Appendix A.

Resolve every registration date in the corpus to a day of the week and the distribution is not close to uniform. Sixty-five of seventy-two registrations — just over ninety per cent — fall Monday to Friday. A uniform distribution across a four-month window would put roughly seventy-one per cent on weekdays. Monday alone accounts for sixteen registrations, more than twice the seven that fall across both weekend days combined. Across 121 consecutive days of activity, this actor registered exactly one domain on a Sunday.

That is not an artefact of sparse or bursty activity. The median gap between consecutive registrations is one day and the longest gap anywhere in the corpus is seven, so the operation was provisioning near-continuously and still avoided weekends. There are twenty-five same-day registration events, which is the signature of a batching workflow: an operator sits down, stands up three or four names in one session, and closes the laptop. Somebody’s job includes doing this, and that somebody works Monday to Friday.

Infrastructure provisioning for UNC6671 is performed by a person or small team working a conventional five-day week, on a schedule set by an organisation rather than by opportunity.

High confidence

This is worth more than it first appears, because it speaks directly to the question GTIG left open. GTIG lists four competing explanations for the multi-brand structure and cannot separate them from infrastructure overlap alone — overlap is equally consistent with one coordinated group and with several independent groups buying the same phishing-as-a-service product. Temporal structure does separate them, because the four hypotheses predict different registration calendars, and only one of them predicts this one.

Splinter cells running their own operations on personal schedules produce weekend noise; criminals working for themselves do not observe Sundays. A commoditised panel sold to a broad population of buyers produces registration events scattered across all those buyers’ individual working patterns, which averages out toward uniformity rather than clustering on Mondays. A single provisioning function inside one organisation, working a business week, produces precisely what we observe. The finding is not conclusive on its own — nothing in this domain is — but it is genuinely independent evidence bearing on an open question, and it points one way.

For collection planning, the corollary is simple. Weight infrastructure-emergence hunting toward the start of the week. If you sweep passive DNS or certificate transparency for authentication-themed registrations, the corpus says Monday and Tuesday are your highest-yield windows, and that a weekend hit is unusual enough to deserve a human look rather than automated triage.

The corpus contains a clean registrar transition. Tucows dominates April with thirteen of that month’s seventeen registrations. NiceNIC International Group appears for the first time on 20 April, runs alongside Tucows for forty-four days, and after 3 June Tucows never appears again. From mid-July to the end of the corpus, NiceNIC is the sole registrar in use. Two smaller suppliers thread through the whole period: Internet Domain Service BS Corp with four registrations, and PDR Ltd — trading as PublicDomainRegistry — with two.

The standard reading of this, and the one that appears in existing analysis, is that registrar is a campaign-era correlation feature rather than a durable actor fingerprint. That is true as far as it goes, and it is also the least interesting thing the data says. The interesting question is not that the actor moved but why. The answer is sitting in the name-server column, and it has been overlooked because it is expressed as an absence.

Two domains in the corpus show name servers set to a registrar suspension holding state at the time GTIG published: passkeyregistration[.]com and portalsetuphub[.]com. Both were registered through PDR. They are the only two PDR domains in the corpus, which means every single domain this actor registered through PublicDomainRegistry was taken down at the registrar. Meanwhile fifty NiceNIC registrations and sixteen Tucows registrations — several of them months old, some already publicly documented — were still un-suspended on the day a major vendor published them by name.

The actor ran a two-domain experiment with PDR in early June. It lost both. It never used PDR again. Read alongside the timing of the NiceNIC ramp, the migration looks less like operational-security hygiene and more like a procurement decision made by somebody who was tracking which suppliers cost them inventory.

The registrar migration is best explained as abuse-response arbitrage — the actor migrating toward registrars with demonstrably slower or absent abuse enforcement — rather than as opsec-driven rotation.

Moderate confidence

This changes how you age indicators. If registrar were merely a rotating fingerprint it would carry no predictive value and you would expire every indicator on the same schedule. If registrar is a proxy for enforcement exposure, it predicts domain lifetime — which is precisely the variable an indicator-ageing policy needs and rarely has. A PDR-registered domain in this family is a short-lived object that will probably be suspended without your intervention; a NiceNIC-registered domain is a long-lived object that will not be, and that therefore justifies a durable block, an abuse referral, and a longer review interval.

It also hands you a lever most teams have written off. Registrar abuse referrals are usually treated as a low-yield chore that nobody has time for. This corpus is direct evidence that against at least one registrar in this actor’s supply chain, they work at a hundred per cent success rate. That is worth knowing before you decide not to file one.

Every row of GTIG’s table carries a list of targeted industries. Treating the length of that list as an aperture measure — how wide a net a given domain was cast with — produces a distribution that is emphatically not flat. April and May domains average just under two sectors each. July domains average 1.74. The two August domains average one. June averages 4.18, more than double every month around it.

At first glance that reads as a genuine targeting expansion, which is broadly how the vendor narrative treats June. It is not. Four domains produce almost the entire anomaly. myconnectkey[.]com, registered 13 June, targets seven sectors. oskeyconnect[.]com, 17 June, targets nine. oskeysync[.]com and keysyncos[.]com, registered 20 and 30 June, target eleven apiece — which is to say very nearly every sector GTIG tracks.

Those four domains are 5.6 per cent of the corpus and carry 20.7 per cent of all domain-to-sector targeting relationships in it. Their mean aperture is 9.5 sectors against a passkey-mainline mean of 2.08, a factor of four and a half. Strip them out and June’s apparent expansion disappears entirely; the mainline was doing in June exactly what it did in May and July.

The four are also lexically distinct, and that is what turns an outlier into a finding. Sixty of the seventy-two domains build on the token passkey. These four do not. They construct instead from key paired with sync or connect, or with an os prefix. The lexical break and the aperture break fall on exactly the same four rows. Two structurally independent features agreeing on the same partition is what separates a cluster from a coincidence, and it is why this desk treats them as a distinct class of infrastructure rather than as noise.

The corpus contains at least two functionally distinct infrastructure tiers: a small set of broad-aperture prospecting domains used to test reach across many sectors at once, and a larger set of narrow, target-specific attack domains.

Moderate confidence

The behavioural reading is that these are different tools for different jobs. A domain configured to serve credential-harvesting subdomains across eleven industries simultaneously is not being used to attack a specific firm; it is being used to find out which subdomains get traffic, which pretexts land, and where the soft targets are. A domain configured against a single sector, or a single company, is the follow-through. An organisation that maintains both is running reconnaissance and exploitation as separate functions — which is, again, management rather than opportunism.

The Helix correlation makes this more than an academic point. GTIG independently identifies oskeysync[.]com and keysyncos[.]com as the infrastructure clusters bridging into organisations later listed on the Helix leak site. Two of the four broad-aperture domains are therefore GTIG-confirmed Helix bridges. If both observations hold, the Helix brand sits on the prospecting tier of a tiered operation rather than being a peer brand to Falcon and Pink. That would be a fact about the actor’s internal division of labour, not about its branding — and it would suggest the brands are functional compartments rather than merely reputational ones.

Stated as inference, not observation. GTIG’s bridging analysis and this desk’s aperture analysis are consistent with that reading; neither establishes it. The alternative — that the key-sync family is simply a different operator’s build with looser targeting discipline — is not excluded by the data.

Operationally, the two tiers warrant different response tempos. If a “key-sync” pattern domain surfaces in your passive DNS with your organisation as a subdomain, treat it as a broad prospecting hit and expect siblings across your sector; coordinate through your ISAC. If a narrow “passkey” pattern domain surfaces with your name on it, treat it as target-specific and assume a call has already been placed or is imminent.

Six domains in the corpus contain the string okta: myoktasso, oktaenroll, keyokta, oktaportalsso, addoktapasskey and passkeyokta. They run from 4 April to 26 May 2026 and then stop. After that date, forty-seven consecutive domains were registered containing no vendor brand string whatsoever — not Okta, not Microsoft, not Entra, nothing. The vocabulary becomes uniformly generic: passkey, sso, mfa, 2fa, portal, helpdesk, enroll, activate.

A second lexical marker moves at almost the same moment. Hyphenation is entirely absent from the first thirty-one domains in the corpus. It appears for the first time on 3 June, in passkey-setup[.]com, and then recurs seven times. That one is easy to read: the unhyphenated namespace was running out, and the actor started buying compound forms it had previously avoided.

The brand-token retirement is the more deliberate decision, and the reasoning behind it is not hard to reconstruct. A domain containing a registered trademark is legally and operationally fragile in ways a generic one is not. It is detectable by every commercial brand-protection service on a trivial string match. It gives the trademark holder standing for expedited UDRP action. It triggers registrar abuse processes that generic vocabulary simply does not activate. A domain called createssopasskey[.]com infringes nothing, belongs on nobody’s watch list, and gives no third party standing to complain about it. The actor worked that out in May and has not registered a branded domain since.

Now combine that decision with where the victim’s name actually lives. It is not in the root domain at all. It is in the subdomain — [company].createssopasskey[.]com. Subdomain creation generates no registration event: no WHOIS record, no registrar notification, no zone-file addition that any external monitoring service observes. GTIG notes separately that seven of the eight still-resolving domains lacked wildcard DNS, which confirms the subdomains were individually provisioned per target rather than catching arbitrary traffic. Each one was typed out deliberately, for a named company, by somebody who had that company on a list.

Conventional domain-registration and brand-protection monitoring provides effectively zero detection coverage against UNC6671, by design. Organisations relying on it as their lookalike-domain control have an unmeasured blind spot.

High confidence

The proof of this is not analytical, it is empirical, and it happened in public on 6 August. Reuters took the seventy-two published root domains, queried passive-DNS and URL-scanning services, and read out victim subdomains that no brand-monitoring product had surfaced across four months of operation. The collection source that works is passive DNS keyed on the root domain. The collection source most enterprises pay for is registration monitoring keyed on their own brand string, and against this design it was never going to fire once.

Do this today — the self-enumeration check

Any organisation reading this can determine in under an hour whether it was targeted. Take the seventy-two root domains from GTIG’s table — plus the four missing ones in Section 3.6. For each, query passive DNS or a subdomain-enumeration service for observed subdomains. Match the results against your own organisation name, trading names, common abbreviations and ticker symbol.

A hit is not evidence of compromise. It is evidence that a credential-harvesting page was provisioned with your name on it, which means a call was probably placed. That converts an open-ended worry into a bounded incident: pull identity-provider authentication events, MFA enrolment events, and SharePoint and OneDrive access for the seventy-two hours either side of the subdomain’s first observation, and see what you find.

If you have no passive-DNS capability, this campaign is your business case. It is the only collection source here that would have given you warning.

The vendor narrative describes a July narrowing toward financial services and legal. Quantified against the corpus, the convergence is sharper than that, and it is still accelerating at the moment the data ends.

In April, eight of seventeen domains touched financial services. In May that collapses to one of twelve, while legal climbs to a quarter of the month’s registrations. June brings financial services back to twelve of twenty-two and pushes legal to its peak at nine of twenty-two — forty-one per cent, the high-water mark for the whole corpus. Then legal falls away almost completely, to two of nineteen in July and none in August, while financial services climbs to twelve of nineteen and then to both of the final two domains. Mean aperture in the final month is exactly one: these are single-sector instruments.

Every one of the last six domains carrying a stated target profile is financial services and nothing else. The final eight registrations run: passkeystatus and secure-passkey on 21 July, addssopasskey and ssopasskey on 22 July, createssopasskey on the 28th, myssopasskey on the 31st, and hubpasskey and passkeymfa on 3 August — three days before GTIG published, and five days before this report.

There is a second signal buried in those names. Four of them reintroduce the sso token in a ten-day burst. That token appears four times in April, then vanishes completely across May and June — sixty-odd registrations without it — and then returns four times in late July. That is a deliberate reversion to an earlier convention, not lexical drift, and it coincides exactly with the sector narrowing. The actor appears to have concluded that finance-sector employees respond better to SSO framing than to passkey framing, and adjusted.

As of the corpus cut-off, UNC6671 is running a narrow, single-sector campaign against financial services using an SSO-plus-passkey naming convention revived from its April tradecraft. The next tranche of infrastructure is more likely than not to follow this convention.

Moderate confidence

For financial-sector defenders this is not history. You are looking at the current state of a live provisioning pipeline whose two most recent registrations predate this report by five days. Whatever was registered between 3 August and today is not in the corpus, is not in the VirusTotal collection, and is not in your feed. Section 9 converts the observed naming grammar into a forward monitoring list on exactly that basis.

Hosting is not distributed randomly across registrars. Fifty-eight of seventy-two domains — just over eighty per cent — sit behind Cloudflare name servers, alone or paired with something else. That is the default build, and Cloudflare fronting buys the actor address concealment, working TLS, and, per Push Security’s research, Turnstile bot-gating that prevents automated scanners from ever seeing the phishing content at all.

Twelve domains pair Cloudflare with Private Layer, AS51852 in Switzerland, across a window running 21 April to 28 July. That pairing is the one hosting feature in the corpus that correlates with confirmed adversary-in-the-middle proxy capability: GTIG’s own network table places its two panel AiTM reverse proxies, at 31.7.56.61 and 31.7.56.52, on that same autonomous system. A domain in this naming family whose resolution path touches AS51852 is not a name somebody reserved. It is a name with a live proxy standing behind it, and it should jump the queue.

A third lane runs quietly alongside the mainline for the whole period. Six domains sit on DDOS-GUARD name servers, and all four of the corpus’s Internet Domain Service BS Corp registrations are among them, joined by two Tucows domains. Not one NiceNIC domain ever appears on DDOS-GUARD. That is a structurally separate provisioning path with its own registrar and its own hosting, running in parallel throughout — consistent with a second builder, or with a deliberately segregated capability the main pipeline is kept away from.

GTIG’s narrative section names specific root domains as the bridges connecting the extortion brands to one another. Cross-checking those named domains against GTIG’s own indicator table produces a gap. The Falcon and Helix bridges are all present. The Pink and BlackFile bridges are not: of the domains GTIG names in prose for those two brands, only passkeydeploy and passkeyuser made it into the table.

Four UNC6671 root domains you probably have not blocked

setupsso[.]com — BlackFile-attributed; bridges into passkeydeploy (Pink)

idokta[.]com — BlackFile-attributed

mysecurepasskey[.]com — bridges the Pink and BlackFile clusters

passkeyms[.]com — Pink-attributed intermediate bridge

Each is named in GTIG’s published narrative as confirmed UNC6671 infrastructure. None appears in the indicator table, and therefore none is likely to be in the VirusTotal collection or in any feed derived from it. Add them, and run them through the self-enumeration check alongside the published seventy-two.

This is not a criticism of GTIG. Narrative and indicator tables are produced by different processes under different constraints and small divergences are routine. It is a criticism of how the rest of us consume vendor reporting. If your intake process is “ingest the indicator table, file the blog post,” you just missed four confirmed domains in an active campaign. Reading the prose is part of the job, and it is the part that automation cannot do for you.

Section 4

In May 2026, Push Security published something unusual: direct access to live deployments of the operator panel driving these campaigns. Its researchers watched real victim submissions arrive in real time, analysed multiple forks of the tooling, and mapped four infrastructure clusters. It is the closest thing in the public record to sitting behind the attacker’s screen, and read against the GTIG corpus it explains a great deal about why this campaign has been so hard to see.

Push’s Cluster C is a heartbeat-variant panel sitting behind Cloudflare Turnstile, serving victim-named subdomains from generic sso, passkey, enroll and okta root domains, registered through Tucows with Cloudflare name servers. Among the examples it cites is <target>.keyokta.com, dated April 2026. keyokta[.]com appears in GTIG’s table registered 13 April, Tucows, Cloudflare. Push’s Cluster D is a minified variant of the same client-side code, registered through NiceNIC with Cloudflare name servers, and the two examples Push names are <target>.passkeyportalsetup.com and <target>.addoktapasskey.com.

Those two Cluster D exemplars are the exact rows at which NiceNIC first enters the GTIG corpus — registered 20 and 21 April, the first two NiceNIC registrations of the entire campaign. Push dated Cluster D to April 2026 at low volume and characterised it as a code revision; GTIG dated the NiceNIC transition to those same two days. Neither vendor was looking at the other’s data. They are describing the same event from two vantage points, one through JavaScript and one through WHOIS.

The Tucows-to-NiceNIC registrar migration coincides with a phishing-panel code revision. Registrar metadata in this corpus therefore functions as a proxy for panel build lineage, not merely as a procurement detail.

Moderate confidence

The practical value of that correlation is that it lets you carry Push’s file-level indicators forward onto GTIG’s domain-level corpus. GTIG documented this campaign at the domain and network layer and published no hashes. Push documented it at the code layer and published several. If you recover panel content — from a takedown, a browser cache, a proxy body capture, a sandbox detonation — you can hash it against known builds and date it, rather than eyeballing the JavaScript and guessing.

The single most important operational fact in Push’s research is that the phishing content is never served to anyone who is not a live, approved target. The victim lands on the domain and sees a loading spinner. Nothing else happens until an operator, watching a queue, manually admits them. Later builds add Cloudflare Turnstile in front of that, plus operator-configurable geographic and device restrictions designed specifically to filter out visitors whose characteristics suggest a security tool rather than a person.

This is the structural reason a domain can operate against a named private equity firm for weeks without ever appearing on a blocklist. Automated crawlers see a spinner. URL scanners see a spinner. Reputation services have nothing to score. The malicious content exists only inside a session that a human being deliberately opened for a specific victim, and it closes again afterwards. Any detection strategy that depends on someone else having seen this domain first is structurally too late, which is why the useful controls in this campaign live in the browser and on the identity plane rather than in network reputation.

Push observed something counterintuitive: the panel does not proxy the victim’s inputs automatically the way a conventional adversary-in-the-middle kit does. An operator watches a queue, admits the visitor, receives the credentials over Telegram, types them into the real identity provider by hand, observes which challenge the provider presents, and then pushes the victim to the matching capture page — “Submit SMS OTP”, “Submit Gauth OTP”, or “Approve [XX] Prompt”, depending on what the real login is asking for.

That is a deliberate design choice, and it costs the attacker something. Manual brokerage inserts human latency into the authentication sequence at every single step. A legitimate user goes from password submission to MFA response in seconds; a victim in this flow waits while a person reads a screen, types into another window, and decides what to show them next. Authentication flows that stall between credential submission and MFA response, in a pattern inconsistent with that user’s own history, are a behavioural signal no static indicator provides — and one that is expensive for the attacker to remove, because removing it means giving up the operator control that makes this tooling effective.

The same research documents the professionalisation around it. The persona behind the original panel was observed recruiting “experienced callers” over Telegram, specifying fluent English with no accent, and advertising six- and seven-figure weekly returns. That is a labour market. The panel itself has been forked and rebranded by other operators, meaning the tooling has entered general distribution. The vishing capability and the panel capability are separate products with separate suppliers, and an organisation can now assemble this attack chain by procurement rather than by development.

The revamped Microsoft-targeting panel Push examined in April 2026 contained an operator action for pushing Microsoft Teams meeting instructions — a meeting ID and passcode rendered on a branded page — to the victim mid-flow. That escalates a credential-theft call into a screen-sharing session, with everything that implies. Two further capabilities were present in the source but inactive in the observed deployment: additional Duo and Okta approval pages, and a code-execution prompt whose placeholder example instructed the victim to run mshta against a remote HTA file.

A bridge from identity compromise into endpoint code execution exists in the panel codebase used by this ecosystem but was not active in observed UNC6671 deployments. Its activation would materially change the required detection posture.

Low confidence that it is currently in use — high confidence that the capability exists

Treat this as a tripwire, not a projection. The correct guidance today remains that UNC6671 requires no endpoint malware and that endpoint telemetry is the wrong place to spend your attention. That holds. But the moment any organisation observes a vishing call in this pattern that culminates in a Teams invitation, a screen-share request, or an instruction to run a command, the model has changed and endpoint controls re-enter scope immediately. Brief the helpdesk and the SOC on that specific escalation now, so it is recognised on first contact rather than reconstructed afterwards.

Section 5

Cross-vendor naming for this actor has expanded since most published profiles were written, and two of the newer identifiers attach to individual brands rather than to the parent cluster — which existing profiles do not reflect and which will confuse anyone whose platform ingests them.

GTIG’s UNC6671 is the reference definition and everything else here is mapped to it. CrowdStrike tracks the same broad activity as CORDIAL SPIDER, with an activity horizon reaching back to at least October 2025 — earlier than GTIG’s January public start, and a difference that most likely reflects collection boundaries rather than proof that GTIG’s cluster was operating in October. Palo Alto Networks Unit 42’s CL-CRI-1116 maps to the parent cluster and is listed by CrowdStrike as a community identifier. Newer and less widely known: CL-CRI-1147 maps specifically to the Pink extortion brand, and CL-CRI-1182 to Falcon. If your CTI platform ingests Unit 42 identifiers and you catch a Falcon-branded extortion note, you will get CL-CRI-1182 and no parent-cluster context at all unless somebody has built that mapping by hand. Build it.

Three names are explicitly not aliases and importing them will corrupt your profile. UNC6661 / SNARKY SPIDER shares a near-identical vishing and SaaS methodology but is tracked separately by GTIG on infrastructure and extortion-channel grounds; the ToogleBox Recall activity and the compromised-mailbox follow-on phishing that circulate in some UNC6671 write-ups belong to GTIG’s UNC6661 reporting, not its UNC6671 case description. UNC6240 / ShinyHunters is a separate extortion cluster historically paired with UNC6040’s Salesforce intrusions, and GTIG assesses UNC6671 as operating independently despite one observed use of the ShinyHunters name. Scattered Spider / UNC3944 is a tradecraft comparator and nothing more; GTIG has stated directly that it tracks this infrastructure, registration pattern and multi-brand network separately from Scattered Spider. Similar helpdesk social engineering is a TTP comparison, not an attribution.

That this actor is financially motivated and centred on SaaS data theft and extortion rests on direct incident-response and telemetry reporting across three GTIG publications, and is held at high confidence. That BlackFile was one of its extortion brands is stated explicitly by GTIG and carries the same weight. That Redact, Pink, Helix and Falcon are operated by actors affiliated with the same cluster sits at moderate to high confidence, resting on shared root domains, identical phishing templates deployed simultaneously across brands, and overlapping victim targeting — with splintering, shared phishing-as-a-service and outsourced extortion all preserved as live alternatives by GTIG, and preserved here too.

This desk departs from GTIG in one place. On the strength of the registration-cadence evidence in Section 3.1, the judgment that the intrusion layer is a single coordinated organisation rather than fragmented cells is held at high confidence rather than at GTIG’s more cautious baseline. That judgment is this desk’s, not GTIG’s, and it should be attributed accordingly if repeated. Note what it does not cover: whether the extortion and negotiation layer shares personnel with the intrusion layer remains at low confidence. GTIG explicitly floats outsourced negotiation, and the cadence evidence bears on provisioning, not on who answers the Tox messages.

The relationship between UNC6671 and UNC6661 is unresolved at the personnel level and should be maintained as a related-tradecraft annex rather than merged into either profile. And on the operators themselves — nationality, physical location, organisational composition — no primary source reviewed establishes anything at all. The correct field value is unknown. Not “suspected Eastern European,” not “likely English-speaking Western,” not any of the placeholders that migrate into profiles and harden into fact through repetition. Fluent unaccented English in the caller recruitment advertisement tells you about a hiring requirement, not about a nationality.

Section 6

On 5 August 2026 — the day before GTIG published — Bloomberg reported a wave of voice-phishing attacks against Citadel, Point72 Asset Management, Two Sigma Investments and Millennium Management, along with several unnamed private equity firms. Two Sigma said it blocked the attempt with no impact to data or systems. Point72 told investors it had been attacked and that initial review found no client data stolen, with the review continuing. Citadel and Millennium declined to comment. FINRA contacted member firms, and its Financial Intelligence Fusion Center — stood up in March 2026 — appears to have seen its first significant real-world use.

Within twenty-four hours these two stories were being reported as one. They should not be, and the reason is technical rather than pedantic.

GTIG’s three publications on UNC6671 describe an IT-helpdesk impersonation pretext driving an urgent passkey or MFA enrolment, terminating in an adversary-in-the-middle capture portal. Not one of them mentions synthetic voice anywhere. The Bloomberg reporting describes cloned voices of known executives and colleagues — which is a different attack requiring different preparation. To impersonate an IT helpdesk you need an employee’s name and mobile number. To clone an executive you need voice samples of that specific person and enough organisational knowledge to know whose voice will move which subordinate. Those are different collection problems, they are defeated by different controls, and no primary source has attributed the voice-cloning activity to UNC6671.

The August 5 voice-cloning wave and the UNC6671 campaign should be tracked as separate activity sets pending evidence of overlap. Merging them now would insert an unconfirmed capability into the UNC6671 profile and misdirect defensive investment.

Moderate confidence

The cost of getting this wrong is concrete. If you brief your executive team that “the group attacking private equity is using AI voice clones,” you will be asked what you are doing about deepfake detection, and you will spend the next quarter and a meaningful budget line on it. The control that actually stops the documented UNC6671 chain is origin-bound WebAuthn on your identity provider. Those are not the same programme, they do not compete well for the same money, and only one of them is supported by the evidence.

So set a merge criterion in advance rather than arguing about it later. Adopt the single-actor hypothesis if, and only if, one of three things appears: a reported incident in which a synthetic-voice call directs a victim to a domain in the passkey naming family; a primary-source vendor attributing voice cloning to UNC6671 in named reporting; or panel research showing voice-synthesis tooling integrated into the operator workflow. Absent one of those, keep them apart.

One nuance worth holding on to. There is partial victim overlap in the public record — hedge funds and private equity firms appear in both story sets, and Reuters’ passive-DNS enumeration surfaced a target list that intersects the Bloomberg-named funds. Overlapping victims in the same sector during the same fortnight is weak evidence of a common actor and strong evidence of a common target profile. Right now, every criminal group with a phone and a list has worked out that private equity holds deal data. Sector concentration is a market signal, not a fingerprint.

Section 7

A technique list is only useful if it distinguishes what was observed from what is merely plausible, so this one carries confidence and defensive value explicitly. It is the one place in this report where a table genuinely beats prose, because this is reference material you will look things up in rather than read.

Several techniques appear routinely in UNC6671 write-ups and should not. T1486 Data Encrypted for Impact is the worst offender: this is data-theft extortion with no encryption anywhere in the reported chain, and its presence causes teams to rehearse the wrong playbook and stand up the wrong recovery capability. T1657 Financial Theft is a poor fit for extortion proceeds, which belong under monetisation and business impact rather than in an ATT&CK mapping at all.

Three more should be removed as unconfirmed rather than as wrong. T1649 Steal or Forge Authentication Certificates does not match reporting that describes MFA and session material. T1041 Exfiltration Over C2 Channel presumes a command-and-control channel this operation does not have — there is no beacon, no implant, and no malware. T1537 Transfer Data to Cloud Account assumes a destination the evidence never establishes. T1133 External Remote Services should be downgraded or dropped, because valid SaaS and IdP login is modelled correctly by T1078.004 and a VPN origin alone does not make an externally exposed remote service. T1114.003 Email Forwarding Rule is not established for this cluster. And where a profile uses T1070.004 File Deletion to describe deleted mail, replace it with T1070.008, which is the sub-technique that actually covers mailbox anti-forensics.

A smaller, evidence-weighted matrix beats a large one every time. A list of thirty-six techniques that blends confirmed behaviour, adjacent-cluster behaviour and theoretical mappings does not make you better prepared. It makes your detection backlog longer and your coverage claims dishonest.

Section 8

Almost every stage of this attack is invisible to you. The phone call happens on a personal mobile you do not manage. The panel is bot-gated and will never appear in a threat feed. The exfiltration looks like a user reading files they are entitled to read. There is exactly one moment in the chain where the adversary must write an unusual record into a log you own, and that moment is the rogue authenticator enrolment. Everything below is organised around that fact.

GTIG published five user agents associated with this activity. Four are unremarkable — python-requests/2.28.1, WindowsPowerShell/5.1, a Firefox 146 string on Ubuntu, and a Pixel device model. The fifth has attracted no commentary anywhere and is the most operationally valuable single indicator in the report.

That is the Okta Verify Android application SDK, paired with a device model. Read together they describe an adversary-controlled Okta Verify enrolment on an Android handset — a Pixel 9 Pro XL — appearing in enterprise identity telemetry. This is the rogue MFA device registration of T1098.005, visible not as an abstract event type you have to infer, but as a concrete matchable string sitting in logs you already collect.

Okta-integrated organisations can hunt for adversary MFA enrolment using device-model and SDK-version telemetry rather than relying solely on enrolment-timing heuristics, which are noisier and easier for an adversary to evade.

High confidence in the detection value; moderate confidence that this specific device model persists

Two caveats before anyone deploys this as an alert. A Pixel 9 Pro XL is an ordinary consumer handset and some of your staff own one, so this is enrichment and prioritisation, not a standalone detection. And the device model is trivially changed — the specific string will age out, probably quickly, now that it is published.

The durable version of the detection is the interesting one. Build a baseline of Okta Verify SDK versions and device models enrolled across your estate, and alert on the long tail: device models appearing once or twice in a population of thousands. What the corpus tells you is that this actor enrols on real consumer hardware, which means it hides inside your device distribution rather than standing outside it. You will not catch it by looking for something obviously wrong. You catch it by looking for something rare. Rarity, not badness, is the signal — and that is a detection philosophy worth generalising well beyond this actor.

GTIG names the specific Okta system-log sequence that constitutes the highest-fidelity identity detection available here: a multi-factor registration event immediately preceded by an authentication failure or an abandoned push challenge. That pattern is the digital residue of the phone call — the operator fumbling the first authentication attempt, or the victim abandoning a challenge before being walked through the next one, followed minutes later by an enrolment nobody in your organisation requested.

The direct-fetch behaviour remains the most consequential visibility gap in this campaign. Content retrieved by direct HTTP request against SharePoint or OneDrive using a valid FedAuth cookie can register as FileAccessed rather than FileDownloaded. An organisation that treats FileAccessed as benign — and a great many do, because it fires constantly — will watch the theft happen and see nothing worth investigating. GTIG’s guidance is unambiguous: treat the two operations as equally critical when the user agent identifies a scripting library or when access volume exceeds anything a human could produce.

Two deliberate additions to the version of this rule circulating elsewhere. Go-http-client is included because GTIG names it explicitly in its hardening guidance even though it does not appear in the published user-agent table — which implies observation in cases GTIG did not document. And curl, okhttp and axios are added as generalisation: this actor’s scripting stack is not fixed, and a rule matching two literal strings will fail silently against the third build.

Single-signal detection will not work here, because every individual event in this chain has a perfectly good benign explanation. A user authenticates from a new network — they are travelling. An MFA challenge is abandoned — their phone was in the other room. A new factor is registered — they got a new handset. Files are accessed in volume — they are preparing for a deal. The chain does not have a benign explanation. Score the sequence, do not alert on the steps.

The last two steps are the ones most programmes have never instrumented, and they are the ones that decide whether your eradication actually worked. If you detect at step five and remediate the identity, steps six and seven have already given the adversary persistence outside your identity provider and destroyed the evidence that would have told you which applications to check.

One threshold note. GTIG’s own published behavioural logic uses fifty distinct documents across at least three file extensions within a five-minute window. Baseline that before you deploy it. In a legal or research environment those figures describe an ordinary Tuesday afternoon; in a manufacturing environment they describe an emergency. A threshold copied without baselining is not a detection. It is an alert-fatigue generator with a rule identifier.

Section 9

The core containment sequence for this actor is well established and is not restated here in full. What follows is the delta — the four things the August reporting changes about a UNC6671 response, and which most existing playbooks do not yet contain.

This actor holds three things: valid credentials, live session material, and a self-enrolled authenticator. A password reset addresses one of them. The mandatory minimum first action is to disable or restrict the identity, revoke every active session and refresh token, revoke OAuth grants, and remove every unrecognised authentication factor and registered device — comparing enrolment timestamps, source addresses and device fingerprints against the user’s own established baseline rather than against a generic notion of what looks suspicious. During an active incident, pause new MFA and device enrolment for the exposed population entirely; the actor’s persistence mechanism is the enrolment process itself, and leaving it open during remediation is like changing the locks while the door is propped.

The August reporting establishes that operators use the compromised mailbox to reset credentials on applications that do not federate, and those resets survive a clean identity-provider remediation. Add four things to your scoping checklist. Enumerate every non-SSO business application the compromised identity could have reset by email, and reset each of them independently. Search the mailbox — including recoverable items and any retained audit copy — for password-reset confirmations, security notifications, MFA change notices and organisation-wide security alerts, remembering that their absence in a window where you would expect them is itself the finding. Pull mailbox audit for hard and soft delete operations across the intrusion window and correlate against the reset events you should have seen. And treat any application whose reset state you cannot positively prove as compromised until demonstrated otherwise.

Remove “verify the caller ID” from your awareness content today. Helpdesk number spoofing is now confirmed in this campaign. Guidance that tells a user to check something the adversary controls is worse than no guidance, because it manufactures confidence at precisely the moment when doubt was the only protection available. The same objection applies to any verification that relies on the user recognising something — a voice, a name, a ticket number the caller supplies.

The only user guidance that survives contact with this actor

Corporate IT will never telephone your personal mobile and direct you to an unfamiliar site to enrol a passkey or update MFA while you stay on the line. If that happens, end the call, and contact the helpdesk yourself using the number in the intranet directory — not a number given to you during the call, and not a number that appeared on your screen.

Two sentences. No judgement required of the user. It fails safe against spoofed caller ID, against a convincing script, and against a cloned voice — which is why it also covers the August 5 activity even though that is probably a different actor.

On the helpdesk side of the same problem: suspend self-service password reset and self-service MFA enrolment for exposed populations during an active incident, require out-of-band callback to a directory-of-record number for any credential or MFA change, and require manager or out-of-band approval for privileged identities. Mandiant is explicit that employee ID, national identifier and manager name are not adequate verifiers, because that information is routinely already exposed — frequently by an earlier breach at a third party the employee never dealt with directly.

BlackFile-era cases included spam floods, threatening telephone calls and swatting-style pressure directed at individuals. Extortion communications have arrived through hijacked corporate email and Microsoft Teams accounts since at least March. This is not solely a SOC incident and it will not stay inside the SOC. Executive protection, corporate security, legal, crisis communications, insurance and law enforcement should be pre-briefed and on a call list before you need them, not assembled under time pressure during a negotiation window with a seventy-two-hour clock running.

Section 10

Read this caveat before the content. What follows is a generative hypothesis derived from the observed naming grammar of the corpus. These strings are predictions. They are not observed infrastructure. They have not been resolved, validated, or confirmed to be registered by anyone at all, and some of them will belong to entirely legitimate parties. Do not block them. Monitor them.

The method is straightforward. Sixty of the seventy-two domains decompose cleanly into an optional prefix, the token passkey, and an optional suffix. Learning the affix inventory from the terminal-era corpus only — registrations from 1 June onward, being the actor’s current productive style rather than its April style — and generating unobserved combinations yields a candidate space of 174 strings. Ranking those by affix productivity, by absence of hyphenation, and by the late-July revival of the sso and mfa tokens identified in Section 3.5 produces the following.

Use it as a cheap tripwire. Register a passive-DNS or certificate-transparency monitor on these strings and on the generalised pattern; if any resolves and carries a subdomain matching an organisation name, you have found live infrastructure before anyone published it. Weight your checking toward Monday and Tuesday per Section 3.1. And prioritise any hit whose resolution path touches AS51852 Private Layer, because per Section 3.6 that pairing is the one hosting feature in the corpus that correlates with a live adversary-in-the-middle proxy rather than a reserved name.

An honest statement of what this is worth

This is pattern extrapolation, not intelligence. Its predictive value decays the moment the actor changes lexical convention — which the corpus shows it has already done twice, once when it dropped brand tokens in May and once when it adopted hyphenation in June. Treat it as a cheap tripwire with a short half-life. If it fires, you have learned something valuable early. If it never fires, the actor has moved, and knowing that is worth something too.

Section 11

The most useful thing an analytic product can do is state clearly where it runs out. Six gaps materially limit everything above.

Whether the intrusion and extortion layers share personnel. This determines whether disrupting one brand disrupts the operation or merely closes one storefront. The cadence evidence in Section 3.1 bears on provisioning only, and says nothing about who answers the Tox messages. Closing it would require negotiation-channel analysis across brands: Tox and Session identity reuse, PGP key overlap, negotiator linguistic patterns, response-time distributions.

Whether the August 5 voice-cloning wave is the same actor. This determines whether synthetic voice enters the UNC6671 capability profile and whether defensive investment should shift accordingly. A single reported incident linking a synthetic-voice call to a domain in the passkey naming family would close it. The merge criterion is in Section 6.

Whether the mshta code-execution capability has been activated. Its activation would move this from an identity-plane threat to a hybrid identity-and-endpoint threat and change the entire control set. Any observed vishing call in this pattern that escalates to a Teams invitation, a screen share, or a command-execution instruction would be the first indication, which is why Section 4.4 asks you to brief for it now.

The true relationship between UNC6671 and UNC6661. The two are methodologically near-identical and separately tracked. Merging them wrongly corrupts both profiles; keeping them apart wrongly duplicates effort. Panel build-hash overlap between the two clusters’ infrastructure would settle it, and Push Security’s cluster model is the most likely place for that evidence to surface.

Nationality, location and composition of the core operators. No primary source establishes any of these, and speculation here is worse than silence because it hardens into fact through repetition. Realistically this closes through law-enforcement action, an operational-security failure, or blockchain cash-out attribution to identified exchange accounts — none of which a defender controls.

Post-corpus infrastructure. The dataset ends 3 August. Registrations almost certainly continued through the publication window and are continuing now. The Section 10 watchlist exists specifically because of this gap, and it is a poor substitute for the next GTIG update.

UNC6671 is not a malware group and should not be resourced as one. There is no implant to find, no beacon to detect, no ransomware to restore from, and no endpoint artefact worth chasing. The entire operation runs on things your organisation legitimately owns: a phone number, an employee’s good-faith trust, a valid credential, an authenticator you allowed to be enrolled, a session cookie, and an API your business depends on. There is nothing in that chain your antivirus was ever going to catch.

The corpus analysed in Section 3 describes an organisation that provisions infrastructure on a business calendar, migrates suppliers in response to enforcement pressure, maintains separate tiers for prospecting and attack, deletes the evidence of its own persistence, prices its extortion to close rather than to maximise, issues PGP keys so its counterparties can trust the negotiation channel, and made a deliberate decision in May to become invisible to the class of monitoring most enterprises pay for. Every one of those is a decision somebody made and then implemented consistently over four months.

The corollary is uncomfortable and worth stating plainly. Against an adversary this disciplined, the controls that fail gracefully — awareness training, caller verification, alerting on suspicious logins — will go on failing gracefully. They will catch the careless attempts and miss the competent ones, which is the worst possible outcome because it produces the appearance of coverage. The one control in the documented chain that fails closed — regardless of what the user believes, how convincing the caller is, or whether the voice belongs to their own manager — is cryptographic origin binding. Everything else in this report is about what to do until that work is finished.

Every quantitative figure in Section 3 derives from a seventy-two-row reconstruction of GTIG’s published indicator table, supplied alongside this report as unc6671_domains.csv. Its fields are the domain as published (refanged), the creation date, the registrar normalised to four values, the name servers verbatim, and the targeted industries as a semicolon-delimited list with “N/A” preserved as a literal rather than as a null. The script below reproduces the principal findings.