Computer Worms Guide: Self-Propagating Malware and How to Contain It

A computer worm is malware that copies itself from one system to the next without anyone opening a file or clicking a link. Unlike a virus, which needs a host file and a user action, a worm finds new victims on its own, usually through an unpatched network service, reused credentials or, more recently, stolen software publishing tokens. That self-propagation is why a single infection can become an organisation-wide outage in under an hour. This guide explains how worms work, what the major cases from Morris in 1988 to the Shai-Hulud npm worm of 2025 teach defenders, and which controls actually stop the spread. It is written for security engineers, infrastructure teams and SOC analysts who need to contain worms, not write them.

Key takeaways

• Propagation is the defining feature. A worm's payload can be ransomware, a wiper or a credential stealer; what makes it a worm is that it spreads automatically, so containment speed matters more than payload analysis.
• Three paths dominate. Exploiting remote services (MITRE ATT&CK T1210), reusing harvested credentials over admin shares (T1021.002 with T1078), and abusing publishing or automation tokens in the software supply chain (T1195.002).
• SMBv1 and TCP 445 remain the classic blast radius. WannaCry exploited a flaw Microsoft had patched two months earlier in MS17-010; disabling SMBv1 and blocking 445 between workstations removes a whole class of worm.
• Patching alone does not stop credential-driven worms. NotPetya kept spreading through fully patched hosts by reusing administrator credentials, so tiered admin, unique local admin passwords and segmentation are equally important.
• Supply chain worms target identities, not hosts. Shai-Hulud spread by stealing npm and GitHub tokens from developer machines and CI runners and republishing every package those tokens could reach, a pattern repeated by the Tensorlake npm worm in 2026.

What it is

In plain terms, a worm is a program that, once running on one computer, looks for other computers it can reach and installs a copy of itself there, which then does the same. No user has to do anything for each hop. The term goes back to the early days of networked computing, and the first worm to cause widespread disruption on the Internet was the Morris worm. According to the FBI, it was released on 2 November 1988 and infected an estimated 6,000 of the roughly 60,000 computers then connected within 24 hours, using flaws in the sendmail email software and the finger service. Its author became the first person convicted under the US Computer Fraud and Abuse Act.

For practitioners, the useful distinction is between the propagation mechanism and the payload:

The categories overlap. WannaCry was ransomware with a worm component; NotPetya behaved like ransomware but functioned as a destructive wiper. See the Malware Guide for the wider taxonomy and the Trojans Guide for the non-replicating case.

How it works

Every worm runs the same loop: gain a foothold, discover reachable targets, move to them, execute, repeat. The defensive value lies in knowing which step each control breaks.

1. Foothold: an exposed vulnerable service, a phishing payload, an infected removable drive (T1091) or a poisoned software package (T1195.002).
2. Discovery: scanning local subnets and, for some worms, random Internet ranges for a listening service such as SMB on TCP 445; or, for supply chain worms, listing every package a stolen token is allowed to publish.
3. Propagation: exploiting the remote service (T1210), logging in with harvested or reused credentials over SMB admin shares (T1021.002, T1078), or publishing an infected version of another package.
4. Transfer and execution: copying the worm to the new host (Lateral Tool Transfer, T1570) and starting it, often through a remote service or scheduled task.
5. Payload: encryption, wiping, credential theft or simply resource exhaustion, as with Morris.

Three generations of propagation

The NotPetya initial vector (a compromised update to Ukrainian accounting software) and its use of credential harvesting are drawn from widely reported government analysis rather than a source re-read for this page.

Why it matters

• Speed outruns human response: a worm moves at machine speed, so an organisation with a flat network can lose most of its estate before a ticket is triaged. Containment has to be designed in beforehand.
• Collateral damage is the norm: NotPetya's primary targets were Ukrainian financial, energy and government organisations, but it spread indiscriminately into multinational businesses.
• Basic hygiene decides the outcome: the UK National Audit Office found WannaCry affected at least 81 of 236 NHS trusts in England plus 603 primary care and other NHS organisations, with more than 19,000 appointments estimated cancelled, and concluded that managing internet-facing firewalls alone would have protected organisations. NHS Digital had issued critical patching alerts in March and April 2017.
• Identities are now the network: in software supply chains the "hosts" a worm hops between are packages and repositories, and the propagation medium is a token. The Shai-Hulud first wave took npm tokens, GitHub tokens and cloud keys from machines that installed an infected package, and pushed workflows that sent repository secrets to an external webhook. Later waves and copycats, such as the second Shai-Hulud wave, followed the same model.

Where identity fits

Credential reuse is the propagation path that patching does not close. A shared local administrator password, a domain admin logging on to workstations, or a long-lived publishing token on a laptop each gives a worm a ready-made route. Unique per-host local admin passwords (Windows LAPS), never using tier 0 accounts on workstations, and replacing long-lived npm tokens with short-lived OIDC trusted publishing remove those routes. See the Lateral Movement Guide, the Credential Dumping Guide and the npm Tokens Security Guide.

How worms are contained

Containment works in rings: remove the exploitable service, stop credentials being reusable, then limit what can talk to what.

1. Audit SMBv1 before removing it. Microsoft documents server-side SMBv1 auditing; each SMBv1 connection attempt is logged as event ID 3000 in the Microsoft-Windows-SMBServer/Audit log. Run it long enough to catch monthly jobs and legacy devices.
2. Disable SMBv1 in rings. It is not installed by default on Windows 11, Windows Server 2019 and later, or Windows 10 1709 and later (except Home and Pro). Elsewhere, Microsoft describes a Group Policy registry preference setting SMB1 to 0 under HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters. Pilot on a small ring, confirm SMBv2/v3 and SYSVOL still work, then widen. Rollback is re-enabling the feature on the affected hosts while the dependent device is replaced.
3. Patch exposed and lateral services first. Prioritise KEV-listed flaws in SMB, RDP and remote management services. See the Patch Management Guide.
4. Block workstation-to-workstation SMB and RDP. Use host firewall rules so TCP 445 and 3389 are reachable only from management hosts and file servers. Block 445 inbound and outbound at the Internet edge. See the Network Segmentation Guide and the SMB Signing Guide.
5. Apply egress controls. Deny-by-default outbound from servers and CI runners; CISA's Shai-Hulud alert specifically advised blocking webhook.site and reviewing firewall logs for suspicious destinations.
6. Prepare a kill switch of your own. Pre-approve emergency network isolation (EDR host isolation, core switch ACLs) so the SOC can act without a change board. Test it in an exercise.

Detection signals and metrics

Useful KPIs: percentage of Windows hosts with SMBv1 disabled; median time to patch KEV-listed remote service flaws; percentage of workstations that cannot reach peers on 445; share of hosts with unique local admin passwords; share of packages published via trusted publishing instead of long-lived tokens; time from detection to host isolation in exercises. See the Endpoint Telemetry Guide.

Common misconceptions

• "Worms are a 2000s problem": WannaCry and NotPetya were 2017, and npm saw several self-propagating worms in 2025 and 2026, including CanisterSprawl.
• "We patched, so we are safe": credential-driven propagation needs no vulnerability. NotPetya proved that patched hosts fall if admin credentials are shared.
• "Antivirus will catch it": signature engines struggle at worm speed and a supply chain worm runs as a legitimate install script. Behavioural EDR plus network containment matters more.
• "The firewall protects the inside": a perimeter firewall does nothing once one internal host is infected on a flat network.
• "Rotating the obvious token is enough": after a supply chain worm, rotate every credential the infected install could reach: npm, GitHub, cloud, SSH and CI secrets.

Related concepts

Related reading: Botnets Guide, Wiper Malware Guide, Ransomware Prevention Guide, Removable Media and USB Control Guide and Software Supply Chain Security Guide.

Practitioner checklist

• Enable SMBv1 auditing, review event ID 3000 for at least a month, then disable SMBv1 in pilot rings.
• Block TCP 445 at the Internet edge and between workstations; allow it only to file servers and domain controllers.
• Track KEV-listed remote service vulnerabilities, including CVE-2017-0144, with a patch deadline measured in days.
• Deploy unique local administrator passwords and stop privileged domain accounts logging on to workstations.
• Pre-authorise SOC host isolation and network kill switches, and rehearse them.
• Alert on fan-out connections to 445 or 3389 and on one account authenticating to many hosts in minutes.
• Move package publishing to trusted publishing with short-lived OIDC credentials and require phishing-resistant MFA for maintainers.
• Disable dependency install scripts in CI where not needed, pin versions and apply deny-by-default egress on runners.
• Keep an offline, tested backup so a worm-borne wiper or ransomware is recoverable.

Standards and references

• CISA: Widespread Supply Chain Compromise Impacting npm Ecosystem
• Microsoft Learn: How to detect, enable and disable SMBv1, SMBv2 and SMBv3 in Windows
• Microsoft: Security Bulletin MS17-010
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE ATT&CK: Exploitation of Remote Services
• National Audit Office: Investigation: WannaCry cyber attack and the NHS
• UK Government: Foreign Office Minister condemns Russia for NotPetya attacks
• FBI: Morris Worm

Related NHI Mgmt Group resources: Malware Guide · Lateral Movement Guide · Network Segmentation Guide · npm Tokens Security Guide · Keyloggers Guide