July 8, 2011

Analysis of recent threat statistics gives an impression that modification of the boot record to infect a system is a new trend among virus makers. Yet here Trojan.Mayachok.2 is a special case. It infects the Volume Boot Record and disrupts operation of popular browsers.

Infection process

Prior to the attack on a computer the malicious dropper checks if the system has already been compromised. It uses the system volume serial number to generate the CLSID and checks if it is already present in the Windows registry. If there is no corresponding section in the branch HKLM \ Software \ Classes \ CLSID , the infection process continues.

Under Windows Vista and Windows 7 the Trojan horse attempts to elevate its privileges. For this purpose the program employs a rather primitive method that has repeatedly been used by other malware. It constantly restarts itself and requests elevation of privileges. Experienced users can end such annoying processes easily over the Task Manager.

The dropper incorporates 32- and 64-bit versions of the driver that will download the main malicious payload. The version compatible with the system is saved to the hard drive. It can be written at the disk's beginning (before the first active partition) if there is enough free space available or at its end. There is an obvious flaw in the Trojan horse's logic. If the first partition is not a boot partition, the malicious driver can overwrite data in any partition before the boot partition because the Trojan horse picks out a sector to write the data to at random from the number of sectors it assumes to be free.

Only when this is done, the Volume Boot Record is modified. The malicious program won't infect the system if the partition's file system is not NTFS. It analyses the boot record to find a suitable place where it will overwrite existing code. The original code is compressed with aplib (http://www.ibsensoftware.com) and is written onto the disk after the malicious code. The number of the first sector on the disk where the driver has been saved earlier and its size are also written to the compromised VBR.

It should be noted once again that the infection mechanism is quite unusual. Viruses modifying MBR and boot sectors existed even under DOS and modern operating systems provide new opportunities for virus makers too. In our case the boot sector is the first VBR sector which occupies 16 NTFS sectors. So the conventional MBR scan fails to expose a malicious object since it is located in the VBR.

Once the system is infected, Trojan.Mayachok.2 saves a small application for rebooting the system on the disk. It is also worth mentioning that another bootkit—Trojan.Hashish—behaves similarly. At the end the Trojan horse tries to cover its tracks and removes itself.

Launch from VBR

Once the malicious loader gains control over the system, it follows the course of action standard for MBR/BOOT-viruses. It takes a small "chunk" of the system memory, moves its code into the memory, intercepts the int 13h interrupt to review the contents of the boot sectors read from the disk. It then loads the entire driver from the disk and unpacks the original VBR code to the former driver location. Control is returned to the system loader.

Next comes a series of sets and removals of hooks in loaded modules, such as ntldr, bootmgr, osloader.exe, winload.exe, etc., depending on the operating system loader. It should be noted that in addition to the usual interceptions (splicing) it also utilizes hardware debug registers (dr0-dr7) and code tracing (step-by-step execution). It provides versatility for the Trojan horse and also works as a natural way to bypass the integrity protection of some boot modules. As a result, the ready to go viral driver is loaded into the kernel mode memory.

Boot driver

The exit point for the virus driver is called twice.Since the viral VBR code only occupies 2078 bytes, the Trojan horse’s authors decided to implement certain features in the driver body. Upon the first call it adds itself to the LOADER_PARAMETER_BLOCK list, that is it gets itself onto the LoadOrderList as a copy of the first module (which is the OS kernel) and onto the BootDriverList as a boot driver that supposedly has an entry at \Registry\Machine\System\CurrentControlSet\Services\null. So the malicious program ensures that it is loaded as an ordinary boot driver.

For the second time the driver is invoked by the operating system that believes that it has loaded it. These manipulations lead to certain side effects.

For instance, the null driver appears in the system but a closer inspection reveals that it has been created by the kernel (ntoskrnl.exe).

At the same time there is another kernel among the loaded modules in which the SizeOfImage and DllBase parameters belong to the malicious driver.

To quickly check if the system has been compromised by the malware, you can use the simple command «echo hello> nul», which is executed successfully in a healthy system but in a compromised system an error is returned.

The driver's objective is to inject its code into the running processes.

Injection is carried out by setting notifications with PsCreateProcessNotifyRoutine and PsCreateProcessNotifyRoutine and then by calling the asynchronous routine through APC. The analysis shows that the 64-bit driver "carries" two libraries. The payload is incorporated only into one of them, while the scond library is apparently meant for future use.

The rest of the driver is not particularly interesting. To date, the routines used by Trojan.Mayachok.2 for infestation are unique among the known threats. Doctor Web's virus analysts expect that other malicious programs will adopt these routines in the near future.