The Welchia Worm Wars: When Vigilante Code Tried to Save the Internet
In summer 2003, a strange digital battle played out across the internet. Two computer worms fought each other on hundreds of thousands of computers worldwide. One worm attacked systems and caused chaos. The other tried to fix the damage.
The second worm had good intentions. But good intentions don’t always lead to good results.
The Original Attack: Blaster Strikes
On August 11, 2003, the Blaster worm began spreading rapidly across the internet. The worm exploited a vulnerability in Microsoft Windows’ Remote Procedure Call service. Windows 2000 and Windows XP systems were the primary targets.
Microsoft had already released a patch one month earlier. They warned everyone to install the update. The Department of Homeland Security sent out alerts. Cybersecurity experts raised alarms.
Many organizations ignored these warnings. They failed to apply the patches.
Blaster infected more than 100,000 systems in the first week. Infected computers rebooted every 60 seconds. Error messages appeared constantly. Systems became unusable. The worm also attempted a denial-of-service attack against windowsupdate.com.
Hidden inside Blaster’s code were two messages. The first read “I love you San!!” The second taunted Microsoft’s founder: “billy gates why do you make this possible? Stop making money and fix your software!!”
Enter the Vigilante: Welchia’s Mission
One week later, on August 18, 2003, a new worm appeared. Security researchers named this one Welchia. Some called this a “helpful worm” or “nematode.” The worm had a different agenda than Blaster.
Welchia’s mission was to help, not harm. The worm would search for computers infected with Blaster. Then the worm would remove the malicious code. Next, the worm would download and install Microsoft’s security patches. Finally, the worm would delete itself on January 1, 2004.
The creator left a personal message in the code: “I love my wife & baby 🙂 ~~~ Welcome Chian ~~~ Notice: 2004 will remove myself:) ~~ sorry zhongli~~~”
Welchia operated through a multi-stage process. First, the worm sent pings across networks to find active systems. Once the worm located vulnerable machines, Welchia would exploit the same vulnerability Blaster used. After gaining access, the worm hunted for Blaster, terminated its processes, and deleted the malicious files. Then Welchia downloaded Microsoft’s patches, installed them, and rebooted the system.
When the Cure Became the Disease
Welchia proved that good intentions don’t guarantee good outcomes. The worm’s aggressive scanning behavior created massive network traffic. In some cases, Welchia caused more problems than Blaster.
Welchia used pings to scan entire networks. Each infected machine sent a ping to every address on its local subnet, plus random internet addresses. The resulting network congestion was devastating. Organizations that had contained the Blaster outbreak suddenly found their networks grinding to a halt under Welchia’s “helpful” scanning.
The casualties mounted fast. On August 18, 2003, the Navy Marine Corps Intranet was hit hard. Email, internet, and shared drive access failed for thousands of users. The US State Department’s worldwide intranet shut down for nine hours on September 23, 2003. Embassies and consulates stopped processing visa applications. Lockheed Martin and Air Canada reported major disruptions.
Universities suffered badly. A survey of 19 research universities showed each institution spent an average of $299,579 during a five-week period to recover from Blaster and Welchia. Campus networks became so congested that wireless LANs stopped working completely.
Welchia had technical problems too. The worm only worked on English, Korean, and Chinese versions of Windows. While Welchia successfully removed Blaster from infected systems, Microsoft acknowledged the worm was not always successful at applying security patches properly.
The Hunt for the Creators
Welchia’s author remains unknown. But authorities caught one of the Blaster variant creators.
On August 29, 2003, the FBI arrested Jeffrey Lee Parson, an 18-year-old from Hopkins, Minnesota. Parson created the “Blaster B” variant. He operated online as “teekid.”
Parson modified the original Blaster worm and released the variant on August 12, 2003. His version infected at least 7,000 computers. Some estimates suggest 48,000 infections. The damage totaled approximately $1.2 million.
FBI investigators tracked Parson by deliberately infecting a computer with the virus. They monitored its connection to www.t33kid.com. The website led them back to Parson.
Parson admitted to creating the worm on his home computer. He expressed remorse. In January 2005, a judge sentenced him to 18 months in prison, three years of supervised release, 100 hours of community service, and victim restitution. The judge noted Parson’s young age, history of mental illness, and lack of parental guidance. She stated: “What you’ve done is a terrible thing. Aside from injuring people and their computers you shook the foundation of technology.”
The original Blaster creator and the Welchia author were never caught.
The Ethical Question
Welchia sparked intense debate within the cybersecurity community. The worm had benevolent intentions. But the worm highlighted fundamental problems with automated defensive measures that operate without authorization.
Security experts condemned the approach. Cornel Swart, national sales manager for Sophos distributor NetXactics, stated: “The writer of the Nachi worm wants to be seen as the Dirty Harry of the Internet world, cleaning up malicious Blaster code. But no virus is a good virus. Infecting systems to disinfect and patch computers isn’t a responsible way to deal with the problem.”
The core issues were clear. First, Welchia infected and modified systems without permission or knowledge of owners. This raised serious legal and ethical questions about unauthorized access. Second, Welchia caused significant collateral damage through network congestion and system instability despite good intentions. Third, the worm’s attempts to patch systems conflicted with existing configurations, broke applications, or failed to complete properly.
Welchia demonstrated that automated “fixes” spiral out of control easily. Unlike carefully orchestrated patch deployment by IT professionals, the worm had no mechanism to assess whether a system could be safely modified. The worm had no way to verify successful remediation. The worm had no ability to roll back changes if something went wrong.
Lessons for Modern Cybersecurity
The dual outbreak of Blaster and Welchia provided cybersecurity professionals with lessons that continue to influence defensive strategies today.
Patch Management is Critical
Microsoft released patches for the exploited vulnerability a full month before Blaster struck. The delayed patch deployment had deadly consequences. Organizations learned they needed automated, centralized patch management systems. Relying on individual departments or users to update systems doesn’t work.
Network Architecture Matters
The worm outbreaks exposed critical weaknesses in network design. Security professionals realized they needed better network segmentation and VLAN strategies to isolate infected systems. They needed the ability to provide limited network access for remediation without completely disconnecting compromised machines.
Defense in Depth
Relying solely on perimeter defenses proved insufficient. Worms spread rapidly within trusted networks. The incidents accelerated adoption of layered security approaches. Organizations added host-based firewalls, intrusion detection systems, and application whitelisting.
Vigilante Solutions Are Not Solutions
This is the most important lesson. Well-intentioned but unauthorized automated responses to security threats cause more problems than they solve. The cybersecurity community firmly established that ethical hacking requires proper authorization, careful planning, and controlled deployment. Self-replicating code released into the wild is not the answer.
Incident Response Planning
Organizations learned they needed comprehensive incident response plans. These plans included procedures for network isolation, offline patch distribution, and coordinated cleanup efforts across large networks.
The Persistence Problem
Blaster persisted long after the initial outbreak. Observations taken in August 2004, a full year later, showed roughly 90,000 unique subnets were still experiencing Blaster activity. Many infected hosts remained active.
The persistent infections displayed patterns. Peak activity occurred during working hours in the eastern United States. Activity dropped on weekends. This suggested many infected systems were being turned on and off daily as workers and home users powered computers. The infections remained undetected and unpatched.
Why This Story Matters
The Welchia worm wars of 2003 represent a unique moment in cybersecurity history. Someone genuinely attempted to use malware for good. The attempt demonstrated conclusively why such approaches are fundamentally flawed. The incident illustrates that in cybersecurity, intentions matter far less than consequences. Unauthorized access remains unauthorized regardless of motivation.
For cybersecurity professionals and students today, the story serves as a cautionary tale about the dangers of digital vigilantism. Fighting fire with fire is tempting when facing devastating attacks. The Welchia incident proved that automated defensive measures require the same care, planning, and authorization as any other security operation. The path to a more secure internet is not paved with vigilante code. The path requires responsible disclosure, coordinated patching, and collaborative defense.
Two decades later, as we face increasingly sophisticated cyber threats, the lessons from Welchia remain relevant. Good intentions don’t justify bad methods. In cybersecurity, sometimes the “cure” is worse than the disease.
