分类： 网络与安全
2011-08-19 17:19:43
In the two years since the Win32/Olmarik family of programs (also known as TDSS, TDL and Alureon) started to evolve, its authors have implemented a notably sophisticated mechanism for bypassing various protective measures and security mechanisms embedded into the operating system.
The fourth version of the TDL rootkit family (TDL4) is the first reliable and widely spread bootkit to target x64 operating systems (Windows Vista and Windows 7). Since TDL4 started to spread actively in August 2010, several versions of the malware have been released. By comparison with its predecessors, TDL4 is not just characterized by modification of existing code, but to all intents and purposes can be regarded as new malware. Among the many changes that have been applied as it developed, the most radical were those made to its mechanisms for self-embedding into the system and surviving reboot. One of the most striking features of TDL4 is its ability to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and Windows 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled. This makes TDL4 a powerful weapon in the hands of cybercriminals. In this article, we consider the PPI (Pay Per Install) distribution model used by both TDL3 and TDL4, and the initial installation.
Distribution by Pay Per InstallIn Aleksandr Matrosov and Eugene Rodionov described how the DogmaMillions cybercrime group distributed the third version of the TDSS (a.k.a. TDL, Olmarik, or Alureon) rootkit using a PPI (Pay Per Install) scheme. It’s both interesting and instructive to compare the ways in which TDL3 and TDL4 (as described in their more recent paper ) have been distributed.
The TDL3 rootkit droppers were distributed using a Pay-Per-Install (PPI) scheme popular among cybercrime groups. The scheme is, in fact, similar to schemes commonly used for distributing browser toolbars. Toolbar distributors have a special build with an embedded identifier which allows for calculating the number of installations associated with that ID and therefore for determining their revenue. The same approach is used for distributing the rootkits: information about the distributor is embedded into the executable and special servers are used to calculate the number of installations.
Anyone deciding to cooperate with the cybercrime group received a unique login and a password, identifying the number of installations per resource, like this:
The gang made use of a well-developed business infrastructure: for example, each affiliate had a personal manager who could be consulted in case of any problems.
Distributed malware was repacked every few hours (or even more frequently) using all-too-reliable and sophisticated packers and protectors in order to reduce the risk of detection by antivirus software, using sophisticated tools and techniques to detect debuggers and virtual machines. Partners were instructed not to check on whether the malware can be detected by AV by using resources like VirusTotal, and could even be “fined” for doing so.
You can see the user interface characteristic of one widely-used encryptor in the figure below. At that point, this was attracting a charge of around $500.
Figure 1 – User Interface of a Packer
The Dogma Millions cybercrime group set up in business in the autumn 2009, placing many advertisements on public forums offering “easy money”. However, it seems to have been somewhat uncomfortable with the copious attention it received last year, and shut down in the fall. Major affiliates to DogmaMillions could earn a cool $100,000 daily, so it’s no surprise that TDL4, the latest generation of TDSS, quickly found similar distribution channels.
GangstaBucks appeared at the end of 2010 and was widely advertised in various forums in Russia and elsewhere, offering very similar terms and features to DogmaMillions, and a very similar mode of expression.
Figure 2 – The GangstaBucks Adverts
Affiliates are able to download the current version of the Trojan downloader and to receive statistics relating to detection by antivirus software. This serves to dissuade the partner from submitting the current version to services such as VirusTotal that forward malicious samples to security companies.
Figure 3 –Scanning Samples for Detection by AV Software
When the downloader is known to be widely detected, the partner receives a newly-repacked sample, so that release/detect cycle begins again.
When the downloader is launched it sends information about the compromised system to a C&C (Command and Control) server and pulls down a secondary downloader which in turn downloads and runs the main malware. The sequence of download events for the downloader which we analyzed is depicted in the following figure. As we can see, the first downloader obtains Win32/Agent.QNF which downloads and installs either Win32/Bubnix or Win32/KeyLogger.EliteKeyLogger malware onto the system.
Figure 4 – The Downloader at Work
Downloader packers and links are changed every few hours, so as to minimize the risk of detection by malware installation tracking systems.
In the middle of February we received a downloader (Win32/TrojanDownloader.Agent.QOF) that installs the latest version of the TDL4 bootkit onto the system. During the installation of the bootkit, as we can see from figure 5, the downloader reports back to the server to register the installation with the partner identifier.
Figure 5 – Installation of GangstaBucks’s TDL4
When conditions are mutually beneficial, services like DogmaMillions and GangstaBucks can accumulate hundreds of partners. In such a case the number of sites all over the world distributing the malicious software can reach several thousand.
Bootkit InstallationThe installation of the bootkit is handled differently on x86 and x64 systems due to specific limitations on x64 platforms. As soon as the dropper is unpacked it checks whether it is running in Wow64 process and determines which branch of the code it should execute.
Figure 6 –Determining OS Version
On x86 systems the installation process looks the same as it does for TDL3/TDL3+, as described in an earlier paper (). To bypass HIPS the bootkit loads itself as a print provider into the trusted system process (spooler.exe) from whence it loads a kernel-mode driver (drv32) which infects the system.
The bootkit implements an additional HIPS bypassing technique which wasn’t noticed in TDL3/TDL3+ droppers: it hooks the ZwConnectPort system routine exported from ntdll.dll.
Figure 7 – Hooking ZwConnectPort
Here is the prototype of the function ZwConnectPort. Parameter PortName is set to the name of the target LPC port to connect to.
The routine is called during execution of AddPrintProvidor to connect to the print spooler LPC port. As shown here the hook prepends to the target port name “\??\GLOBALROOT” string in an attempt to connect to the print spooler service.
Figure 8 – The Code of ZwConnectPort Hook
When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, after which it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper by means of the CreateFile and WriteFile API functions.
The algorithm for infecting x86 operating systems is presented in Figure 10. It is important to mention that the TDL4 dropper exploits the now-patched MS10-092 vulnerability in the Microsoft Windows Task Scheduler service in order to elevate privileges and successfully load its own driver. The vulnerable systems include all Windows operating systems starting from Microsoft Windows Vista (both x86 and x64 versions). If it fails to exploit the vulnerability it copies itself into a file into TEMP directory with the name “setup_xxx.exe” and creates a corresponding manifest file requesting administrative privileges to run the application. After that, it runs the copied dropper by calling ShellExecute and a dialog box message requesting administrative rights is displayed to the user.
Figure 9 – The Algorithm of Infecting x86 System
When the dropper is run on x64 operating systems it is unable to load the kernel-mode driver, as 64-bit systems require it to be signed. To overcome this restriction the dropper writes all its components directly to the hard drive by sending IOCTL_SCSI_PASS_THROUGH_DIRECT requests to a disk class driver. It obtains the disk’s parameters and creates the image of its hidden file system in the memory buffer which is then written onto the hard drive at a certain offset. We’ll discuss the way in which the hidden file system is maintained in a future article, but an earlier article for Virus Bulletin () is also relevant to the discussion. When the image is written the dropper modifies the MBR of the disk to get its malicious components loaded at boot time. After that, the dropper reboots the system by calling the ZwRaiseHardError routine, passing as its fifth parameter OptionShutdownSystem. This instructs the system to display a BSOD (Blue Screen Of Death) and reboot the system:
In the next figure we present a diagram depicting process of infecting x64 system.
Figure 10 – The Algorithm for Infecting x64 Systems
The bootkit’s components are contained inside the “.config” section of the dropper (the layout of the section is described below as detailed in our report on TDL3).
The rootkit dropper is encrypted. The decryption routine is slightly obfuscated and varies between different droppers. During unpacking, the dropper performs some simple anti-debugging checks and also checks that it isn’t running inside a virtual machine. The next figure shows the structure of the dropper.
Figure 11 – The Dropper Structure
Here is the list of modules that are dropped into the hidden file system:
| Dropped modules | Description |
| mbr | original contents of the infected hard drive boot sector |
| ldr16 | 16-bit real-mode loader code |
| ldr32 | fake kdcom.dll for x86 systems |
| ldr64 | fake kdcom.dll for x64 systems |
| drv32 | the main bootkit driver for x86 systems |
| drv64 | the main bootkit driver for x64 systems |
| cmd.dll | payload to inject into 32-bit processes |
| cmd64.dll | payload to inject into 64-bit processes |
| cfg.ini | configuration information |
| bckfg.tmp | encrypted list of C&C URLs |
Table 1 – Dropped Modules
Comparison with TDL3/TDL3+Here is the table summarizing the major differences between the TDL3/TDL3+ and TDL4 droppers which include bypassing HIPS, escalating privileges, installation mechanism and number of installed modules.
| |
TDL3/TDL3+ | TDL4 |
| Bypassing HIPS | AddPrintProcessor/AddPrintProvidor | AddPrintProvidor, ZwConnectPort |
| Privilege Escalation | - | MS10-092 |
| Installation mechanism | By loading kernel-mode driver | By loading kernel-mode driver,
Overwriting MBR of the disk |
| Number of installed modules | 4 | 10 |
Table 2 – Comparison of TDL Droppers
TDL4 and GluptebaAt the beginning of March 2011 we received another interesting sample of TDL4: this time, one that downloads and installs another malicious program, Win32/Glupteba.D. This was the first instance the authors had come across of TDL4s being used to install other malware. It is important to mention that this is not a plug-in for TDL4: it is standalone malware, which can download and execute other binary modules independently. A sample of Win32/Olmarik.AOV was obtained from a server at vidquick.info. After what looked at first like a standard TDL4 installation, at any rate by comparison with the most recent versions analyzed, Win32/Olmarik.AOV received a command from the C&C server to download and execute another binary file.
Win32/Glupteba.D uses the customary blackhat SEO (Search Engine Optimization) methods to push clickjacking contextual advertising as used by the ads network Begun (), which has a high profile in Russia. Clickjacking algorithms have been developed for crawling web sites pushing typical content for specified context ads. All the affected web sites are hosted by a single provider: “Masterhost.ru” is, in fact, the biggest Russian hosting-provider.
Figure 12 – the Masterhost.ru Empire
Network activity from Win32/Glupteba.D is shown in the following screendump:
Commands for Win32/Glupteba.D directed to the C&C server look like this:
In the in this series, we’ll consider the bot, kernel mode and bootkit functionality of the malware.
Incoming search terms: