TL;DR: The Com is a decentralized criminal ecosystem that keeps producing new handles and brands even after arrests, so defenders who treat Scattered Spider, LAPSUS$, ShinyHunters and SLH as one thing risk misattribution and the wrong response, according to Flare analysis. Attribution discipline becomes a governance control, not a branding exercise, when social engineering outlives any single crew.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Flare's blog post: The Com is a shifting cybercriminal ecosystem, and misattribution becomes a security failure when brands outlive the clusters behind them.
Why it matters: Identity and SOC teams need to distinguish clusters, brands, and evidence levels so response, threat hunting, and executive reporting do not lock onto the wrong actor.
Context
The central security problem is not a single threat group but attribution under churn: when a criminal ecosystem keeps reusing tactics, handles, and public brands, defenders can confuse a cluster with a label and build the wrong response around it. In identity-heavy intrusions, that confusion matters because the same help-desk and account-recovery weaknesses can be exercised by different operators over time.
The article frames The Com as a social-engineering ecosystem whose value comes from speed, rebranding, and shared tradecraft rather than stable membership. That means practitioners need to think in terms of evidence thresholds, cluster continuity, and the governance of claims, not just incident names.
Key questions
Q: What are the signs that helpdesk password recovery is being abused?
A: Look for unusual reset volume, repeated assisted resets for the same identities, weak caller verification, and a growing gap between self-service and support-led recovery outcomes. Those patterns suggest the helpdesk path has become a softer trust boundary than the primary sign-in flow.
Q: Why do social engineering crews succeed against identity workflows?
A: They succeed when identity controls rely on human judgement under pressure, such as password resets, MFA fatigue, help desk verification, or urgent approval paths. Attackers exploit weak identity proofing, reused personal data, and exceptions in joiner-mover-leaver or privileged access workflows to obtain valid credentials or authorise unauthorised access.
Q: How do analysts separate a threat cluster from a public brand?
A: Analysts separate them by looking for converging evidence of behaviour, infrastructure, tooling, targeting, and victim overlap rather than by names used in public reporting. A threat cluster is an observed set of related activity, while a public brand is a label that may reflect marketing, self-promotion, or attribution guesses.
Q: What is the difference between an intrusion cluster and a criminal brand?
A: An intrusion cluster is a technically linked set of malicious activity, usually tied together by shared infrastructure, tradecraft, malware, or operational patterns. A criminal brand is the name used in public or underground reporting for a group, which may cover several different clusters or change over time as operators split, merge, or rebrand.
Technical breakdown
How criminal ecosystems separate clusters from brands
A criminal ecosystem can contain multiple intrusion clusters, shared personas, and temporary public brands without those elements becoming one operational entity. A cluster is the recurring set of behaviours, infrastructure, and tradecraft that persists across incidents. A brand is the label used to claim credit, recruit, or amplify fear. When those two are conflated, analysts can mistakenly merge unrelated activity, overstate continuity, or revive a defunct actor because a former participant reused a familiar name. See the Threat Actor Groups Guide.
Practical implication: Treat naming as an analytic output, not a starting assumption, and require separate evidence for cluster continuity and brand association.
Why social engineering dominates these intrusions
The common thread across The Com is social engineering, especially calls, messages, and support-workflow manipulation aimed at people who can approve access. That matters because the attack path avoids novel malware in favour of trusted processes: help desks, identity providers, account recovery, and SaaS support. The technical signal is often not exploit code but the abuse of legitimate workflow steps that were built for speed and user convenience. Read Human vs Non-Human Identity.
Practical implication: Harden support workflows as attack surface and look for approval paths that can be driven by persuasion instead of technical compromise.
Why evidence thresholds matter in attribution
Attribution is strongest when independent lines of evidence converge, such as behavioural patterns, infrastructure reuse, court records, and first-party incident-response findings. A single indicator, like a social-engineering method or a claimed identity in a channel, may show similarity but not identity. The risk is false precision: telling leadership that a named crew was involved when the record only supports a broader ecosystem or an unresolved cluster. See the Structured Analytic Techniques for CTI Guide.
Practical implication: Set a minimum evidentiary standard before naming an actor, and separate confidence in the incident from confidence in the label.
Threat narrative
Attacker objective: The objective is to gain trusted access through human and workflow manipulation, then convert that access into theft, extortion, or ransomware-enabled impact.
- Entry begins with social engineering, usually through help-desk impersonation, account-recovery pressure, or other trust abuse aimed at an employee or support function.
- Credential access follows when the victim is manipulated into approving access, resetting credentials, or authorizing a connected app through a legitimate workflow.
- Escalation and lateral movement occur once the attacker can operate with valid access inside identity or SaaS systems, often using normal administration tools and approved paths.
- Impact is achieved through data theft, extortion, ransomware affiliate activity, or broader compromise that persists even after individual operators are removed.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Attribution is itself a security control in The Com environment: When teams collapse clusters, brands, and aliases into one label, they lose analytic precision and weaken response decisions. The same access tradecraft can appear under different names, but the governance failure is treating a label as evidence. Practitioners should separate what is proven from what is merely familiar.
The Com is a notoriety market, not just a profit market: Many actors in this ecosystem monetize attention as much as access, which changes how they choose victims and how loudly they claim credit. That means public claims can be part of the attack pattern rather than a reliable indicator of identity. Security programmes should treat visibility into channels and reputational signalling as part of threat intelligence, not as noise.
Shared branding does not equal shared command: The SLH label functions as a coordination and marketing layer over more than one intrusion stream. That structure matters because it explains why some activity clusters persist even when named individuals are arrested. For practitioners, the lesson is to model continuity at the behaviour level, not at the banner level.
Evidence weighting must outrank familiarity bias: A known name in a breach discussion can become an anchor that distorts judgment. Analysts should resist the urge to reuse a famous label when the record only supports a weaker conclusion. The practical outcome is a cleaner incident narrative that survives scrutiny from peers, legal teams, and executives.
Help-desk trust is now part of the attack surface taxonomy: The most durable pattern in these cases is not malware but procedural abuse of identity workflows. That places service-desk verification, account recovery, and identity-provider administration into the same governance conversation as privileged access. Security leaders should classify those workflows as primary assets, not back-office support.
What this signals
Attribution discipline will matter more as criminal ecosystems fragment: Security teams will need to record confidence, not just names, because a familiar label can mask a new operator or a recycled persona. That becomes especially important when executive reporting, legal response, and external disclosure all depend on the same incident narrative.
Help-desk governance is now a frontline identity issue: The next wave of social-engineering intrusions will continue to target support functions because they sit at the boundary between human trust and privileged action. Identity programmes that treat recovery workflows as administrative plumbing will keep leaving a practical gap between policy and enforcement.
For practitioners
- Strengthen help-desk verification Require strong identity checks before password resets, MFA resets, device changes, or support-driven account recovery, and make the escalation path auditable.
- Separate clusters from brands Document actor names, aliases, and campaigns separately in threat intelligence notes so a public brand does not overwrite the underlying evidence.
- Set an attribution threshold Name a specific actor only when independent evidence converges, such as behaviour, infrastructure, and first-party reporting, and otherwise use a broader cluster label.
- Treat support workflows as attack surface Review account recovery, identity provider administration, and SaaS support paths as controlled access channels that can be abused through persuasion.
Key takeaways
- The core risk is not a single threat name but the tendency to turn a shifting ecosystem into a false certainty.
- The article shows that arrests did not stop the underlying tradecraft, which means personnel changes do not eliminate the operating model.
- Practitioners should treat attribution quality as part of response quality, because the wrong label drives the wrong controls.
Related NHI Mgmt Group resources: Human vs Non-Human Identity · Threat Actor Groups Guide · Structured Analytic Techniques for CTI Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0001;TA0006;TA0008 — Initial Access; Credential Access; Lateral Movement | The Com cases rely on social engineering to obtain access, steal credentials, and move laterally. |
| Recommendation — Map social-engineering intrusions to TA0001, TA0006, and TA0008 to improve detection and response coverage. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Attribution quality and evidence thresholds are risk decisions that affect response and reporting. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on abuse of identity workflows that grant access through support processes. | |
| Recommendation — Define evidence thresholds for actor naming within your risk management strategy and incident review process. Tighten support-driven access approvals and require stronger proof before changing entitlements. | ||
| CIS Controls v8 | CIS-5 — Account Management | Help-desk abuse targets account recovery and credential changes, which are account-management failures. |
| Recommendation — Review account recovery and reset processes under CIS-5 to remove easy paths to unauthorized access. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | Human operators are being manipulated into granting or changing machine and SaaS access. |
| Recommendation — Limit human-driven approval of NHI access changes and add stronger verification before granting access. | ||
Key terms
- The Com: A decentralized cybercriminal ecosystem rather than a single gang. It is held together by shared language, status, social channels, and reusable tradecraft, which means the same behaviours can persist even when handles, brands, or individual operators change.
- Social Engineering: Social engineering is the use of deception, urgency, and authority to persuade a person to reveal information or take a risky action. It targets human decision-making rather than software defects, and often turns legitimate identity workflows into the attack path.
- Help Desk Vishing: A social engineering attack that uses phone or SMS impersonation to trick support staff or users into resetting credentials, enrolling devices, or revealing MFA codes. In identity programmes, it turns operational support into an authentication path and bypasses controls that assume requests are legitimate because they sound legitimate.
- Cluster Attribution: The process of linking addresses, accounts, or services to a shared operator set or criminal network. It is especially useful in crypto-enabled fraud because it reveals overlap across marketplaces, payment paths, and laundering services that may not be obvious from a single incident.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org