Backdoor:WinNT/Rustock.gen!B

Backdoor:WinNT/Rustock.gen!B is a component of Win32/Rustock - a multi-component family of rootkit-enabled backdoor trojans, which were historically developed to aid in the distribution of 'spam' e-mail. First discovered sometime in early 2006, Rustock has evolved to become a prevalent and pervasive threat. Recent variants appear to be associated with the incidence of rogue security programs.

Normally the trojan consists of 3 components which are embedded within each other - the dropper (which runs in user mode), the driver's installer, and the actual rootkit driver, (both of which run in kernel mode). All of the trojan’s components are encrypted, and the actual driver component is also packed with plib.

 

When executed the dropper checks if the rootkit is already active.  There are a number of global events which Rustock uses to determine whether it is already present. We have observed it setting the following:

 

(Note that this list is not exhaustive.)

 

The dropper facilitates updates and the deployment of the rootkit’s driver installer. The installer is first decrypted, and then dropped and loaded as a system driver. The rootkit’s dropper might attempt to disguise the driver’s installer as a legitimate, but rarely used, system driver.

 

For instance: Rustock may stop the “beep” service or “null” driver using Service Control Manager (SCM), overwrite <system folder>\drivers\beep.sys or null.sys with the rootkit loader, and then reload the “beep” or “null” drivers.  If unsuccessful, the file name of the dropped installer will normally be either hardcoded or randomly generated (depending on the Rustock variant), as in the examples listed below:

 

Some Rustock variants drop the installer using the \\127.0.0.1\admin$\system32\drivers\<drivers name.sys> path, attempting to further complicate real-time rootkit identification and detection. Earlier variants of the Rustock family also used alternative streams to store the installer (for example System32:lzx32.sys) but this technique was dropped in favor of the stealth mechanism provided by system services hooking.

 

The registry is set to reflect the presence of the rootkit driver installer on the system. For example, if the driver installer is 7005d59.sys, the following modifications would be made under the following registry entry:

 

the following keys are set:
ImagePath = \SystemRoot\System32\drivers\7005d59.sys
Type = 1
Start = 1
ErrorControl = 1

Once the driver installer is loaded it launches the rootkit driver. The rootkit installer decrypts and then decompresses the actual code of the rootkit driver (the driver’s code is packed with aplib), injects the copy of the driver into itself, and transfers execution to the code of the rootkit driver. Such complexity is aimed at further complicating the detection and analysis of this rootkit.

 

The rootkit driver hooks system functions to further hide itself and the components of the rootkit from detection.  The driver checks for the presence of the global event to check if an instance of the rootkit is running, and creates one if it doesn’t already exist.

 

The driver patches the System Service Dispatch Table (SSDT), hooking the events ZwCreateEvent, ZwCreateKey, and ZwOpenKey. This makes it possible for the driver to filter requests containing the driver’s name and return STATUS_UNSUCCESSFUL if matched, ultimately avoiding detection by AV and other monitoring software.

 

In an attempt to further hide the network and disk I/O operations as well as its functional activity, the driver hooks the set of ntoskrnl.exe and ntdll.dll API’s and communicates directly with NTFS and TCP/IP devices such as NTFS, IP, TCP, Udp, RawIP and IPMULTICAST.