Mydoom connects three questions that are easy to confuse: what persuaded someone to run a file, how the worm spread, and what access remained afterward. A response that addresses only the first visible attachment can miss the larger compromise.
This is a retrospective on the 2004 worm family. Historical messages and system changes are discussed as evidence from that period, not as a present-day detection checklist.
Understand the family and its backdoor
Yenra’s original January 26, 2004 coverage described technical-looking email and attachments associated with the emerging outbreak. Microsoft’s later Mydoom family analysis describes mass mailing, peer-to-peer spread in some variants, and backdoor functionality that could allow further malicious software to be delivered. Some variants also launched denial-of-service attacks. Keep those variant qualifications; not every behavior belongs to every specimen.
The backdoor is central to the recovery question. Stopping one mailing process does not by itself establish what other access occurred. A name such as “Mydoom” also does not tell an investigator every change on a particular machine.
A technical-looking message can create false authority
A message need not offer a prize to persuade a reader. It can claim that a document was converted, delivery failed or an attachment contains required details. The trap is the requested action: running unfamiliar content because a message appears to be part of a technical process.
Modern services and file types differ from those in 2004. The transferable observation is the shift in task: “read this” becomes “run this.” Teaching that distinction is more durable than memorizing an old list of subject lines.
Separate delivery, execution, spread and access
- Delivery: a suspicious message arrived. That fact alone does not prove its attachment ran.
- Execution: the file was launched or another mechanism executed it. Investigate what privileges and data were available.
- Spread: other people or systems may have received related content. Determine the affected population from evidence.
- Continued access: a backdoor or other change may permit activity beyond the original program’s visible behavior.
These are investigation questions, not a claim that every incident passes through all four stages. Record what is known and what is still uncertain. “Blocked before execution” and “removed after running for an unknown period” support different conclusions.
The historical Doomjuice case makes the continued-access issue concrete: a later worm used an opening left by Mydoom.A. The dependency matters more to a general reader than a list of old registry entries.
Ask what would establish recovery
For a current event, use the hub’s containment guidance and involve the designated responder for workplace incidents or sensitive-data exposure. Do not delete evidence or run old removal instructions copied from a historical advisory.
Organize the response around questions: What actually executed? Which accounts and shared resources were accessible? Did the device send anything? Is there evidence of further access? Who can decide whether supported remediation is sufficient or a rebuild is appropriate? A clean scan is one result within that assessment.
Keep the action log separate from conclusions. “The tool quarantined a file at 10:15” records an event. “The device is trustworthy again” requires an explanation of the additional checks and remaining uncertainty.
Discuss a report without blaming the reporter
Compare this route with Sasser’s network-service exposure. The contrast helps explain why mail filtering, patching, account protection and network boundaries address different opportunities.