Skip to main content
ZombieMutex

30 results · ↑ ↓ navigate · Enter open · Esc close

All writing
November 7, 20262 min read

Melissa: a document macro virus and an email outage

Melissa demonstrates why I include document and user-interaction boundaries in propagation analysis, not only remotely exploitable network services. In March 1999, a Microsoft Word document with a malicious macro relied on someone o

By

Share

Send this article to someone or copy its link.

Suggest a correction

Reader tools

2 min remaining · 0% of article

Select a passage and choose Highlight selection to save it. Local browser storage only. Shift+F toggles focus.

Case file / Retro schematic

Reported sequence and proposed controls

Explore a simplified sequence from the cited research, then switch to defensive checkpoints. These are explanatory diagrams, not live samples, executed code, or original incident telemetry.

Reported sequence

  1. Word attachment
  2. Macro enabled
  3. Document infection
  4. Outlook address-book mail

Proposed defensive checks

  1. Restrict macros
  2. Screen attachments
  3. Bound automatic mail sending
  4. Monitor mail spikes

Simplified sequence based on cited research; proposed defenses are not evidence that the incident was prevented.

Melissa demonstrates why I include document and user-interaction boundaries in propagation analysis, not only remotely exploitable network services. In March 1999, a Microsoft Word document with a malicious macro relied on someone opening it. The code infected Word documents and used Outlook contact lists to send more malicious messages.

The exact trust boundary

The first step was a document opening with macros enabled. That action allowed code embedded in content to execute with the user's application privileges. Microsoft and the FBI describe the ensuing mail activity as automated forwarding to the first 50 contacts in the address book.

Because the messages appeared to come from known people, this was also an abuse of social trust. The software's automation API made one account able to generate enough mail to affect other people and infrastructure.

Why the classification is interesting

The term virus refers to code that infects host files or programs. The term worm describes self-propagating software. Melissa is commonly called a macro virus; Microsoft's threat encyclopedia also calls it a macro worm, reflecting the combination of document infection and email-based spread. Those labels describe different dimensions of what it did.

For comparison, WannaCry propagated by exploiting vulnerable network services, whereas Melissa required a user action to run the infected document in the common case.

What survived as an engineering lesson

  • Treat documents and email attachments as untrusted data, even when sent by familiar contacts.
  • Disable unneeded macro execution and use protected document-viewing paths.
  • Rate-limit bulk actions and monitor anomalous mail patterns; one endpoint shouldn't get unlimited sending authority.
  • Include email infrastructure in incident availability planning. A malware event may overload an otherwise healthy communication service.

These controls operate at different layers. A document policy restricts execution; service throttling limits amplification; mailbox monitoring detects downstream behavior.

Sources

Scope: Historical analysis based on official descriptions; no macro or infected document executed.

Related technical notes with overlapping topics.

Discuss a passage

Select a paragraph above, copy it with its article link, then paste into the discussion. Don't include private data.

Jump to discussion ↓

Public conversation / GitHub Discussions

Discuss this article

Read and reply using GitHub Discussions. A GitHub account is needed to post. Comments are public and subject to GitHub moderation.

For privacy, the external giscus widget does not load until you choose to open it. Opening it connects your browser to giscus and GitHub. Do not post credentials or private project data.