Some time ago while tracking Winnti group activity we came across an intriguing sample.

MD5
Size
Linker
Compiled on
2C85404FE7D1891FD41FCEE4C92AD305
241’904
10.00
2012-08-06 16:12:29

Property
Value
CompanyName
Microsoft Corporation
FileDescription
Net Command
FileVersion
6.1.7600.16385 (win7_rtm.090713-1255)
InternalName
net.exe
LegalCopyright
© Microsoft Corporation. All rights reserved.
OriginalFilename
net.exe
ProductName
Microsoft® Windows® Operating System

It was protected by a commercial VMProtect Win64 executable signed with a known compromised certificate from Chinese entity Guangzhou YuanLuo Technology. Moreover, the properties of the executable read as if it were Microsoft’s Net Command net.exe, and even running the sample also resulted in output typical of the original net.exe utility:

Masquerading as net.exe
All this pointed to the sample being rather suspicious.
Bootkit
Since the code of the program was protected, an analysis of its functionality would have been an arduous task. But luckily a dump revealed some unique and quite important strings and four more samples hidden inside the initial one: Win32 and Win64 versions of one library and one driver:

Strings in malware body
The strings led us to suspect that this sample was actually a bootkit installer. And thanks to some clear artifacts we found a similar sample but with no code protection that confirmed our suspicions.
First of all, let’s run this tool:

Original HDD Rootkit output
The program parameters are quite self-explanatory – this tool installs a bootkit that infects the operating system during the boot stage with an arbitrary backdoor specified as a parameter. The backdoor has to be a Win32 executable or dynamic link library.
This utility is called “HDD Rootkit”; hence the base of our verdict names HDRoot. On 22 August 2006 the version number was 1.2.
So, we can conclude that the protected version was the same utility modified for use on the victim side to avoid revealing the intent of the tool in case someone outside the intruders’ circle discovered it.
HDD Rootkit maintains a bunch of resources that also have quite telling names:

HDD Rootkit resources
As it reads:
“MBR” maintains the 1st piece of malicious code that is injected to the MBR of an infected computer;
“BOOT” – 2nd piece of malicious booting code;
“RKIMAGE” – 3rd piece of malicious booting code;
“DLLLOAD” – Dynamic Link Library that is pushed by the malicious booting code into the file system and OS autorun.
Let’s try running some executable with the help of a bootkit. In our experiment the role of the executable is played by a benign program that does nothing apart from create a file in the root of the C: drive. I will try to run it using the HDD Rootkit utility with the following command line:
hdroot.exe inst write_to_c.exe c:
telling it that I’d like to install a bootkit on drive C: that will make the program write_to_c.exe run on system startup.

Live installing of HDRoot bootkit
The utility checks the free space left on the specified drive and refuses to install the bootkit when the value is less than 30% of overall volume.

Free space check
So, now the bootkit has been installed. Let’s take a look at what has happened. First of all, part of the code in the MBR is replaced with a malicious one from the resource “MBR”:

“MBR” resource
The first 2 bytes EB 70 mean a jump to the 72nd offset where the rest of the 1st booting code block is located. The zeros before 0x70 and after 0xB0 mean the code of the original MBR at these positions remains intact. The following image represents a patched MBR after the bootkit is installed:

Injected malicious code in MBR
This first piece loads the next booting code block that has been placed by the bootkit installer in the 11th sector (Offset: 0x1400 bytes). The 2nd block is taken from the resource “BOOT”.

2nd booting block
The byte at 8th offset of the 2nd booting block is a drive number and the next DWORD is an offset in sectors where the next booting part is located. This example has the value 0x80, meaning drive 0 and the offset 0x5FD9A0, which if multiplied by 0x200 bytes (size of sector) results in 0xBFB34000. This is the offset in bytes from the beginning of the drive where the bootkit installer has put the 3rd booting block taken from its resource “RKIMAGE”.
The “RKIMAGE” resource has a large piece of code that implements a DLL injection (the DLL is taken from the “DLLLOAD” resource) into the file system and makes changes in the system registry so that DLL is loaded and run during system start-up. As that piece of code is executed at the early booting stage, there is no API for accessing the file system and the code parses the file systems (FAT32 and NTFS) on its own.

Supported file systems
It searches for the hardcoded special file whose content is replaced with the DLL taken from a specified place on the disk. Most versions of HDRoot that we have found and detected use the file %windir%WMSysPr9.prx for these purposes. Sometimes the DLL overwrites some existing system library which is certainly not a safe way for malware to work because it could cause OS failure in some cases and alert the user to the infection. Among other files that can be used for overwriting we have noticed:
%windir%twain.dll
%windir%msvidc32.dll
%windir%helpaccess.hlp
%windir%helpwinssnap.hlp
%windir%systemolesvr.dll
%windir%syswow64C_932.NLS
%windir%syswow64C_20949.NLS
%windir%syswow64dssec.dat
%windir%syswow64irclass.dll
%windir%syswow64msvidc32.dll
%windir%syswow64kmddsp.tsp
The code then reads the content of the file %windir%system32configsystem that maintains the content of the HKEY_LOCAL_MACHINESYSTEM registry hive. Among other things the registry hive contains information about installed services. There are numerous system services that are started during OS logon as ServiceDll via svchost.exe where the path to the functional library to be run is specified in the ServiceDll registry value for a particular service. The malicious booting code searches in the file “system” for the hardcoded path to a system library associated with a system service and replaces that value with the path to the injected DLL (for example, %windir%WMSysPr9.prx). In all the versions we encountered we found that HDRoot exploited the following services:

Internal service name
Displayed service name
Path to search for
wuauserv
Automatic Updates
system32wuauserv.dll
LanManServer
Server
system32srvsvc.dll
schedule
Task Scheduler
system32schedsvc.dll
winmgmt
Windows Management Instrumentation
system32wbemwmisvc.dll

So, when the operating system starts running services, instead of loading the original service DLL svchost.exe loads a malicious one. This malicious library does nothing apart from load and run a backdoor taken from a specified offset on the hard drive where the bootkit installer HDD Rootkit had placed it. We have found two versions of HDRoot with different methods of doing this. The first one just saves the backdoor as a file %windir%tempsvchost.exe and executes it with the help of the WinExec API function. By all appearances the malware author later decided that this approach is not the best way to run the backdoor because it is visible to AV products and the fact that the application has started may be noticed when inspecting events in the system logs. The other version of the DLL does not drop the file but allocates a read backdoor in memory, prepares it for proper execution (loads libraries according to the import table and fixes relocations) and runs it there on its own. This approach is much more clandestine as it substantially reduces the chances of discovering the backdoor even if the DLL or poisoned MBR are detected.
Returning to our experiment, when the command
hdroot.exe inst write_to_c.exe c:
has been run, we restart the operating system. After the OS has loaded we can see the result of running of our program write_to_c.exe, which behaves as though it were a backdoor:

Created test file zzz.bin
The file C:zzz.bin is seen immediately after Windows has loaded, which proves that the program write_to_c.exe has been successfully executed.
The whole process of the HDRoot infection is as follows:

HDRoot operation scheme
Interestingly, the malware does not have functionality to start the original service that was substituted during the boot process. Because the affected services are part of the OS, neglecting to do this could cause Windows to malfunction and reveal the infection. This is even stranger considering the malware does try to cover its tracks. Namely “tries”, because it fails to do so. The dropped DLL has a function to restore the original value of ServiceDll in the registry, storing the path to the DLL associated with the service. But due to flawed code in the 3rd booting block (from “RKIMAGE”), which slightly patches the content of “DLLLOAD” before injecting, DLL starts holding the wrong data at hardcoded offsets and it prevents the DLL from finding the proper registry path to ServiceDll to restore the original value. That’s why, for example, “C:WINDOWSWMSysPr9.prx” can still be viewed instead of “C:WINDOWSsystem32wuauserv.dll” after logging on to Windows:

Path remains to injected malicious DLL in registry

Wrong registry path and value name

Mistakenly overwritten registry SubKey with original value of ServiceDll
As a result, we have to conclude that the malware was not created very carefully, which is not what you expect from such a serious APT actor as Winnti. However, we have noticed the malware author’s efforts to make this bootkit work properly at the booting stage to avoid completely blocking the OS from loading. But the mistakes mentioned above leave some quite conspicuous signs of infection on the compromised computer. For example, original services such as Windows Update or Task Scheduler do not work, but it appears nobody noticed them.
During the investigation we found several backdoors that the HDRoot bootkit used for infecting operating systems. These malicious programs will be described in the next part of our article.
Source: Kaspersky