ExploreZip — also called zipped_files.exe — appeared this past weekend. It is the third major mass-mailing worm of 1999, after Happy99 in January and Melissa in March.
This one is materially worse. I want to write about it because the trajectory of these things matters more than any individual specimen, and because the operational response — the fact that we are seeing a third one in six months and the first systemic responses are still emerging — is itself the lesson.
What ExploreZip does
The worm arrives as an email attachment. The mail typically appears to be from a known contact and reads something like: I received your email and I shall send you a reply ASAP. Till then, take a look at the attached zipped docs. The attachment is zipped_files.exe and presents itself, with a deliberately deceptive icon, as a WinZip self-extracting archive.
If the user runs the attachment — and the icon is calculated to make this look reasonable — the worm does several things at once:
Propagation. Like Melissa, it uses MAPI to send copies of itself to recent correspondents. Unlike Melissa, it does not stop at 50 addresses; it sends to every recent contact in the user's mail, on every reply received, persistently for as long as it remains installed.
Payload. Here is where it gets nasty. ExploreZip walks the local filesystem and zeros out files of certain types — Word documents, Excel spreadsheets, source code (.c, .cpp, .asm), PowerPoint, and a handful of others. The files are not deleted; they are overwritten with zero bytes, retaining their names but becoming empty. This is a deliberately hostile payload: it appears to leave the file system intact but quietly destroys the actual data.
Persistence. The worm copies itself to C:\WINDOWS\SYSTEM\Explore.exe and modifies the WIN.INI run= line so it starts on every boot.
Network propagation. This is the new thing. ExploreZip will, over a network, copy itself to other Windows machines via SMB shares it can write to, modifying their WIN.INI files in the same way. Any reasonable corporate Windows network has plenty of writable SMB shares. The worm uses them.
Why this is the trajectory I worried about
When I wrote about Melissa in March, I observed that Melissa's payload was essentially decorative and that the next variant would have a more aggressive payload. That prediction has come true in three months.
What I did not predict was the network propagation. Melissa was strictly email-borne. ExploreZip is email-borne and SMB-borne in parallel. This means the perimeter mail relay is no longer the only chokepoint. Even with perfect mail filtering, an internal infection can spread laterally via SMB shares, infecting machines whose users never opened a malicious attachment.
This is structurally worse for two reasons.
First, the lateral spread inside an organisation is invisible to the perimeter. If your defences are perimeter-focused — and most organisations' are — you have no insight into the internal spread. The worm replicates inside your network for hours or days before anyone notices.
Second, the lateral spread is fast. SMB is a high-bandwidth, low-latency protocol on a corporate LAN. A worm propagating over SMB can hit hundreds of machines in minutes, not hours. The window for response is correspondingly smaller.
What can be done about it
For mail filtering, the same advice as after Melissa applies and is now non-optional:
- Strip executable attachments at the relay.
.exe,.scr,.pif,.com,.bat,.vbs— every executable extension. There is no legitimate use of these as email attachments that cannot be served by a different mechanism. - Run a virus scanner at the relay, with signatures updated daily. The signature for ExploreZip will be available within hours of you reading this.
- Subject-line and content filtering for known patterns. This is short-term effective; the next variant changes the patterns.
For SMB-based lateral spread, the answers are harder.
- Tighten share permissions. Most shares on most networks are writable by far more users than need write access. Auditing and reducing share permissions is tedious work and much overdue.
- Disable null-session access to shares. Many Windows configurations allow anonymous access to shares; this is a propagation vector for any worm that does not authenticate.
- Network segmentation. A flat corporate network is an enormous attack surface. Putting workstations in their own subnet, and applying ACLs between subnets, limits the reach of a worm that gets in.
- Detection on the inside. Snort sensors on internal segments, watching for SMB-related activity that does not match normal patterns. This is uncommon and operationally heavy. The sophistication of the worms suggests it is becoming necessary.
Where this leaves the threat model
The pre-1999 threat model for email-borne malware was essentially: infected attachments arrive, users open them, antivirus scanners catch most of them, the few that get through cause local damage to the affected user.
The post-Melissa, post-ExploreZip threat model is: worm arrives by mail; propagates by mail to the user's full address book; propagates internally over SMB without further user action; corrupts data on every infected machine; defeats per-host antivirus until signatures catch up; defeats perimeter filtering once inside the network.
This is a different category of problem. The defences that were sufficient last year are no longer sufficient.
My personal data point
I run a small Linux mail relay for friends. I am not seeing Windows-side spread. The friends I support all run mail clients that do not auto-execute attachments. I know of one second-degree contact whose corporate mail was hit; their organisation lost several days of data and is still recovering on the workstation side, although the infrastructure (mail servers, file servers) was unaffected because of platform diversity.
The platform-diversity defence is real. A homogeneous Windows estate is exactly what these worms are designed for. A heterogeneous estate, with Linux mail relays and Linux file servers and a non-Windows directory service, presents a much smaller surface for self-propagating malware. This is not a comprehensive defence — Linux desktops are coming; the next worm could target them — but it is a structural advantage that the ones we have now do not exploit.
For anyone running a homogeneous Windows network, the next 18 months are going to be harsh. The worms are getting better, the response time of antivirus vendors is finite, and the perimeter is no longer the right place to put the entirety of the defence.
My continued advice: strip executable attachments at the gateway, regardless of inconvenience to users. The trade-off has shifted decisively. The user friction is small; the alternative is being infected.