The Code Red worm spread by exploiting a known vulnerability in Microsoft’s IIS web server software, scanning random internet addresses for unpatched machines and infecting them automatically, with no human interaction required. On July 19, 2001, it infected more than 250,000 systems in just nine hours.
The Vulnerability Behind the Outbreak
Code Red targeted a flaw in a component called idq.dll, which was part of Microsoft’s Index Server and Indexing Service running on IIS web servers (versions up to and including 6.0 beta). The flaw was a buffer overflow: the component accepted incoming data without checking its length, so an attacker could send a specially crafted, oversized request that overwrote parts of the server’s memory. This let the worm inject its own instructions directly into the running program and take control of the machine remotely.
Microsoft had actually released a patch for this vulnerability a full month before the worm appeared. The security bulletin (MS01-033) was published in June 2001. But tens of thousands of servers hadn’t been updated, giving Code Red a massive pool of targets. The worm was, in effect, punishing slow patching at internet scale.
How It Found New Targets
Once Code Red infected a server, it immediately began hunting for more victims. The worm spawned 100 simultaneous threads on the compromised machine. Ninety-nine of those threads had a single job: generate random IP addresses and send connection requests to port 80, the standard port for web traffic. Any machine listening on that port and running an unpatched version of IIS could be infected in seconds, using the same buffer overflow trick that got the worm in the door in the first place.
The first version of the worm had a critical flaw of its own. Its random number generator used the same seed on every infected machine, which meant every copy of the worm produced the identical list of IP addresses to scan. Infected servers kept re-discovering and re-infecting each other instead of spreading efficiently. Later variants (commonly called CRv2a and CRv2b) fixed this by generating truly random address lists, which allowed them to find new vulnerable servers much faster and ultimately infect far more machines.
Living Entirely in Memory
Code Red never wrote itself to the hard drive. It existed only in the server’s RAM, which made it unusual for the time. This meant that rebooting an infected machine would wipe the worm out completely. But there was a catch: rebooting didn’t fix the underlying vulnerability. Because newly infected machines scanned the same IP addresses in the same order (at least in the first variant), a rebooted server that still lacked the patch would almost certainly be reinfected within minutes. The only real fix was installing Microsoft’s security update.
The Three-Phase Monthly Cycle
Code Red’s behavior followed a rigid calendar built into its code, repeating every month:
- Days 1 through 19: Propagation. The worm focused entirely on spreading. Each infected server scanned random IP addresses and attempted to compromise every vulnerable IIS server it found. The first version also defaced infected websites, replacing the homepage with the message “HELLO! Welcome to http://www.worm.com! Hacked by Chinese!” Later variants dropped the defacement, which actually made infections harder for administrators to notice.
- Days 20 through 27: Attack. All infected servers simultaneously flooded a single target with massive amounts of traffic: the White House website. This was a coordinated distributed denial-of-service (DDoS) attack designed to overwhelm www.whitehouse.gov and knock it offline.
- Days 28 through end of month: Dormancy. The worm went quiet, sitting idle in memory until the first of the next month, when the cycle started over.
Why the White House Attack Failed
The DDoS phase targeted a hardcoded IP address rather than the domain name whitehouse.gov. The worm’s code also checked whether port 80 at that specific IP address was active before launching the flood. These two design choices made the attack trivially easy to defeat. The White House simply moved its website to a different IP address, and the worm’s entire attack phase became harmless, sending traffic to an address that no longer hosted anything.
How the Variants Differed
The original Code Red (v1) spread inefficiently because of its identical random-number seed and announced itself loudly through website defacement. The later variants were stealthier and more effective. They generated unique random IP address lists on each infected machine, avoided defacing websites, and spread to a much larger number of servers as a result. A separate worm called Code Red II, which appeared shortly after, exploited the same IIS vulnerability but carried a different payload: it installed a backdoor on infected machines, giving attackers persistent remote access even after a reboot. Code Red II was a more serious long-term threat because it wrote files to disk rather than living solely in memory.
The Scale of the Damage
The U.S. Government Accountability Office estimated Code Red caused more than $2.4 billion in economic losses globally. That figure included the cost of patching systems, lost productivity, bandwidth consumed by the worm’s scanning traffic, and the IT labor required to clean up infections. The worm’s scanning alone generated an enormous amount of junk traffic across the internet, as hundreds of thousands of servers simultaneously blasted connection requests at random addresses, many of which didn’t even exist. Network operators worldwide saw a measurable spike in unsolicited traffic on port 80 during the outbreak.
Code Red became one of the defining cybersecurity events of the early 2000s, not because its code was particularly sophisticated, but because it demonstrated how devastating a simple, automated exploit could be when aimed at a widely deployed product that many administrators had failed to patch. The vulnerability had a fix. The fix had been available for weeks. The worm spread anyway.