Blaster: The Worm That Attacked Windows Update While Telling Bill Gates to Fix His Software

2026-08-09-14 min read

#blaster#msblast#rpc-dcom#cve-2003-0352#windows#worm#welchia#automatic-updates#xp-sp2#windowsupdate

On August 11, 2003, a worm called Blaster (also known as MSBlast or Lovsan) began spreading across the internet by exploiting a buffer overflow in Windows' RPC DCOM service. Within 24 hours it had infected hundreds of thousands of machines. The worm forced infected computers to continuously reboot, embedded the message "billy gates why do you make this possible. Stop making money and fix your software!!" in its code, and launched a DDoS attack against windowsupdate.com - the very service users needed to download the patch that would protect them from Blaster.

The Blaster outbreak in August 2003 was part of a concentrated wave of high-profile worms that summer. SQL Slammer had arrived in January. By August, Blaster was followed within days by the Sobig.F email worm. Security researchers described August 2003 as the worst month for internet security in history to that point. The combination of a patch that had been available for 26 days before the outbreak, a vulnerability that affected virtually every Windows machine on the internet, and an attack that disrupted the patching mechanism itself made Blaster a crystallizing event in the argument for automatic security updates.

The Vulnerability: RPC DCOM

Blaster exploited CVE-2003-0352, a stack buffer overflow in the Distributed Component Object Model (DCOM) interface of Windows' Remote Procedure Call (RPC) service. Microsoft had released a patch (MS03-026) on July 16, 2003 - 26 days before Blaster's release. The vulnerability affected Windows NT 4.0, 2000, XP, and Server 2003. Since RPC was a core Windows service enabled by default, essentially every unpatched Windows machine on the internet was vulnerable.

The overflow was in the handling of DCOM object activation requests. An attacker could send a specially crafted request to TCP port 135 (RPC endpoint mapper) or ports 139 and 445, triggering the overflow and gaining SYSTEM-level code execution with no authentication required. The vulnerability was remotely exploitable from the internet, required no user interaction, and provided the highest privilege level on the target system.

[TECHNICAL NOTE]

Blaster's propagation mechanism used a technique that differed from Code Red and Nimda. Rather than simple random IP scanning, Blaster used a biased scanning strategy: 3/4 of the time it scanned random IPs in the same /8 subnet as its own IP address (local network bias), and 1/4 of the time it scanned completely random IPs. The local network bias was strategically effective because machines in the same subnet were far more likely to be connected, reachable, and unpatched than random internet machines. Corporate and ISP networks, which had large numbers of machines in the same /8 space, spread Blaster rapidly through internal networks even when perimeter firewalls blocked external scanning. This technique meant the worm could penetrate corporate networks through a single internally-infected machine and then spread rapidly without any external traffic. The distinction between perimeter-focused defense (blocking port 135 at the border) and network-level defense (blocking RPC exploitation between internal machines) was dramatically illustrated by Blaster: many organizations had blocked port 135 at the firewall but allowed it internally, and Blaster spread explosively through their internal networks once one machine was compromised.

The Welchia Counter-Worm

Shortly after Blaster appeared, a "counter-worm" called Welchia (or Nachi) appeared that exploited the same vulnerability to spread, but instead of deploying a DDoS payload, it attempted to download and install the MS03-026 patch from Microsoft's Windows Update servers. Welchia was designed by someone who had apparently decided to fix the vulnerability by force.

Welchia's well-intentioned design had catastrophic side effects. The worm spread using the same ICMP ping scans and RPC exploits as Blaster, generating enormous amounts of network traffic. In some organizations and ISPs, Welchia's traffic - trying to reach Windows Update on every machine it infected - caused more network disruption than Blaster itself. The Welchia episode became the canonical example of why unauthorized "helpful" network activity - even genuinely attempting to remediate a vulnerability - causes unpredictable damage and is ethically and legally problematic.

[WARNING]

Blaster's DDoS against windowsupdate.com created a self-reinforcing crisis. The worm infected machines partly because users hadn't applied the available patch. The worm then attacked the update service that would allow them to patch. Users who became aware of the outbreak and tried to update their systems found the update service degraded. Microsoft had to change the target IP address of the DDoS by moving windowsupdate.com to different infrastructure, resolving the immediate attack - but only because they had the resources to do so quickly. For a smaller organization, an attack on its own remediation infrastructure would have been far more damaging. The pattern of attacking remediation and notification infrastructure during an incident - attacking the tools defenders use to respond - predated Blaster in theory but Blaster demonstrated it in practice at internet scale. The same design appears in subsequent malware that disables Windows Update, kills antivirus processes, or modifies hosts files to block security vendor domains.

The Push for Automatic Updates

Blaster was released 26 days after the patch was available. SQL Slammer had been released 6 months after its patch. Code Red was released 27 days after its patch. The pattern was clear: critical vulnerabilities in widely-deployed Windows components were being exploited within days to weeks of patch release, but enterprise patching timelines stretched to months. Users and organizations were systematically failing to apply patches fast enough to stay ahead of worm propagation.

Microsoft's Trustworthy Computing initiative, launched in January 2002 after Code Red and Nimda, had produced Windows XP SP2 as a direct response. SP2, released in August 2004 (one year after Blaster), included Windows Security Center with automatic update prompting, an improved Windows Firewall enabled by default that blocked port 135 externally, and Data Execution Prevention (DEP). These changes directly addressed the conditions that made Blaster's spread possible. The Blaster outbreak also accelerated corporate adoption of patch management automation - tools like WSUS (Windows Server Update Services), SMS, and later SCCM that automated patch deployment rather than relying on individual administrators to manually apply each patch.

[IOC]

Blaster (MSBlast/Lovsan/W32.Blaster.Worm) technical summary: first detected August 11, 2003. Vulnerability: CVE-2003-0352, stack buffer overflow in Windows RPC DCOM (MS03-026). Affected systems: Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003. Patch availability: MS03-026, released July 16, 2003 (26 days before outbreak). Exploitation port: TCP 135 (RPC endpoint mapper); also 139, 445. Propagation: biased IP scanning (75% same /8 subnet, 25% random IPs). Payload 1: forced system reboot loop via RPC shutdown exploit. Payload 2: DDoS against windowsupdate.com (SYN flood, August 15-31 activation). Embedded string: "I just want to say LOVE YOU SAN!!" (second variant); "billy gates why do you make this possible. Stop making money and fix your software!!" (first variant). Infection count: estimated 8-16 million machines. Welchia counter-worm: spread using same exploit; attempted to install MS03-026; caused significant network degradation from ICMP traffic. Criminal outcome: Jeffrey Lee Parson (18, Minnesota) arrested and convicted for creating a Blaster variant; sentenced to 18 months federal prison. Original Blaster author: never identified. Legacy: directly contributed to Windows XP SP2 automatic updates and firewall-enabled-by-default; accelerated enterprise patch management automation.