Witty appeared on 19 March 2004 and reached saturation of its target population in approximately 45 minutes — even faster than SQL Slammer. The vulnerability it exploits is unusual: a buffer overflow in ISS BlackICE personal firewall, a security product. The irony is acute. The structural lessons are larger than the irony.
This post is going to be a substantial walkthrough. Witty is short-lived but operationally significant for several reasons that are worth careful treatment.
What Witty does
The technical mechanism: Witty exploits a buffer overflow in BlackICE's ICQ packet processing. BlackICE inspects ICQ traffic; the inspection code has a vulnerability; a specifically-crafted ICQ packet triggers the vulnerability. The exploit gives the attacker code execution at the privilege level of the BlackICE service, which is high.
Once a host is compromised, Witty:
Begins scanning. Each compromised host scans random IP addresses, generating UDP packets that target ICQ ports. The scan rate is high — comparable to Slammer's, perhaps 2,000 packets per second per host.
Includes a destructive payload. This is the new part. Witty overwrites random sectors of the host's hard drive with random data. The corruption is not catastrophic immediately — the host continues to run for a while — but eventually the corruption hits something important and the host fails. Often the failure happens hours or days after the initial infection.
Does not establish persistence. Witty is memory-resident only. A reboot removes the worm process. The disk corruption, however, persists.
Does not include a backdoor. Unlike Code Red II or MyDoom, there is no command-and-control mechanism. The worm is purely propagation-and-destruction.
The destructive payload is the structural innovation. Most worms since Melissa have been mostly non-destructive — propagation-focused, with destruction as a secondary or absent feature. Witty makes destruction the primary feature.
The vulnerable population
The number of internet-exposed BlackICE installations was small — approximately 12,000 hosts, by the available estimates. This is two orders of magnitude smaller than the Slammer-vulnerable population (75,000 SQL Servers) or the Code-Red-vulnerable population (360,000 IIS servers). A worm targeting such a small population should not, by typical worm-arithmetic, be a major incident.
Witty was a major incident anyway, for two specific reasons.
First, the speed. Forty-five minutes from initial seeding to global saturation. The math works out: with β around 0.4 per second per host (high because of the small target space and aggressive scanning), the doubling time is approximately 1.7 seconds. From a single seed, fourteen doublings produces 16,000 — saturation of the 12,000-host target population. Fourteen doublings at 1.7 seconds each is 24 seconds of pure exponential growth; the actual saturation took longer due to network and processing constraints, but the underlying speed is extreme.
Second, the irony. The vulnerable product is a security product. BlackICE is sold as a personal firewall — its purpose is to defend the host. The irony of a security product being the attack vector amplified the press coverage and the operational discussion. Witty was discussed disproportionately to the size of its vulnerable population.
The seeded list
The most operationally significant detail of Witty is the seeded list. Witty did not start from a single seed. The worm appeared simultaneously on approximately 110 hosts, distributed globally, in the first second of its emergence.
This is structurally different from earlier worms. Code Red started from a single seed and propagated outward. Witty started from many seeds simultaneously.
The implication: the author had pre-compiled a list of vulnerable BlackICE hosts before releasing the worm. The 110 initial hosts were targeted directly with the worm payload; the worm then spread from those 110 hosts to the rest of the population.
The pre-compiled list suggests that the author had been doing reconnaissance before the worm was ready. The 110 hosts were not random; they were specifically known to be vulnerable. The reconnaissance happened in advance of the public outbreak.
This matters because it changes the timeline of what was knowable. The vulnerability in BlackICE was patched on 18 March; the worm appeared on 19 March. The patch was less than 24 hours old. Operators who had not patched were vulnerable; the number of vulnerable operators was effectively determined by the patching cadence over the past 24 hours, which is essentially zero for almost all operators.
The patch-to-worm gap was, in some real sense, zero hours. No operator could have been protected by patching within the available window.
The destructive payload
The disk-overwriting behaviour is operationally significant in ways that pure propagation worms have not been.
Recovery requires restoration from backup. A worm that just compromises a host can usually be cleaned up in place — kill the process, remove the persistence, apply the patch, reboot. A worm that has corrupted the host's filesystem requires restoration of the lost data, which means restoration from backup, which many operators do not maintain rigorously.
The damage continues after the infection ends. Witty corrupts disk sectors during its run; the corruption persists after the worm is gone. Operators who clean up the worm but do not check filesystem integrity are still affected; data loss appears later.
The cost of compromise is permanent rather than recoverable. With other worms, the compromise is a temporary inconvenience that can be undone. With Witty, the compromise produces lost data that may or may not be recoverable.
This category of damage is what most operators are now taking seriously for the first time. The defensive infrastructure for non-destructive worms (signature-based detection, automated cleanup) does not address destructive payloads. The defence must shift toward prevention (because cleanup does not recover the damage) and toward robust backup (because the damage is permanent).
For my own infrastructure: my backup discipline has been good for years. Witty is the strongest validation of the discipline I have observed.
What this teaches structurally
Four things.
Security products are also targets. The vulnerability in BlackICE is the irony but the lesson is general — defensive products are attack surface like any other software. Operators should not assume that products labelled "security" are inherently safer than products not so labelled.
The deeper version: anti-virus, intrusion detection, firewalls, endpoint protection — all of these are software, all of them have bugs, all of them are potential entry points for compromise. The security industry has been slow to acknowledge this; Witty is the largest single piece of evidence forcing the acknowledgement.
Speed continues to escalate. Forty-five minutes to saturation is faster than Slammer. The trajectory of worm-propagation speed continues. Future worms will be faster.
The implication for defenders is the same as after Slammer: reactive defence has a horizon below which it stops working. For Witty's 45-minute saturation, no human response is fast enough. The defence must be entirely pre-positioned.
Pre-compiled target lists are a category. The seeded-distribution approach Witty used is now operationally demonstrated. Future worm authors will copy the technique. The implication: the patch-to-worm gap is no longer the meaningful timescale; the advisory-to-reconnaissance gap is.
Defenders who patch within hours of advisory may still be hit if the attacker had pre-existing reconnaissance data. The defensive answer is to avoid being on the reconnaissance list in the first place, which means tighter perimeter filtering, less generous default exposure, more aggressive removal of unused services.
Destructive payloads are returning. Most worms since 2001 have been mostly non-destructive. Witty is the first major destructive worm in years. Whether it is a one-off or the start of a trend remains to be seen.
If destructive payloads become common, the cost-benefit of every other defensive discipline shifts. Cleanup becomes inadequate; prevention becomes essential; backup discipline becomes critical.
What operators should do
For BlackICE users (the directly affected population):
Apply the patch if you have not already. The worm has saturated the originally-vulnerable population, but new BlackICE installations and new internet-exposed instances continue to appear. The patch eliminates the exposure.
Verify filesystem integrity. If you were ever exposed to Witty, run filesystem integrity checks. The disk corruption may be partial and not yet visible. Early detection allows restoration before the damage propagates to backup copies.
Restore from backup if you find corruption. The cost of restoring is small compared to the cost of continuing to operate on corrupted filesystems.
For operators not running BlackICE (most of the audience):
Audit your security products for current patches. The BlackICE pattern can repeat against any security product. Anti-virus, IDS, firewall — all need to be kept patched.
Consider the destructive-payload threat. Backup discipline matters more than ever. If you have not validated your backup-restoration procedures recently, do so.
Watch for other small-population worms. A Witty-class worm targeting any niche product can produce 45-minute saturation. The next one may target a product you do run.
What I have observed
For my own infrastructure: I do not run BlackICE. The direct exposure is zero.
For my Snort sensor: the Witty scan traffic was substantial during the peak, but bounded. The scan pattern is distinctive (UDP packets with specific payload characteristics) and the rules to detect it are simple. The post-saturation scanning continued for several days as compromised hosts continued to propagate; the volume gradually subsided.
For my structured-log analysis: the Witty dataset is small (small target population, short duration) but informative. The 45-minute saturation curve is visible in the data; the model fits reasonably; the structural conclusions are consistent with what other operators have published.
For friends running BlackICE: I sent notifications to two friends I knew used the product. Neither was hit; both had been patched within the 24-hour window before the worm.
What this changes for my predictions
From my 2004 list:
Witty resolves the prediction about "continued worm activity" affirmatively. It does not specifically resolve any other prediction; the destructive-payload feature was not in my list. I should have included it; I did not. Calibration adjustment: include destructive payloads as a category in future predictions lists.
The pre-compiled-target-list aspect is also new for me. Future predictions should include the possibility that worms have pre-existing reconnaissance data, which makes the patch-to-worm window less protective than it appears.
A reflection on speed and the operator population
Witty's 45-minute saturation, against a 12,000-host vulnerable population, is the kind of incident that is essentially impossible for any individual operator to respond to during the event itself. The operators who were not hit were either patched within the previous 24 hours (rare) or did not run BlackICE in the first place.
This is a different operational shape than Code Red or Sasser. Those worms had hours-to-days saturation; an operator who started responding when the worm appeared could materially affect their own outcome. With Witty, the only thing the operator could do during the event was watch.
The defensive shift this implies is profound. The operator-as-responder model continues to break down. The operator-as-architect model — where the relevant decisions are made before the incident, in the design of the infrastructure — is increasingly the only viable approach.
For my own work and writing: more emphasis on architectural decisions made in advance. Less emphasis on the response process during incidents. The trajectory of worm speed makes this shift necessary.
What this points toward
Three predictions, with probabilities:
A worm with both Witty-style speed and a destructive payload, against a larger target population. Probability: 60%, deadline: end of 2005. The combination has not yet been achieved at scale; the components are demonstrated; the assembly is straightforward.
A worm targeting another security product. Probability: 70%, deadline: end of 2005. The BlackICE pattern can be reused; the security-product population is well-known.
A worm using pre-compiled target lists with longer-running reconnaissance. Probability: 75%, deadline: end of 2005. The seeded-distribution technique is now demonstrated; the reconnaissance can scale to much larger lists than Witty's 110.
More as the year develops.
A closing note
Writing this on the Sunday after Witty. The worm has saturated; the cleanup is starting; the structural lessons are becoming clear. The 45-minute saturation has produced more discussion in the security community than the small vulnerable population would otherwise have warranted; the destructive payload has produced more discussion still.
For the field as a whole, Witty is a small but important inflection point. The trajectory of worm speed continues. The introduction of destructive payloads continues. The structural defensive answers — pre-positioned everything — continue to be the only viable approach.
For operators: the lesson is to take security-product patching as seriously as Microsoft-product patching. The vendors hope that you assume their products are safe. They are not.
More in time.
Why this category will repeat
A reflective addition. The Witty pattern is going to repeat because the underlying conditions that produced it are persistent.
First, security products will continue to have vulnerabilities. The codebases are written in C, like everything else; the same memory-corruption bugs that affect other software affect security software. The vendors have stronger incentives than most to find these bugs, but the rate of new bugs continues.
Second, the discovery-to-exploitation gap will continue to shrink. Reconnaissance tools improve over time; attacker workflows mature; the time between vulnerability disclosure and operational exploitation has been compressing for years and will continue to compress.
Third, the destructive-payload temptation will grow. As propagation becomes commoditised, the differentiation moves to payload. Authors who want their worms to have impact beyond the propagation itself will increasingly include destructive payloads. The trajectory points toward more Witty-style events, not fewer.
Fourth, small-population worms are operationally underestimated. Operators reading about Witty often dismissed it as 'only 12,000 hosts'. The 45-minute saturation against any small specific population is a structural threat to any operator running the affected product, regardless of the absolute size of the population. Future Witty-class events will hit different products and different populations; the lesson generalises.
For my own writing going forward: more attention to small-population worms. The big-population events get the press; the small-population events teach the structural lessons. Both deserve sustained attention.
A small note for security-product vendors
A digression aimed at any reader who works for a security-product vendor. Your products are now operational targets. The Witty pattern means that any vulnerability in your product is potentially the seed of a fast-saturating worm. The patching cadence and quality you provide directly affects your customers' exposure during this category of incident.
The specific implications for vendor practices:
- Code review for security-relevant components must be at the highest level your organisation can sustain.
- Patch availability must be aggressive — vulnerabilities found internally should produce patches within days, not weeks.
- Patch distribution must be pushed rather than pulled — customers who have to manually download and install patches will lag the threats.
- Communication during incidents must be frequent and honest — customers need to know what to do during the operational window.
Most security-product vendors are doing some of this. The bar continues to rise; the cost of failing to clear the bar is increasing. The Witty incident is a small but visible reminder.
More in time.
Final thought
The Witty incident is going to be remembered for the speed and the irony. The longer-term operational lessons — about security products as targets, about destructive payloads, about pre-compiled reconnaissance lists — will be discussed for years. Each will produce specific defensive responses that take time to deploy. The trajectory is, as ever, that the threat side iterates faster than the defensive side; the gap between them, on the structural metrics, continues to widen.
For any operator running internet-facing infrastructure of any kind: this is the time to audit which security products are deployed, which versions, with what patches. The audit takes hours; the protection it provides against the next Witty-class event is meaningful. The few operators who do this kind of audit regularly are differentially safer than those who do not. The differentiation is structural; the cost of being on the wrong side of it grows over time.
More in time.