Last Friday — 13 July — a worm called Code Red appeared in the wild, exploiting the IIS .ida vulnerability I wrote about two weeks ago. By Saturday morning it had compromised an estimated 70,000 hosts. By Sunday, several hundred thousand. By this morning, on the published estimates, well over 350,000.
This is the IIS-targeted worm I have been predicting. The propagation is faster than I expected.
What Code Red does
The worm exploits the .ida buffer overflow with a single HTTP request. The exploit gives it code execution as the IUSR user. It then:
- Checks the system date. If the date is between the 1st and the 19th of any month, it scans for new victims.
- If the date is between the 20th and the 27th, it stops scanning and instead sends a flood of HTTP requests to www.whitehouse.gov.
- If the date is the 28th or later, it sleeps until the next month.
The scanning is aggressive. Each compromised host scans 100 random IPs per second, looking for IIS servers vulnerable to the same bug. The propagation rate is high enough to saturate the vulnerable population in a few days.
Notably, Code Red is memory-resident only. It does not write itself to disk. A reboot of the affected host removes the worm — but if the underlying IIS vulnerability is unpatched, the host will be re-infected within minutes by another scanning host.
The defacement
The worm modifies the default web page on infected English-language IIS servers to read:
HELLO! Welcome to http://www.worm.com! Hacked By Chinese!
The defacement gives the worm its name (the original analyst named it after a Mountain Dew variant called Code Red).
What I have observed
My honeypot range has been hit substantially. Specifically:
- Roughly 4,000 distinct sources have hit my range with the
.idaexploit pattern in three days. - The Honeyd persona that emulates a Linux web server (which is therefore not vulnerable) has been hit by the worm and has, of course, not been compromised.
- The Snort sensor has captured the full HTTP request from each attempt; the requests are essentially identical (same shellcode, same payload).
- The aggregate scan rate from sources targeting my range is the highest I have ever seen.
The internet's background scan rate has, on the available evidence, roughly tripled this weekend.
What is happening more broadly
From the Honeynet Project reports and operator chatter:
- US-CERT has issued an advisory recommending immediate patching.
- Major US ISPs are reporting noticeable congestion from worm scan traffic.
- The Whitehouse.gov DDoS scheduled for the 20th is being prepared for; the site will likely change its IP to evade.
- Many operators are experiencing collateral disruption — the scanning load is hitting other services, even those not vulnerable to the worm.
The worm itself is a single specific attack. The aggregate effect on the internet's operation is much larger.
What operators should do
For anyone running IIS:
Patch immediately. MS01-033 closes the vulnerability. Your server is being scanned every few minutes.
Reboot if you suspect compromise. Code Red is memory-resident; a reboot removes it. After the reboot, patch immediately — otherwise re-infection will happen within minutes.
Disable the indexing service if you do not need it. This eliminates the attack surface entirely.
Review your firewall logs for the .ida pattern. Any external request matching the pattern is an exploitation attempt; the source IP is, almost certainly, a compromised host.
For anyone running other web platforms:
The collateral disruption is real. Even if your server is not vulnerable, the scan traffic is consuming bandwidth and capacity. Plan accordingly.
For everyone:
Watch for the 20 July DDoS. Whitehouse.gov will be the target; the collateral effect on adjacent infrastructure is unclear.
A small reflection
This is the first auto-propagating, internet-scale worm of the modern era. Morris worm in 1988 was the previous comparable event; the internet was much smaller then. Code Red's scale and propagation speed are without precedent.
My calibration discipline marks prediction 1 ("auto-propagating Windows worm by year-end") as resolved on the affirmative side. The 85% probability was reasonable; the timing was earlier than my central estimate; the scale is larger than I had implicitly assumed.
More as the worm develops. The next post will be a deeper analysis once the dust settles.