Nimda: The 2001 Worm That Attacked Through Five Doors at Once

On 18 September 2001, one week after the attacks of 11 September, a new computer worm began to spread across the internet. It was named Nimda, which is the word admin spelled backwards, a detail found in the code. It did not rely on a single weakness. It attacked through several routes at the same time, and that made it harder to stop than any worm before it.

The context

The timing produced speculation. Some commentators wondered whether the worm was connected to terrorism, given its date. No evidence of such a link was ever established, and the author of Nimda was never publicly identified. It is best viewed as a coincidence of timing. What is well documented is how rapidly the worm spread: security firms reported that it was among the most widespread pieces of malware on the internet within hours.

The five routes in

Nimda is often called a blended threat because it combined several techniques. Each one would have been a serious problem alone.

1. Email. The worm sent itself as an attachment named readme.exe, in messages with varying content, to addresses it found on the infected computer. In some email clients, particular flaws in how mail was displayed allowed the attachment to run when the message was merely previewed.
2. Web server vulnerabilities. It scanned for Microsoft IIS servers with known flaws that had been patched months earlier, and attacked them directly. Some of those servers already had backdoors installed by the Code Red II worm, which Nimda reused.
3. Network shares. It copied itself onto shared folders on local networks, spreading inside organisations whose perimeter was secure.
4. Infected web pages. On compromised servers, it added a small piece of JavaScript to web pages, so that visitors using a vulnerable version of Internet Explorer could be infected just by browsing.
5. Existing backdoors. It looked for machines already compromised by earlier worms.

Why it was so disruptive

Defenders had to deal with all these routes at once. Blocking email attachments stopped one path, but not the others. Patching web servers closed another. A company that had cleaned every server could be reinfected through a laptop plugged into the internal network. The worm also generated heavy network traffic as it scanned for targets, which slowed networks and, in many places, made it hard to download the very patches needed to protect against it.

It also changed web servers in lasting ways. Infected servers were modified so that visitors were exposed to the worm, which meant that a company's own website could become a source of infection for its customers.

One consequence deserves emphasis: trust. Because Nimda altered web pages, visitors to infected sites could be attacked by what looked like a legitimate company's content. Some organisations learned that their site had been compromised only when customers or partners told them. That experience led many to monitor their own pages for unexpected changes, a practice now common under the name file integrity monitoring.

The cleanup

Cleaning up was laborious. Because the worm modified files and left backdoors, simply deleting the infected programs was not enough. Security advisers recommended rebuilding affected servers from clean media where possible, since it was difficult to be sure that every change had been reversed. For many organisations, this meant days of work.

What defenders learned

• Layered defences matter. Perimeter protection alone fails if one machine inside is infected.
• Servers should be hardened, with unused services switched off.
• Patches should be installed even for flaws that seem old.
• An infected server may need to be rebuilt, not just cleaned.

The wider shift

Nimda, together with Code Red a few months earlier, was a turning point for corporate security. Together they showed that the internet-facing parts of an organisation, web servers above all, needed the same care as its internal networks. Both worms contributed to the decision by Microsoft to focus on security in its software, announced in the Trustworthy Computing memo of January 2002, and to the move towards regular, automated patch releases.

The lesson for site owners today

Security is rarely about a single hole. Attackers look for whichever route happens to be open. If your site is compromised, the way in may not be the way they come back. Think of your website as having several layers: the server software, the CMS, the plugins, the accounts that can log in, and the other sites on the same server. Weakness in any of them can be enough.

1. Update everything, not just the main application.
2. Keep separate sites separate, so one compromise does not spread to the others.
3. After a hack, change all passwords and look for hidden users, files and scheduled tasks.
4. Keep clean backups, so you can restore from a known good copy.

If you are unsure where to start, you can contact the team.

Staying separate

A VPS gives each project its own isolated environment, which limits how far a compromise can spread. On a shared plan, Plesk keeps subscriptions apart. If you need help judging what to do after an incident, get in touch, and see our security page for prevention tips.