Details
I-Worm.ZippedFiles (a.k.a. ExploreZip)
This is a virus-worm spreading via the Internet and local network. Usually it appears as a “Zipped_Files.Exe” file attached to an e-mail. This file itself is a Delphi executable file about 210Kb in length. Most of the file’s code is occupied by Delphi run-time libraries, data and classes, and just about 10Kb of code is “pure” worm code.
Upon execution, it installs itself into the system, then sends infected messages (with its attached copy) to addresses found in the e-mail Inbox. To hide its activity, the worm displays the following message:
Error
Cannot open file: it does not appear to be a valid archive. If this file is
part of a ZIP format backup set, insert the last disk of the backup set
and try again. Please press F1 for help.
Installing into the system
To install into the system, the worm copies itself to the Windows directory with the _SETUP.EXE name, and to Windows system directory with the EXPLORE.EXE name, for example:
C:\WINDOWS\_SETUP.EXE
C:\WINDOWS\SYSTEM\EXPLORE.EXE - not “EXPLORER.EXE”!
The worm then registers its copy in the Windows configuration files to force the system to execute it each time Windows starts up. To do this, the worm writes a “run=” instruction to Windows configuration files that points to one of the worm files - _SETUP.EXE or EXPLORE.EXE. Depending on the Windows version, this registration process can be made by Windows in two different ways: The worm registers itself either in a WIN.INI file (under Win95/NT), or in the system registry (in case of WinNT).
In the case of Win95/98, the WIN.INI file [windows] section is updated with a “run=” instruction:
WIN.INI file:
[windows]
run=[worm file name]
In the case of WinNT, the same registration procedure affects the registry key:
HKEY_CURRENT_USER
Software\Microsoft\Windows NT\Current Version\Windows: run=[worm file name]
Depending on the worm “status” and system conditions, the worm selects its file name from one of two possible variants - _SETUP.EXE or EXPLORE.EXE. It then may replace an existing value with a second one, and then return to the first name. So, there may be two variants of a “run=” instruction found:
run=_setup.exe
run=C:\WINDOWS\SYSTEM\Explore.exe or run=C:\WINNT\SYSTEM32\Explore.exe
The Worm in the System Memory
The worm then (being registered in the system) stays “memory resident,” and is active up to the moment the system shuts down. The worm’s task has no active window, and is not visible in the taskbar, but is visible in the task list (Ctrl-Alt-Del) with one of the names the worm uses to name their copies:
Zipped_files
Explore - not “Explorer”!
_setup
The worm does not check its copy already presented in the Windows memory, and as a result, there may be several worm instances found.
Being active as a Windows application, the worm runs four threads of its main process: the installation thread that copies worm files to the Windows directories and registers them, the Internet spreading thread and two file destroying threads.
Spreading by E-mails
The second, and most important, thread sends e-mail messages using any e-mail system based on standard MAPI (Messaging Application Program Interface) - MS Outlook, MS Outlook Express, etc. The worm knocks the installed e-mail system four times trying to log on with different MAPI profiles: a default one, Microsoft Outlook, Microsoft Outlook Internet Settings, and Microsoft Exchange.
Being connected to an e-mail, the worm monitors all arriving messages - in an endless loop, it scans the Inbox for messages, and replies to them. The reply message has the same Subject with a “Re” prefix, and the message body appears as follows:
Hi [recipient name]
I received your email and I shall send you a reply ASAP.
Till then, take a look at the attached zipped docs.
The message ends with one of two signature variants depending on the worm’s success in locating the “sender name” in the e-mail fields:
bye.
sincerely [sender name]
The worm copy is attached to the message with a “Zipped_Files.Exe” name.
The worm does not reply to messages twice, and does not reply to its own messages. To detect already-infected messages, the worm marks them with a TAB character at the end of the Subject string. Each time the worm scans the Inbox for messages, it obtains the Subject field, goes to its end, and skips over the message if a TAB is found there. The worm also does not reply to all messages in the Inbox - only to unread messages.
It is necessary to note that both these conditions–replying to unread messages only and not replying to the same message twice–are optional in the worm’s infection routine. In the known worm version, both of them are hard-coded in the aforementioned way, but it is possible that the next worm version will answer all messages in the Inbox each time the worm infection thread gains control.
As a result, the process appears as follows: When the worm starts for the first time on a computer, it sends infected messages by using all unread messages found in the Inbox; it marks them as “infected” by using a TAB character and does not infect anymore; when a new message is received from the Internet and appears in the Inbox, it is immediately “answered” by the worm with the fake text shown above.
Spreading to a Local Network
The worm is able to spread over a local network, and is able to infect remote computers in the case when the Windows directory there is shared for reading and writing (full access). To do this, it enumerates network resources (shared remote drives), and looks for an WIN.INI file in there. In case this file is located, the worm copies its _SETUP.EXE file to this directory and modifies the configuration file there so that Windows on a remote computer will execute the worm file upon the next rebooting (see “Installingall” above).
Payload
The worm has an extremely dangerous payload. Each time it is executed, it runs two more threads that scan directory trees on the local and network drives; look for .C, .H, .CPP, .ASM, .DOC, .XLS, and .PPT (program source and MS Office files) and zeroes them. The worm uses a create-and-close trick that erases file contents and sets file length to zero. As a result, the files become unrecoverable.
As it is mentioned above, there are two file-killing threads: the first is active whenever the worm copy is active in the system until shutting down. In an endless loop, it scans all available drives from C: to Z: and corrupts the files listed above. The second thread is executed only once. It enumerates network resources (shared remote drives), scans them for the same files and also destroys them.