ATT&CK Botnets, Worms and Cryptominers Software Hub: Detecting Self Spreading and Resource Hijacking Malware

Self spreading malware turns one foothold into hundreds, and the newest members of the ATT&CK catalogue spread through stolen developer tokens and package registries rather than through network exploits alone. This hub brings together the 14 botnet, worm and cryptominer entries in MITRE ATT&CK Enterprise v20, from Agent.btz and Conficker to Shai-Hulud, GlassWorm and the Tsundere Botnet. It computes the behaviours they share from ATT&CK's technique mappings, sorts them by how they spread, and turns that into detection, hardening and measurement guidance. It is written for SOC analysts, detection engineers and platform owners responsible for Windows estates, developer environments and CI/CD. For the general concepts behind botnets, see the Botnets Guide; this page stays at catalogue level.

Key takeaways

• Spread mechanism defines the defence: the 14 entries spread in four ways, through removable media, network services and admin shares, shared content, or software supply chains, and each needs a different control set.
• Admin shares remain the classic lateral path: five entries use T1021.002 SMB/Windows Admin Shares and three use T1110 Brute Force, so local administrator password reuse is still what lets older worms run.
• Supply chain worms run on tokens: Shai-Hulud, GlassWorm and the Tsundere Botnet map to T1195.001 Compromise Software Dependencies and Development Tools, and Shai-Hulud also to T1528 Steal Application Access Token and T1552.001 Credentials In Files, which makes them non-human identity incidents.
• Persistence is simple and visible: seven entries use T1547.001 Registry Run Keys / Startup Folder and five use T1543 Create or Modify System Process, both easy to baseline.
• Mining is an impact, not a family trait: only LoudMiner and Lucifer carry T1496.001 Compute Hijacking here, but every self spreading family hands an attacker compute that can be resold, mined or used for denial of service.

What this category covers and why it matters

The category holds 14 ATT&CK v20 software entries, all typed as malware, whose defining behaviour is propagation or resource abuse. ATT&CK's own descriptions place them across almost two decades: Agent.btz, a worm that spreads through removable devices and reportedly infected US military networks in 2008; Conficker, first detected in October 2008 and spreading through the MS08-067 vulnerability; BlackEnergy, which began as a DDoS botnet toolkit and later carried plug-ins used against Ukrainian institutions; HermeticWizard, used to spread HermeticWiper in Ukraine from 2022; and Shai-Hulud, a supply chain worm first reported in September 2025 that spreads through GitHub and npm and steals credentials and access tokens.

Two things make the category worth a hub. Worms compress an incident's timeline: containment that works in hours for a manual intrusion can fail in minutes against automatic spread. And the newest members spread through identity rather than vulnerability. A stolen npm publishing token or a leaked extension publishing token lets the malware publish itself to every package the owner maintains, so the blast radius is set by token scope, not by network segmentation.

How the catalogue spreads

See the MITRE ATT&CK T1091 Replication Through Removable Media, the MITRE ATT&CK T1210 Exploitation of Remote Services and the MITRE ATT&CK T1195 Supply Chain Compromise.

Common behaviours across the catalogue

Counts are entries mapped to each parent technique in ATT&CK v20 (an entry counts once), computed from the software-to-technique relationships.

Catalogue: every botnet, worm and cryptominer entry in ATT&CK v20

All 14 entries, alphabetical. Platforms and groups come from ATT&CK v20; "key techniques" shows up to four mappings that show what is distinctive about each entry, not the full list. Follow the ID link for the cited reports.

Group links are thin: five of 14 entries are linked to a group. BlackEnergy is linked to Sandworm Team, Net Crawler to Cleaver, HIUPAN to Mustang Panda and TINYTYPHON to Patchwork. ATT&CK describes the Tsundere Botnet as attributed to a likely Russian speaking actor and links a variant named DinDoor to MuddyWater operations. See the Sandworm Threat Actor Profile, the Mustang Panda Threat Actor Profile Guide and the MuddyWater Threat Actor Profile.

Real cases from the NHI Mgmt Group breach library

• Shai-Hulud, first wave: install scripts in infected npm packages harvested npm and GitHub tokens and cloud keys, ran the TruffleHog secret scanner on the filesystem, then used any npm token found to publish infected versions of the owner's other packages. GitHub later reported removing more than 500 packages. See the Shai-Hulud npm Worm, First Wave (September 2025) and the Shai-Hulud npm Worm Guide.
• GlassWorm: code hidden with invisible Unicode characters in editor extensions stole npm, GitHub, Git and Open VSX tokens, and its loader read the next payload location from Solana blockchain transactions with Google Calendar as a fallback. The Eclipse Foundation linked the distribution to publishing tokens leaked in public repositories. See the GlassWorm Campaign 2025 and the GlassWorm VS Code Extension Worm Guide.
• TeamTNT worm (not a catalogue entry, same pattern): scanned for Docker APIs exposed without access control, installed itself in a new container on each, copied unencrypted AWS CLI credential files and mined Monero with XMRig. See the TeamTNT Worm 2020.
• Carbonato (not a catalogue entry, newest form): a 2026 botnet that entered through unauthenticated Docker daemons on port 2375, installed an AI agent framework to run tasks and prioritised stealing AI API keys to power the operators' own LLM gateway. See the Carbonato Botnet 2026.

Detection themes

1. Fan out: alert when one host connects to many internal hosts on TCP 445 or SSH within minutes, or when a workstation writes to another workstation's ADMIN$ share. Workstation to workstation SMB is rare in most estates.
2. Autostart and service creation: baseline Run keys, Startup folders and new services (System event 7045); alert on entries pointing to AppData, Temp or ProgramData executables.
3. Log clearing: alert on Security event 1102 and System event 104 outside planned maintenance; three entries clear Windows event logs.
4. Removable media execution: alert on processes launched from removable drives and on new hidden folders or shortcut files created at a drive root.
5. Package install behaviour: alert when npm, node, a VS Code extension host or an MSI installer spawns a shell, runs a secret scanner, reads cloud credential files or reaches webhook, paste or blockchain RPC endpoints.
6. Token use from new places: alert on registry publishing events, new GitHub workflow files or new public repositories created with tokens from unusual IPs or user agents.
7. Resource hijacking: sustained high CPU on idle hosts, connections to mining pool ports and new cloud compute in unused regions. See the Cryptojacking Guide.

Hardening and rollout

1. Close old worm paths first: patch remote services, set unique local administrator passwords (Windows LAPS), and block inbound SMB between workstations with host firewall rules. Test the firewall rule in a pilot ring for a week and keep a group policy rollback ready. See the SMB Signing Guide.
2. Control removable media: turn off AutoRun, allow list approved USB devices and block execution from removable drives. See the Removable Media and USB Control Guide.
3. Protect container and build hosts: keep the Docker daemon on its default local Unix socket; where remote access is needed, Docker documents SSH or TLS with client certificate verification (tlsverify). See the Container Security Guide.
4. Shrink publishing token blast radius: replace long lived registry tokens with trusted publishing, require phishing-resistant MFA for maintainers and scope tokens to single packages. See the npm Trusted Publishing and Provenance Guide and the npm Install-Time Security Guide.
5. Prepare a worm response: pre-agree who can isolate segments and revoke tokens at scale, because spread outpaces ticket based approval. See the Supply Chain Compromise Response Playbook.

Where identity fits

The supply chain members are credential harvesters with a propagation module. CISA's September 2025 alert on the npm compromise told organisations to rotate all developer credentials, require phishing-resistant MFA on developer accounts, audit GitHub Apps, OAuth applications, webhooks and secrets, and turn on secret scanning and branch protection. Treat any infected developer workstation or CI runner as a token compromise: inventory every token readable from that environment, revoke and reissue, and review what each token did since infection. The older network worms are identity problems too, since Net Crawler dumps credentials and brute forces accounts to reach the next host. See the npm Tokens Security Guide and the Self Propagating Supply Chain Worms.

Measuring coverage

• Lateral exposure: percentage of workstations that accept inbound SMB from other workstations.
• Local admin uniqueness: percentage of Windows endpoints with a managed, unique local administrator password.
• Token lifetime: median age of package registry and CI publishing tokens, and the share replaced by trusted publishing.
• Time to revoke: minutes from a confirmed infected developer host to revocation of all tokens readable from it.
• Detection coverage: share of the ten behaviour table techniques with a tested detection.

Common failure patterns

• Rebuilding the host but not rotating tokens: supply chain worms have already copied tokens off the machine before cleanup.
• Shared local administrator passwords: one dumped hash opens every machine to admin share spread.
• Exposed management APIs on build and container hosts: the TeamTNT and Carbonato cases both started with Docker APIs reachable without authentication.
• Broad publishing tokens on maintainer laptops: a single token scoped to every package lets the worm infect them all.
• Treating miners as low priority: a miner proves code execution and often arrived with credential theft, as in TeamTNT.

Framework mapping

Practitioner checklist

• Block inbound SMB between workstations and alert on ADMIN$ writes between them.
• Deploy unique managed local administrator passwords on every Windows endpoint.
• Turn off AutoRun and block execution from removable media.
• Keep Docker daemons off the network or behind SSH or mutual TLS.
• Alert on package managers and extension hosts spawning shells or reading credential files.
• Move package publishing to trusted publishing and scope remaining tokens to single packages.
• Alert on event log clearing (1102, 104) and new services (7045).
• Pre-authorise rapid token revocation and segment isolation for worm incidents.

Standards and references

• MITRE ATT&CK: Software
• MITRE ATT&CK: S9008 Shai-Hulud
• MITRE ATT&CK: T1195.001 Compromise Software Dependencies and Development Tools
• MITRE ATT&CK: T1021.002 SMB/Windows Admin Shares
• CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
• Docker: Protect the Docker daemon socket
• NIST: SP 800-53 Rev 5 Security and Privacy Controls
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: Botnets Guide · Mirai and IoT Botnet Families Guide · MITRE ATT&CK T1496 Resource Hijacking · ATT&CK macOS Malware Software Hub · ATT&CK Credential and Active Directory Attack Tools Software Hub