Conficker: The 2008 Worm That Infected Millions of Computers
Conficker spread through an unpatched Windows flaw and weak passwords, building a botnet of millions. Here is how it worked and why patching still matters.
In late 2008 a computer worm called Conficker began spreading across the internet at a speed that alarmed security researchers worldwide. It infected millions of machines, including systems in governments, hospitals and businesses, and it was hard to remove. The remarkable part is that the main hole it used had already been patched. Conficker succeeded because so many computers had not been updated.
The flaw it exploited
Conficker first appeared in November 2008. It used a vulnerability in the Windows Server service, fixed by Microsoft in security bulletin MS08-067. Microsoft had taken the unusual step of releasing that patch outside its regular monthly schedule in October 2008, because the flaw was serious enough to allow remote code execution without a user doing anything.
A machine that was missing the patch and reachable over the network could be taken over by receiving a specially crafted request. That made Conficker a true worm: it found new victims on its own, without anyone clicking a link or opening a file.
More than one way to spread
Later versions added further methods, which is one reason the worm was so persistent:
- Network shares and weak passwords. It tried a list of common passwords against administrator accounts on shared drives.
- Removable drives. It used USB sticks and the Windows autorun feature to jump between computers that were not connected to the same network.
- Self-protection. It tried to block access to security vendor websites and to disable Windows updates and security tools, which made cleaning an infected machine harder.
The botnet and the domain trick
Infected machines were designed to contact web addresses to receive instructions. To stop defenders from simply blocking a few fixed servers, Conficker generated large lists of domain names every day using an algorithm. Only the authors knew which ones would be used. Defenders had to predict, register or block hundreds of domains a day, and in later versions tens of thousands.
In response, industry and academic groups formed what became known as the Conficker Working Group, and Microsoft announced a reward of 250,000 US dollars for information leading to the arrest of those responsible. Estimates of the number of infected machines varied widely and ran into the millions. Because no precise count was ever established, treat any single number with caution.
The April 1st scare
A later variant was set to change its behaviour on 1 April 2009, which produced a wave of media coverage. In the end, nothing dramatic happened that day. But the episode showed how a large, leaderless botnet could worry governments simply by existing, with the possibility that it could be turned into a tool for spam, theft or attacks.
Why Conficker mattered
Conficker is often cited as a textbook example of what patch lag costs. The fix was available weeks before the outbreak. Organisations that applied it were safe from the main infection route, while those that put patching off, or that could not test updates quickly, were exposed. It also showed the value of three habits:
- Strong, unique passwords on any account that can reach shared resources.
- Disabling features you do not use, such as autorun on removable media.
- Knowing which machines are on your network, so none are forgotten.
Forgotten machines are the quiet theme of the whole episode. Old servers in a cupboard, test systems nobody owned and laptops that rarely connected were often the ones that stayed infected and kept the worm alive long after the headlines faded.
How defenders fought back
Conficker was unusual because the response was a joint effort between rivals. Antivirus vendors, domain registries, internet service providers and researchers shared information about the daily domain lists. Registries agreed to block or pre-register the domains the worm was expected to contact, which cut off the infected machines from their instructions in many cases.
That cooperation worked well enough to contain the worm's ability to do damage, but cleaning up the infected machines took years because each one had to be fixed by its owner. Even long after the outbreak, researchers continued to see traffic from infected computers, which shows how long an unpatched system can linger on a network once it has been compromised.
The gap between a fix being released and being installed is a challenge that every software ecosystem, including WordPress and its plugins, still faces today.
The practical lesson for site owners
Websites have the same problem in a different form. Content management systems, themes and plugins publish fixes, and attackers read those same release notes to find sites that have not applied them yet. The safest habit is to apply security updates promptly, use a unique password on every account and remove software you no longer need.
If you run WordPress, our WordPress hosting gives you a Plesk-based environment to manage updates from, and our knowledge base explains how to set it up. If you are not sure whether your current site is fully updated, that is the first thing to check this week.
