Which threat actors have used self-replicating worms?

What kinds of actors have a history of using worms?

Self-replicating worms are not confined to one type of adversary. They have been used by criminal crews seeking scale and disruption, hacktivists aiming for visibility or defacement, and state-linked groups pursuing persistence, espionage, or destructive access. The important analytical point is that the worm’s propagation mechanics usually tell you more than the actor label.

Because worms spread automatically, the same campaign style can support different objectives. A criminal crew may use it to amplify monetisation or extortion, while a state-linked operation may use the same property to move quickly across connected environments. That means attribution should be built from infrastructure, payload, target selection, and follow-on actions, not from the mere fact that a worm was observed.

For a broader taxonomy of adversaries and naming conventions, Threat Actor Groups Guide is useful when you are translating campaign reporting into a defensible actor assessment.

Why worm campaigns are hard to attribute cleanly

Worms often propagate through whatever weakness is easiest to automate, such as an exposed service, a weak credential path, a supply-chain trust relationship, or an unpatched vulnerability. That makes them operationally flexible and attribution-poor. The same propagation pattern can be reused by multiple actors with very different motivations.

What tends to persist across cases is the tradecraft, not the brand of the actor. Watch for mass scanning, exploitation at scale, lateral movement after first access, and secondary payload delivery. If those behaviours are present, the worm is doing the strategic work for the operator, regardless of whether the operator is financially motivated, ideological, or state-aligned.

When you need a practical malware taxonomy for separating a worm from loaders, trojans, botnets, and other families, Malware Guide helps anchor the analysis in behaviour rather than label drift.

What defenders should look at first

The first question is not “who did it?” but “how did it spread, and what did it do next?” A worm that spreads through a package registry, a cloud credential store, or an enterprise host has very different containment and eradication implications. The propagation method determines whether the priority is patching, secret rotation, account suspension, segmentation, or code repository review.

Defenders should also separate initial replication from post-compromise action. Some worms are primarily propagation vehicles; others are also loaders for theft, botnet enrolment, or destructive payloads. If the worm touched credentials, tokens, or service accounts, the response should treat those as potentially exposed even if there is no evidence yet of downstream abuse.

Campaigns that combine worm behaviour with credential abuse are a recurring pattern in modern intrusion reporting, and The State of NHI & AI Agent Breach Report 2026 is a useful reference point for understanding how stolen secrets and lateral movement often accompany automated spread.

Risk and Threat Considerations

Worms are dangerous because replication changes the blast radius faster than most human response workflows can keep up. Once the initial foothold is automating spread, the attacker does not need to win every next step manually, so exposure can expand before detection, containment, or patching catches up.

Failure mechanism: The worm abuses a repeatable trust or exploit path, then uses that path to copy itself, discover adjacent targets, and sometimes deliver a second-stage payload. If the underlying weakness is shared across many hosts or tenants, the campaign can scale much faster than a normal intrusion.

Impact: The result can be broad compromise, service disruption, credential exposure, or destructive execution across multiple systems, often before defenders have a complete asset or vulnerability picture.

For worm campaigns that move through software distribution or package ecosystems, ChainDrop npm worm 2026 illustrates how self-propagation can be paired with secret theft and follow-on compromise.

Practitioner Guidance

What to prioritise: Treat the propagation route as the primary containment problem. If the worm used a vulnerable service, patching and exposure reduction come first; if it used stolen secrets or tokens, rotation and revocation come first; if it spread through software publishing or CI/CD, suspend publishing paths and inspect recent releases before assuming the infection is gone.

What to verify: Confirm whether the worm only replicated or also executed a distinct payload. That distinction changes whether you are dealing with a cleanliness problem, an access problem, or a broader incident involving data theft, persistence, or lateral movement.

Practitioner takeaway: In worm incidents, attribution is usually secondary to propagation analysis. The fastest path to containment is to identify the spread mechanism, bound it, and then assess whether the worm exposed credentials, sessions, or other reusable access material.

Related resources from NHI Mgmt Group

• What does AI model abuse reveal about the current NHI threat surface?
• What are effective practices for operationalizing NHI threat detection?
• Why do secrets stay dangerous even when they are no longer actively used?
• How should security teams harden macOS endpoints against trojanized admin tools used by threat actors?