W32/Zimuse

Abstract

Zimuse is a family of worms that performs destructive overwrites of the Master Boot Record of disk drives on the infected system. If the current system date and time matches certain conditions, the worm overwrites the Master Boot Record of available drives with its own data. The worm will also try to delete some of the important files of the Windows Operating system. The file is run-time compressed using PECompact arrives on the system either as a standalone file (possibly from a malicious download or e-mail) or by infected removable devices (e.g., USB sticks).

Detailed flow of infection

First we start with the analyzing the main .exe file. The icon of the malicious file look like a legitimate IQTest.exe file as shown in the fig.1,

Fig.1 Icon

When we execute the file it creates a directory named ‘C:\IQTest’ wherein it contains only 2 files named IQTest.exe and Readme.txt as shown in the fig.2.

Fig.2 Folder IQTEST

When we execute the Iqtest.exe file it loads an IQ test in Slovakia language and it looks as shown in fig.3 and fig.4,

Fig.3 Introduction to IQ Test

Fig.4 Questions of the test in Slovakia

The original file makes a mask of the above IQtest software and in the background it starts its work. Let’s start analyzing the file, we can observe in the below shown fig.5 that the original file is packed with PECompact packer. So the first thing we need to do is to unpack the file manually and start analyzing the unpacked file.

Fig.5 File packed with PECompact

After unpacking the file we will get the file which contains two partitions in it. One is the malsious activity and another is the legitimate IQ Test. The main executable is a passenger to the malisious .sys, .exe and .dll files. It creates the basement for these files and makes them to do all the malicious activity. Let’s look how it creates the files, registry entries and runs services. First it creates the thread and after that it creates all the files as shown in the fig.6 and fig.7.

Fig.6 creates files

Fig.7 creates file and run entry for Dump.exe

The below shown fig.8 and fig.9 shows creation of the thread by the file zimuse.exe and creating Run entry for the file Dump.exe to run the malware every time the system boot up.

Fig.8 creation of thread

Fig.9 run entry for dump.exe

The malware first creates all the files and is shown in the fig.10 and fig.11. Some of the file which it creates uses temporarily and deletes it as and when it’s not usable. We can see clearly in the fig.10 that it creates some files in %temp% folder and after usage it deletes it.

Fig.10 creation of files

Fig.11 creating .sys file

After creating the files the next thing is to load the files, like the .sys files are loaded as drivers by creating the services for it, and some are loaded as processes. Fig.12 shown below shows the detail flow of the creation of the service. First it opens the service manager by using ‘OpenSCManagerA’ API. Next calls the subroutine ‘Service_entry’ wherein it opens the service and controls the service. Before this there is a call to the subroutine wherein it creates the service and starts the service as shown in the fig.13.

Fig.12 Service

Fig.13 service creation and start

In the below shown fig.14, we can see the running services of Mstart.sys and Mseu.sys.

Fig.14 running services in the infected machine

The malware also creates the registry entry for the services which has been initiated as its instance run every time this can be seen from the fig.15 and fig.16.

Fig.15 Registry entry for Mseu

Fig16 Registry entry for Mstart

The next thing is the mseus.exe file which is running as hidden process and can been seen as shown in the below fig.17.

Fig.17 hidden process mseus.exe

The malware also creates a .dll file named Tokset.dll and a .inf file called ainf.inf, the .dll files will not be hooked to any other process rather it’s the malware original copy and can be seen in below fig.18. It just places in ‘%windir%\system32’ for further usage. As the malware propagates through USB drives, it will create an autorun.inf and a .exe file is created using this tokset.dll file.

Fig.18 creation of .dll and .inf

After completion of the basic setup to run the other files which will do malicious activities. The malware will continue running of those files by deleting the temporary files. The below shown fig.19, says that the malware deletes the files which has been created for temporary usage. Here call to the subroutine ‘Get_path_Delete_file’ deletes the specific file which has been file is sent as an argument to it.

Fig.19 delete file

Master Boot Record (MBR) Overwriting

Zimuse worm will drop an mseus.exe which will run as a hidden process in the system as shown in the fig.15. This file will have main control over all the malicious activities in the infected system.

Short for Master Boot Record, a small program that is executed when a computer boots up. Typically, the MBR resides on the first sector of the hard disk. The program begins the boot process by looking up the partition table to determine which partition to use for booting. It then transfers program control to the boot sector of that partition, which continues the boot process. If this part is made rewritten with zero the system will not be able to reboot. This malicious activity is done by this mseus.exe file.

In this first it accesses the physical drive using ‘CreateFile’ API. It will open the existing file. It sets the file pointer to zero using the ‘SetFilePointer’ API. Now after accessing the physical drive and setting the file pointer to zero it will write the file with zero as shown in fig.20. This is the way it tries to change the MBR. But these changes will not happen at the time of infection, rather after infection it waits for some time and will change the MBR.

Fig.20 changes to Physical drive

When we compare the MBR using some utility we can easily differentiate the difference as shown in the fig.21 and fig.22. The master boot record will be the one which u can see in the fig.21 and the malware overwritten MBR is shown in the fig.22

Fig.21 clean MBR

Fig.22 replaced with zero’s

So after changing the MBR system will not be able to boot next time when the user restarted and it will give the message operating system not found message as shown in fig.23.

Fig.23 operating system not found

As soon as the MBR is changed, the malware pops up a message to the user as shown in the fig.24.

Fig.24 Kernel error message

The same can be seen as show in fig.25, here it also says that it will also make an beep sound when it pop up the message box.

Fig.25 creating message box

This file will also creates an service called unzip service as shown in the fig.26,

Fig.26 creating unzip service

Method of Propagation

Autorun.inf files outbreaks are the result of lax security restrictions on network drives and shares. The worm copies itself to the root of all available network drives, subsequent users visiting the same location will Autorun the file and thus continue to spread the infection to other network resources. The other predominant infection method is via USB pen drives. This is typically how such an infection is brought into an organization.

First the malware searches for the all the physical drives existing in the system from C to K alphabetically as shown in the fig.27 to fig.30.

Fig.27 C Drive

Fig.28 D Drive

Fig.29 E Drive

Fig.30 F Drive

In the above figures, Subroutine ‘Find_Drive_Type_write’ will check for the driver type and searches for the malware file Zipsetup.exe using the API ‘FindFirstFileA’, if the file found then it will copies the ainf.inf and creates autorun.inf. If a Zipsetup.exe file is not found then the malware will copy the tokset.dll and creates zipsetup.exe and copies ainf.inf to autorun.inf.
Deleting the files

The malware may also attempt to delete some of the system directories of all the existing drives like system volume information, my documents, documents and settings, system32. Some of the files like BOOT.INI, NTDETECT.COM, NTDLR, HYBERFILE.SYS, BOOTMGR.BAK and BOOTSECT.BAK. This can be seen in the below shown fig.31 and fig.32,

Fig.31 tries to delete some folders

Fig.32 tries to delete some files and folders

Conclusion

The method of infection is of old style but it’s very powerful, as because the malware will not allow to the system after some days of infection. But the malware will not download or upload any data from the system. This shows that the malware was not written for any financial use. As it hides the processes and the drivers dropped it’s difficult to find it also.

References

http://www.threatexpert.com/report.aspx?md5=63a6a43f94c06334e3b9249d374b8114
http://www.f-secure.com/v-descs/worm_w32_zimuse_b.shtml
http://www.symantec.com/security_response/writeup.jsp?docid=2010-012301-1138-99

By Santosh.S.M