Zotob appeared on 14 August 2005 exploiting MS05-039 — a Plug-and-Play vulnerability in Windows 2000. The scale was modest by Sasser standards but the disruption was substantial — CNN, ABC, Caterpillar, the New York Times all reported significant disruption.
This is a longer-than-usual treatment because the Zotob incident teaches several specific lessons that the smaller scale might otherwise hide.
What Zotob does
The technical mechanism: Zotob exploits a buffer overflow in the Windows Plug-and-Play service. The vulnerability is exposed on TCP port 445 (the same port used for SMB file-sharing). A specifically-crafted PnP request triggers the overflow.
The vulnerability primarily affects Windows 2000. Windows XP SP2 and later versions have substantial mitigations that make exploitation harder; the worm targets the older platform specifically.
Once a host is compromised, Zotob:
- Installs itself with persistence in the Windows registry.
- Begins scanning for other vulnerable hosts on port 445.
- Connects to specific IRC servers for command-and-control.
- Includes a backdoor that the IRC operators can use for additional commands.
The IRC-based command-and-control is operationally interesting. The compromised hosts join specific IRC channels; the channel operators can issue commands; the bot population responds. This is essentially the architecture of a botnet, with Zotob acting as the propagation mechanism for adding new hosts to the botnet.
The MS05-039 advisory
Microsoft published MS05-039 on 9 August 2005. The advisory was clear about severity — remote code execution, no authentication required, default-vulnerable on Windows 2000. The patch was made available with the advisory.
The gap between disclosure and worm appearance was 5 days. Five days. This is the shortest patch-to-worm gap I have observed. The trajectory continues — each successive worm appears more quickly after the underlying advisory.
Five days is barely enough time for any operator to test, schedule, and deploy a patch across a non-trivial estate. Operators who patched within the same week were safe; operators on monthly patching schedules were not.
Why Windows 2000 is still targeted
Windows 2000 is, by 2005, an older operating system. Microsoft has been pushing operators toward Windows XP for years. Windows Server 2003 has been available since 2003. Why is Windows 2000 still such a substantial target?
Three reasons:
Many organisations have not migrated. Windows 2000 deployments remain common in enterprise environments where migration costs are substantial. The operator population running Windows 2000 in 2005 is smaller than it was in 2003 but is still meaningful.
Specific applications require Windows 2000. Some line-of-business applications are certified only against Windows 2000; their vendors have not certified them against newer Windows versions. Operators dependent on these applications cannot easily migrate.
The patching cadence at lagging organisations is poor. Even operators running Windows 2000 should be applying patches; many do not. The cumulative gap (older operating system + slow patching) produces a substantial vulnerable population.
The specific organisations affected by Zotob — CNN, ABC, the New York Times, Caterpillar — are all large enterprises. The pattern of large enterprises running Windows 2000 with imperfect patching discipline is the norm, not the exception.
The disproportionate disruption
Zotob's compromised population was modest — perhaps tens of thousands of hosts globally. By worm-volume standards this is small. The press coverage was substantial because the affected organisations were prominent.
The specific operational impact at affected organisations:
CNN reported newsroom systems were unable to function for several hours. Production of news content was disrupted; broadcasts went out without expected support content.
The New York Times reported similar disruption to editorial systems.
Caterpillar reported manufacturing-floor systems were affected. Production was disrupted at multiple facilities for hours.
ABC and several other media organisations reported similar issues.
The pattern: media organisations and large industrial operations experienced disproportionate impact. The reason is that these organisations have specific Windows-based systems for production and editorial work that are operationally critical, that have been running on Windows 2000, and that have not been migrated because the migration cost is substantial.
The Zotob incident is, in some sense, the visibility version of an underlying problem that has been growing for years. The vulnerable Windows 2000 population is large; the operational impact when it is targeted is substantial; the migration process is slow.
The author and the arrest
Unusually for a worm of this scale, the authors were caught quickly. Within two weeks of Zotob's appearance, Moroccan and Turkish authorities arrested two individuals — Farid Essebar and Atilla Ekici — who were identified as the worm's authors. The investigation was facilitated by US-based law enforcement coordination with the relevant national authorities.
The arrest is operationally significant for several reasons.
The international cooperation worked. Multi-jurisdiction cybercrime investigations have historically been slow and difficult. The Zotob investigation was rapid by historical standards; the cooperation between US, Moroccan, and Turkish authorities was effective.
The deterrent value is real but bounded. Worm authors who operate from jurisdictions that cooperate with international law enforcement now face meaningful prosecution risk. Authors who operate from jurisdictions that do not cooperate continue to be largely safe.
The motivation was commercial. The investigation revealed that Essebar was being paid by Ekici to write the worm. The worm was, on the available evidence, intended to be used for commercial cybercrime — building a botnet that could be rented out for various purposes.
This is the commercial-cybercrime pattern that has been emerging for years. The worm-authoring activity is no longer primarily about peer recognition or ideological grievance; it is about money. The economic infrastructure is mature; the law-enforcement response is starting to catch up.
What this teaches
Four generalisations.
The patch-to-worm gap continues to shrink. Five days is a new low. Operators who patch within days of advisory remain safe; operators on traditional cycles do not.
Older operating systems remain a substantial target. Windows 2000 in 2005 is similar to Windows 95 or 98 in 2001 — older platforms with persistent vulnerable populations. The migration pressure is real but slow.
Lateral spread inside organisations remains the dominant operational impact. The specific organisations affected by Zotob were affected because the worm spread laterally on internal networks once introduced. Internal segmentation continues to be undervalued.
Commercial cybercrime is the dominant motivation. The Zotob authors were being paid; the worm was intended for botnet recruitment; the economic infrastructure continues to mature. This is the structural shift I have been writing about for years; it continues.
What operators should do
For anyone running Windows 2000:
Apply MS05-039 immediately. The patch is available; the cost is small; the cost of not applying is substantial.
Plan migration to a current operating system. Windows 2000 will continue to be a target; the patches will eventually stop; the operational risk continues to grow. Migration to Windows XP or Windows Server 2003 is overdue for most operators still running 2000.
Block port 445 at network perimeters. No legitimate service should be exposed on this port across an internet boundary.
Block port 445 on internal segments where possible. The lateral-spread problem requires internal segmentation. The Zotob impact at affected organisations was largely from internal lateral spread.
For anyone running Windows XP or Server 2003:
Verify your patches are current. XP SP2 has substantial mitigations against this class of vulnerability; the patches still matter.
Audit for legacy Windows 2000 hosts in your environment. Many organisations have small numbers of Windows 2000 hosts that have been forgotten. Each is a potential infection vector.
For cleanup of compromised hosts:
Standard cleanup applies. Stop the worm process, remove persistence, apply the patch, verify cleanliness, monitor for reinfection.
Inspect for the IRC-based command-and-control connections. Compromised hosts have been connecting to specific IRC servers. Block the relevant IPs and ports at network perimeters; this disrupts the post-compromise control without removing the compromise itself.
What I am doing
For my own infrastructure: zero direct exposure (no Windows 2000). The collateral scan traffic is real but bounded.
For friends running Windows infrastructure: a note about MS05-039 priority and about Windows 2000 migration. Two friends had Windows 2000 hosts they had been planning to migrate; the Zotob incident has accelerated their planning.
For my Snort sensor: rules for the specific Zotob exploit pattern and for the IRC-based command-and-control connections. The rules will catch ongoing scan attempts and any internal hosts attempting to phone home to the worm's controllers.
A small reflection on the Windows 2000 question
Windows 2000 has been Microsoft's mainstream server platform for the first half of this decade. It is now in extended support; mainstream support ended in mid-2005. The trajectory points toward Windows 2000 being a substantial security risk for the next several years as patches become less frequent and operator migration remains uneven.
For operators still running Windows 2000: the question is no longer "should we migrate?" but "how quickly can we migrate?". Each year of continued Windows 2000 deployment is a year of increasing risk.
For Microsoft: the pressure to extend support continues; the pressure to not extend support also continues. The balance is contested. From a security perspective, ending support sooner produces clearer migration incentives; from a customer-relationship perspective, longer support reduces operational pain. The actual outcome will be somewhere in between.
For the broader industry: similar patterns will recur with future operating systems. Windows XP will eventually be the legacy platform that Windows 2000 is now. The lessons from Windows 2000's long tail apply to every successor.
What this points to
Three predictions:
More Windows 2000 worms over the next 12-18 months. The vulnerable population is large; the patching is poor; the worm authors will continue to target it.
Increased pressure for Windows 2000 migration. Operators will accelerate migration plans; vendors will provide more migration support; insurers may begin to factor Windows 2000 deployment into their risk pricing.
The Zotob authors' arrest as precedent. Future investigations will reference this case. The cumulative effect of successful cybercrime prosecutions matters; it does not solve the problem but it raises the cost for operators in cooperating jurisdictions.
More as the year develops.
A closing note
Writing this on Friday evening with the worm's immediate disruption mostly resolved. The cleanup at affected organisations will continue for weeks; the structural lessons (Windows 2000 migration, internal segmentation, faster patching) will play out over years.
For any operator reading this who is still running Windows 2000: this is the time to plan migration. The next worm in this pattern will probably target Windows 2000 again. The risk continues to grow.
More in time.
A further structural look at the Zotob window
Let me extend this post with additional context on the Zotob incident and its specific lessons.
The Windows 2000 long tail
The Zotob incident has highlighted the substantial population of Windows 2000 hosts still in production deployment. The specific pattern:
Enterprise core servers. Many UK enterprises run Windows 2000 servers for specific applications (line-of-business systems, legacy database engines, specialised internal services). The migration to newer Windows versions has been deferred because the application certification has not been updated.
Embedded systems. Industrial control systems, point-of-sale systems, ATM hosts, kiosks — many are running Windows 2000 with no current migration plan. The vendors who supply these systems have not certified them on newer Windows; the operators are dependent on the vendors.
Forgotten servers. Small, infrequently-used servers in corner roles, often without active maintenance. These are the most vulnerable to specific advisory-driven worms.
The cumulative population is, on the available estimates, in the millions of hosts globally. The specific UK population is substantial.
The migration economics
Why is this population still running Windows 2000?
Migration cost. Each Windows 2000 host typically requires application testing, possible application replacement, infrastructure changes, retraining, and deployment work. The per-host cost is substantial; cumulative cost across hundreds of hosts is enormous.
Application vendor constraints. Many applications have not been certified on newer Windows. The application vendors may have moved on, may charge for re-certification, may not have the resources to test. The operators are bottlenecked on vendor decisions they do not control.
Operational risk of migration. Migration projects can fail; failed migrations produce service disruption; the risk of disruption is sometimes assessed as higher than the risk of running unpatched legacy systems.
Microsoft support pricing. Microsoft's extended-support pricing for Windows 2000 has been substantial; some operators are paying extended support rather than migrating.
The combination produces continued Windows 2000 deployment despite the security risks.
What this teaches about migration generally
The Windows 2000 pattern will recur with future operating systems. Windows XP will eventually be the legacy platform; Windows Server 2003 will eventually be too. The structural problem is general.
For any operator running infrastructure: the migration discipline is a long-running operational concern. Specific practices that help:
Inventory current. Know what is running where, on what version, with what support status. The discipline of maintaining the inventory is the first step.
Migration roadmap. For each major platform, a planned migration window before the support end-of-life. The plan does not have to be detailed; it has to exist.
Application portability. Applications that depend tightly on specific OS versions are migration constraints. Reducing the OS-specificity of business applications is a long-running discipline.
Vendor pressure. Operators who are bottlenecked on vendor certification can sometimes accelerate the process by collective pressure. Industry coordination helps.
None of these are fast. The cumulative discipline over years produces operators who can migrate when they need to.
The Microsoft response
Microsoft's specific response to Zotob has been measured. The patch was available a week before the worm; the post-incident communication has been clear; the operational support for affected customers has been adequate.
This is, in my assessment, the Trustworthy Computing discipline working as intended. Three years ago, the Microsoft response to a similar incident would have been less smooth; the current response shows measurable improvement.
The substantive test of Trustworthy Computing has always been: does the rate of new vulnerabilities decrease, and does the response when new vulnerabilities appear improve? On the second question, the answer is unambiguously yes. On the first question, the answer is less clear — the rate of new vulnerabilities continues but the severity may be slightly lower than the previous trajectory predicted.
What I expect over the next 12 months
Three predictions:
Continued Windows 2000 worm activity. Probability: 70%, deadline end of 2006. The vulnerable population is large; the patching is poor; specific incidents will continue.
Acceleration of Windows 2000 migration plans. Probability: 75%, deadline end of 2006. The cumulative pressure (worms, support pricing, vendor pressure) will push operators to plan migrations more aggressively.
At least one large UK operator publicly attributing an incident to Windows 2000 retention. Probability: 60%, deadline end of 2006. Specific organisations will face public pressure about their infrastructure choices.
More as the year develops.
A small note on the cleanup window
Let me close with observations on the cleanup phase that follows worm incidents.
The cleanup work is where the operational maturity of organisations becomes most visible. Mature organisations have systematic cleanup procedures; less mature ones improvise.
The specific elements of disciplined cleanup:
Inventory of affected hosts. Knowing what is compromised is a prerequisite to fixing it. Many organisations cannot answer this question quickly; the discipline of inventory is the foundation.
Standard cleanup procedure per affected host. Tested in advance; documented; deployable under pressure. The procedure includes: stop the active worm, remove persistence, apply the patch, verify cleanliness, return to service.
Verification beyond the obvious. The host that is no longer running the visible worm process may still have residual artefacts. Specifically: registry persistence, modified system files, unauthorised user accounts, scheduled tasks. Each must be checked.
Communication during cleanup. Users need to know what is happening. Status updates, expected resolution times, what to do in the meantime. The communication is itself part of the response.
Post-incident review. What worked, what did not, what should change. The discipline of writing this down captures the lessons; the lessons inform future incidents.
For any operator dealing with a Zotob-style incident: the cleanup is more involved than removing the active worm. The full sequence above is the right discipline.
More as the year develops.