Anatomy Of A Worm

Looking Inside A Self-Replicating Malware Sample

When I first started taking apart real worm samples in my lab, I kept expecting them to behave differently than the academic descriptions said they would. They don't. The theory holds up, but the practical details are messier than any textbook makes them sound. Understanding the anatomy of a Worm matters because most people treat all malware the same way and waste hours chasing the wrong indicator. Every worm I've reversed fits the same skeleton. The loader is usually the smallest piece, and it exists for one reason: getting past whatever sandbox or AV hook was waiting at entry time. The dropper comes next and drops the real payload. Then you have the propagation engine, the persistence mechanism, and the command-and-control layer. Most amateur analysts start at the C2 module because it's the flashiest part. That is the wrong order. Start with the loader and work backward. The loader in a modern worm rarely uses simple obfuscation anymore. I spent three days unpacking a sample from 2023 that layered UPX, manual packing, a custom XOR stub, and a runtime-decryption routine that only decrypted its own second stage when a specific registry key existed. The worm was dormant on my analysis VM because the key was missing. I added the key with a quick PowerShell script, reran the loader, and the entire dissection finished in under twenty minutes. It sounds trivial now, but that kind of environmental gating is designed to waste your time.

The loader and what it actually does

Loaders check for debuggers, virtual machines, and known analysis keywords. They parse command-line arguments to decide whether to run normally or exit silently. Some check for specific CPU features. A few even inspect the MAC address prefix to see if they are running on a known analyst machine. The ones that do this are rare, but they exist, and they cause false negatives in automated scanners all the time. When I extract a loader, I always run it first in a network-isolated VM with API monitoring enabled. The output from that run tells me exactly what strings it pulls, what processes it touches, and whether it drops anything to disk before the main payload executes. Tools like strace on Linux or Process Monitor on Windows cover most of this. You do not need exotic tooling for the first pass.

The dropper and deployment tactics

The dropper is where most worms differentiate themselves. Early worms like Code Red and Nimda used fairly blunt methods. Modern variants use targeted deployment. I found a worm once that dropped its payload through a compromised USB autorun file combined with a WMI event subscription. Both delivery paths were present, and either one alone would have been enough. That redundancy is intentional. It means taking down one infection vector does not stop the worm from spreading. When you are cataloging the dropper section, note the file paths it targets, the permissions it modifies, and any scheduled tasks or startup items it creates. I keep a simple spreadsheet with columns for path, artifact type, and timestamp. It sounds basic, but after your fifth sample in a week, that spreadsheet becomes the only thing keeping the details straight.

Propagation engine specifics

This is the part people usually care about most, and it is also the part most often misunderstood. A worm does not need to scan the entire internet to be dangerous. Efficient worms target specific protocols and services. SMB exploitation is still the standard for Windows environments. SSH brute force and credential reuse dominate Linux spread. I have seen worms that only propagated through a single misconfigured Redis instance and took down an entire production cluster in under forty minutes. The vulnerability choice matters more than the scanning speed. A worm targeting CVE-2021-44228 moved laterally through Log4j endpoints in hours. A worm targeting a forgotten RDP session on an old domain controller moved slower but caused more structural damage because it owned the domain. Speed is overrated. Lateral movement quality determines the real impact.

Persistence mechanisms you should watch for

Worms use the same persistence tricks as other malware, but they tend to stack them faster because they need to survive reboot cycles during active outbreaks. Registry run keys, scheduled tasks, WMI subscriptions, and service modifications are the standard set. More sophisticated samples add boot-level persistence or kernel drivers. I found one variant that installed a custom minifilter driver just to monitor file creation and re-trigger itself if the payload was deleted. Removing the registry keys was not enough. You had to remove the driver first, then the payload, then the drivers file association. The C2 module handles command interpretation, encoding, and beaconing. Most worms use HTTP or DNS tunneling for this. Some use messaging platforms or public CDNs as opaque channels. The encoding scheme is usually simple ROT or base64 with a rotating key embedded in the binary. I have encountered worms that used ICMP packets for low-bandwidth command channels. That is unusual, but it works because most firewalls do not deeply inspect ICMP payloads. When extracting C2 indicators, always record the full URL structure, query parameters, and headers. Many analysts miss the header-based encoding that some worms use to pass instructions without changing the URL at all. One sample I analyzed carried its entire command set in the User-Agent field, rotating between four predefined strings. The beacon interval was sixty seconds. The traffic looked completely normal to anyone scanning logs without looking closely at that header.

Practical dissection workflow

Here is how I approach a new worm sample, step by step, without overcomplicating it. Run file, strings, PE information, and entropy checks. Use tools like pefile, binwalk, or trid to identify embedded files and packers. Check the entropy profile. High entropy in a small section usually means packed or encrypted data. A flat entropy curve across the entire file often indicates strong obfuscation rather than natural packing. Note the import table and any unusual DLL references. Use a snapshot-based VM with monitoring enabled. Run the sample and capture network traffic with Wireshark. Monitor file system changes with Process Monitor. Watch registry modifications. Record process creation and injection events. Do not connect the VM to any production network. This step usually takes between fifteen and forty minutes depending on how aggressive the worm's anti-analysis measures are.

When the sample uses runtime decryption, attach a debugger at the entry point and follow the decryption routine. Write a script to extract the decrypted bytes to disk. This is where most amateurs get stuck because they try to manually trace every decryption loop. Instead, hook the function that returns the decrypted buffer and dump it directly. I use a simple Python script with pykd for WinDbg that captures the buffer contents at a specific memory address and writes them to a file automatically. Map every network connection the worm establishes. Identify the vulnerable service it targets. Check for credential harvesting or password guessing routines. Document the exact exploit method. If the worm uses a known CVE, note the patch status of affected systems. This information is what you need to write detection rules and containment procedures. List every artifact the worm creates. Registry keys, scheduled tasks, startup entries, services, WMI classes, and driver files. Document the exact commands used to create each one. This list becomes your remediation checklist. Skipping any item leaves the worm able to regenerate from a surviving artifact.

Running the sample without network monitoring first. You will miss the C2 traffic entirely and spend hours trying to reconstruct it from memory dumps. Always capture the network layer before touching anything else. Assuming the first file you find is the payload. Many worms use multi-stage delivery where the initial executable is mostly filler. The real code lives in a subsequent drop. Follow the execution chain until you reach the final stage. Neglecting to check for environmental triggers. Some worms remain dormant until they detect a specific hostname, IP range, or locale. If your sample appears inert, try changing the VM configuration to match common target environments. A quick hostname change to something like WORKSTATION-01 or adjusting the system locale to English US resolves the issue more often than you might expect.

Limitations of this approach

Static analysis alone cannot reveal runtime behavior. Dynamic analysis requires careful isolation. Environmental triggers can cause false readings. Some worms detect analysis tools and refuse to propagate or reveal their C2 during observation. When that happens, you may need to modify the sample or simulate the required environment more thoroughly. There is no shortcut around that. I also recommend pairing manual analysis with automated frameworks like Cuckoo Sandbox or Any.Run when you need to process large volumes of samples. Manual reversal is accurate but slow. Automation scales but misses nuance. Use both, and trust the manual findings when the automated reports conflict.

What to take away

Worms follow a predictable structure even when their implementation varies. The loader, dropper, propagation engine, persistence layer, and C2 module are consistent across almost every sample. Understanding each piece separately makes the whole thing easier to dismantle. The real value comes from recognizing the patterns quickly so you can focus on what makes each variant different instead of reinventing the wheel for every new sample.