Hard-to-detect PE_VIRUT variants, with their entry point obscuring (EPO) techniques, created quite a buzz this April. Before PE_VIRUT stole the scene, however, there was another file infector that may not have made as much noise as PE_VIRUT, but had an infection routine that can rival Virut's in its complexity. Detected in the wild last February, PE_DARKSNOW employs old, new, and borrowed tactics enough to keep threat analysts on their toes.

Something old

Like most file infectors, Darksnow spreads via removable drives or via infected files shared or downloaded from the Internet. To propagate via removable drives, it creates a WindowProc function that intercepts window messages. The said function waits for the window notification WM_DEVICECHANGE with the extended parameter DBT_DEVICEARRIVAL before it can be triggered. The message WM_DEVICECHANGE with DBT_DEVICEARRIVAL signals the presence of a new device and that the device has just been connected. Once Darksnow's created WindowProc function detects the said message, it drops a copy of this file infector along with an autorun.inf in the connected removable device. Thus, when the device is accessed, Darksnow's copy is automatically executed. All EXE, XLS, and DOC files saved on the target device are also infected with Darksnow.

Upon execution, PE_DARKSNOW checks for the existence of its main executable blackice.exe in the Windows system folder. If it does not find blackice.exe, it drops a copy of the said file and an auxiliary copy named kernel.dll in the mentioned folder. If the executable file already exists, Darksnow checks if it is running and overwrites the existing file if it is not. The file creation date of its dropped copy is set to January 12, 2002, 1:00 AM to avoid suspicion.

The auxiliary copy kernel.dll is not just an idle file. It is a tactical component in Darksnow's perpetual execution. The file infector creates a watchdog thread, which it injects into the processes explorer.exe and taskmgr.exe. This thread continually checks the two processes to see if blackice.exe is running. If the thread finds that it is not, it creates and executes a new malware copy from kernel.dll.

As part of its goal of continued execution, PE_DARKSNOW monitors and guarantees that its EXE is referenced in the Windows initialization files win.ini and system.ini by creating the following entries every five seconds:

In WIN.INI

[windows]
Run=%system%\blackice.exe

In SYSTEM.INI

[boot]
Shell=Explorer.exe %system%\blackice.exe

While this particular routine already assures automatic execution of blackice.exe at every system startup, it also makes sure that if the EXE is deleted, a new one is sure to replace the removed copy.

Darksnow employs old-fashioned macro virus tactics. Like most macro virus infections, it first lowers the security settings of MS Word and MS Excel to allow macro execution in the global templates (Normal.dot for Word; book1.xlt and book1.xls for Excel). It does this by modifying the following registry entries:

HKEY_CURRENT_USER\Software\Microsoft\
Office\{MS Office version}\Excel\security
Level = "1"
AccessVBOM = "1"

HKEY_CURRENT_USER\Software\Microsoft\
Office\{MS Office version}\Word\security
Level = "1"
AccessVBOM = "1"

This file infector then reconstructs in memory the embedded VBA (Visual Basic for Applications) code in the global templates plus an image of its EXE into base64 encoding so that they are all converted into pure text. Doing so enables the malware EXE to fuse with the global template's VBA script. This part of the malware's technique is simple yet effective, since new XLS or DOC files are automatically infected as soon as they are created. Moreover, each infected XLS and DOC file carries a copy of the mother file infector, enabling further infection upon their execution.

There is nothing new in all of the routines already mentioned. Numerous file infectors and other malware types have already used them time and again. This shows that while PE_DARKSNOW employs a rare infection technique that is discussed in the succeeding section, it still manifests some fairly predictable behavior.

Something new

Though it ensures the infection of subsequently created DOC and XLS files, the infection of existing system files is still Darksnow's "main event". Before starting infection, PE_DARKSNOW checks if the day is Tuesday, Thursday, or Saturday. If the day does not match any of the three, it skips its file infection routine and exits. The possible reason behind this action is to keep a user guessing as to when Darksnow really executes.

Darksnow enumerates and searches for XLS, DOC, and EXE in the drives and subfolders of the infected system. It does, however, avoid infecting files in the folder where it is currently executing, in the parent folder (if any) where the current folder is under, in the WINNT folder, and in the Windows folder. It also avoids infecting files with the file name blackice.exe. Incidentally (or not), blackice.exe is also the name of a legitimate firewall application process file. Thus, by avoiding infecting a known security program file it also avoids easy detection.

For DOC and XLS files, Darksnow injects a macro code that drops and executes the malware executable whenever the infected document is opened. For EXE files, Darksnow begins infection by updating and adding the resource section of the file using hardcoded values 0x1e79 Resource Name and 0x1f45 resource type, in effect allocating new resource space for a new type of data. Normally, the resource section of an EXE file holds data necessary for file execution (i.e. ICONs, embedded files, data-blob, etc.) and that an entry point defines each of these data. After doing this, it maps the target host to memory and, at the same time, queries if the name of the last section is already blackice. This last section also serves as an infection marker. If blackice already exists, Darksnow skips infecting the file. If it finds no marker, it creates blackice and writes its dropper routine on this section. This dropper routine refers to the ability to drop and execute this malware. Moreover, Darksnow modifies the entry point of the target host such that its dropper routine is called first before the host file is executed. Once all these steps are completed, the main malware file is then written in the new allocated resource space in the target host.

The infection technique described above can neither be considered appending nor cavity. The malware code is not simply added in the host file, which characterizes an appending infection, nor is it inserted in free spaces within the host, which is the description of a cavity infection. Darksnow adds itself as an integral part of its host by creating a new resource entry that contains the malware code. Thus, Darksnow's code can be seen as another part of its host and not just an arbitrary code inserted or appended in the file.

This different kind of infection also called for a more creative solution on the part of TrendLabs' threat analysts. One should consider that file infectors, especially new ones like PE_DARKSNOW, always challenge AV's capability to create a solution that not only stops infection but also properly restores infected files back to their original state. Cleaning always carries the risk of damaging the infected file in the process. In view of this, cleaning files infected by Darksnow involves a combination of cutting and zeroing out the injected malware code as detailed by the steps below:

1. Go to the resource section.
2. Enumerate all resource entries in the resource directory to find the malware-added resource.
3. Once found, remove the resource entry from the directory.
4. Zero out the entire content of the malware-added resource.
5. Restore program entry point.
6. Remove the arbitrary code added to drop and execute malware from resource.

Something borrowed

Similar to recent strains of file infectors, PE_DARKSNOW is essentially a Web threat. Aside from the fact that it can arrive on systems via the Internet, one of its main routines is to download file from the Web. It gathers the host name, volume serial, and MAC address of the network adapter of the affected system. Then, it proceeds to download an INI file from two URLs. The downloaded INI file/s contain the new URL where the next file to be downloaded is located. The success of this download's execution routine results to the execution of another possibly malicious file on the system.

This two-step action prior to downloading the intended malicious executable gives Darksnow flexibility and the malware author the opportunity to employ server-side polymorphism by simply changing the content/s of the target executable or changing the URL link contained in one or both INI files. It should be noted that in downloading the initial INI, the stolen information mentioned above are also sent to the server, consequently making way for possible future attacks. Furthermore, PE_DARKSNOW can propagate via network shares, a propagation vector that more and more file infector families like PE_LOOKED and PE_FUJACKS are adapting.

Something (to be) blue (about)

PE_DARKSNOW is a product of the times. Its complex infection routine is a sign of the continuous evolution of malware sophistication. Its complex download routine echoes the trend of rising Web threat dominance.

Looking at the bigger picture, PE_DARKSNOW is just one of the many intricately-designed file infectors appearing recently. This trend is not a mere coincidence. With the way sophisticated variants of PE_LOOKED, PE_VIRUT, and PE_FUJACKS are turning up, it is not a stretch to suppose that file infectors are not just making a come back but may actually play key roles in the current threat arena.

Description created: May 31, 2007
By: Almira Lozada and Ace Portuguez