This month we added a family of rootkit-enabled trojans to MSRT – Win32/Rustock
Win32/Rustock is 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. Recently we’ve seen it associated with the incidence of rogue security programs. This might indicate that the Rustock family of trojans has gained some traction as an efficient spamming tool and has been successfully utilized in money-making malware schemes.
Normally the trojan consists of 3 components which are embedded within a single binary (like a Russian Matryoshka, or stacking doll) – 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 aPLib.
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’ve seen it set the following:
(Note that this list is not exhaustive.)
This rootkit family is evolving. We’ve seen tweaks made to its polymorphic decryptors, to the size and names of the sections, and to the versions of compilers used. Perhaps these efforts are with one major goal in mind – to dodge pre-screening by AV engines and render available rootkit detections inefficient.
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. It is interesting to note that 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 %sysdir%\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 hardcoded or randomly generated (depending on the Rustock variant) and vary within the rootkit’s family. It is not uncommon to see it set to something obscure like glaide32.sys, or lzx32.sys or even randomly generated, such as 7005d59.sys, for example.
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, under the 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 the execution to the code of the rootkit driver. Such complexity is aimed at further complicating the detection and analysis of this rootkit. Roughly, the trojan’s lifecycle might be presented as shown below.
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.
It is interesting to note that with some variants of Rustock it is still possible to see the driver’s installer file inside the %system32%\driver folder. For instance, in the following case the file 7005d59.sys is still visible. When attempting to manually delete the Rustock driver component, the system behaves as if the file doesn’t exist (see below). This is a good tell-tale sign that the system might be affected by a rootkit and requires cleaning.
Despite the challenging intricacies of this rootkit’s system infiltration, it is successfully detected and removed by the October release of MSRT. 🙂