More rootkits - “good” and different. Part i

    Sometimes the differences in the writing style and applied principles of the operation of malicious software are significantly different from sample to sample. Some rely on polymorphism, others on the rootkit component. Especially in terms of rootkit technology development, the TDL family of malware (also called TDSS, Alureon, Olmarik, Tidserv) has distinguished itself. As you know, the new is the well-forgotten old. At the dawn of the development of personal computers, the bulk of malware was composed of viruses, which were divided into two classes - file and boot (there were also combined ones, for example, the infamous OneHalf ). A worthy successor to boot viruses is the bootkitTDL-4, although it is a Trojan (unable to spread on its own). A bootkit is a word formed from the words boot (boot, boot area) and rootkit (rootkit, a means of hiding signs of activity). But before becoming a bootkit, TDL has come a long way.

    TDL-1


    One of the first rootkit versions was discovered by Kaspersky Lab in April 2008, it saved its tdsserv.sys driver in the system, from which the name TDSS came from. Subsequently, the name of the main driver changed several times to clbdriver.sys, seneka * .sys, UACd * .sys, gaopdx * .sys, tdlserv.sys and others.
    The alternative name TDL was due to the presence in the code of numerous identifiers starting with the characters 'tdl'. The dropper TDL-1 contained two main files: the rootkit driver itself and the library, in which the main functionality was located (payload). At that time, the methods of intercepting functions were quite trivial and did not differ in innovation, but they allowed to bypass most anti-virus protection tools.
    The main masking functions implemented by the driver:

    • hiding registry branches;
    • hiding files on disk;
    • introducing malicious code into system processes from the kernel-mode driver;
    • hiding TCP network ports;
    • hiding loaded DLLs.

    Also, the driver is able to perform several other functions aimed at actively countering antiviruses:

    • destroy the stream;
    • block thread execution;
    • kill the current process;
    • Get the name of the current process
    • unload the driver;
    • Get a list of running processes.

    When installing the rootkit, the following technique was used to circumvent behavioral protection: malicious code is placed in the system cache of frequently used libraries \ KnownDLLS, from where it is called by a legitimate system application when it uses one of these libraries. Specifically, TDL-1 used the patch of the advapi32.dll library, loaded by the Microsoft Installer service, during the installation. Newer versions used the msi.dll library patch. Thus, the TDL-1 code was called from the context of a trusted application. You can learn more about the methods used by TDL-1 in Alice Shevchenko's post .

    TDL-2


    The installation took place according to the same first version of the TDL technique, while the msvcrt.dll library was patched. To complicate the detection of the rootkit driver, obfuscation and encryption mechanisms have been used. In particular, the binary code was “diluted” with random words from the work of “Hamlet” by William Shakespeare. Compared to the first version, the rootkit has changed little functionally, but the methods of concealment and protection have changed, which is probably due to the previous version getting into the anti-virus databases.

    TDL-3


    In autumn 2009, the third version appeared, containing many technical innovations. The workaround has changed, now it was the hijacking DLL method, its essence - the OS first looks for the necessary dll in the current directory, and then in the system directory, therefore, by placing a malicious library in the directory of the legitimate program with the name that matches the name of one of the imported libraries, you can achieve launching malicious code. TDL-3 copied itself as a library to the directory of the print processor, and then accessed it. This led to the execution of malicious code in the context of the system process.
    To gain control after a reboot, the method of infection of the system components of the OS (drivers) was used. The atapi.sys mini-port / port driver was used for infection; in later versions of TDL-3, it randomly selected and infected system drivers that were suitable for some parameters. A small piece of malicious code of 824 bytes (917 bytes for variants with random drivers) was introduced into the atapi.sys driver, which served as a loader, while the original driver size remained unchanged. The original data that was replaced was stored along with the main code in a specially allocated place at the end of the hard drive. The last few sectors of the disk were organized into a kind of encrypted data storage with its own file system, and a virtual device was created to work with it. This repository also housed blocks of configuration data. TDL-3 intercepted disk accesses and, in the case of viewing its “personal” sectors, returned their contents as a data block filled with zeros. The configuration data block (config.ini) is unchanged for all three versions; it contained the following data:

    [main] - identification data
    Quote - quotes from movies, cartoons, etc. that are displayed when the debugger is connected;
    Version - version;
    Botid - bot identifier for the admin panel;
    AffId - identifier of the "affiliate program";
    SubId - used to identify the bot network when the botnet is divided into several subnets;
    Installdate - date of installation in the system;
    Builddate - compilation date.
    [injector] - mapping of implemented modules and processes
    contains a list of pairs of values ​​of the form: process name (by default “*” means all processes) - name of the DLL (dynamic library that should be loaded to the specified process).
    [tdlcmd] - server data
    Servers - addresses of rootkit admin panels, usually three addresses;
    Wspservers - server addresses for working with search services;
    Popupservers - server addresses for opening pages;
    Version is the payload version.


    Distribution of TDL was carried out using the so-called "affiliate programs" or "affiliate programs." According to Wikipedia, “Affiliate program is a form of business cooperation between the seller and partners in the sale of a product or the provision of services; allows the seller to reduce the cost of attracting the end customer. " In the area of ​​cybercrime, the goods are malware, and the services are attracting users to infected web resources and infecting their computers. Money is paid for each successful installation. For this, the AffId field in config.ini is used in order to know who to how much to pay money for installing the bot with the given identifier. It also allows you to evaluate the performance of a particular affiliate program. For assistance in the distribution of TDL, the owners of affiliate programs receive from $ 20 to $ 200 for 1,000 malware installations, depending on the geographic location of the victim computer. Final installation could be done in various ways, for example, by installing fake codecs, by embedding a bot in keygens for popular software, or by distributingcvyazki exploits (exploit pack).

    Data was exchanged with the TDL management servers using the HTTPS protocol. For this, the attackers used a self-signed security certificate (which was located on the server) issued by the fictitious company Internet Widgits Pty Ltd. Using HTTPS did not allow antiviruses to detect and block network traffic by the contents of packets. In addition, in TDL-3 GET, requests were further encrypted using the symmetric RC4 algorithm.

    The main goal of TDL is monetization, based on the botnet created with its help. TDL had a modular structure and allowed to load additional modules (in the form of DLL) over the network. One of the modules installed by TDL by default was the tdlcmd.dll library, which performs the following tasks:

    • receiving and executing commands from the control center;
    • interception of user queries to search engines in order to replace search results;
    • creation of specified queries to search engines;
    • emulation of user work with the site.

    List of commands supported by tldcmd.dll:

    • DownloadCrypted - download an encrypted file;
    • DownloadAndExecute - download and execute a file;
    • DownloadCryptedAndExecute - download an encrypted file, decrypt and execute it;
    • Download - download a file;
    • ConfigWrite - make changes to the configuration file.

    Interception of user requests in order to substitute issuance was carried out for popular search engines, such as Google, Yahoo, Bing, etc. For each request to such sites, tdlcmd.dll generates a request to the server specified in the Wspservers field of the configuration file. In response, the server receives a link to the page that must be displayed to the user. The link can lead to a malicious site (for example, to install another malware), and to a legitimate one (banner promotion).

    An interesting function of tdlcmd.dll is a mechanism for dishonest "promotion" of sites by keywords (Black Seo). For its operation, a keywords file is created in the TDK repository containing words that must be addressed to the search engine. Then, in the search engine results, the site specified by the attackers is selected. At the same time, for convincing imitation of the user's work, JavaScript was used, which is built into the browser and imitates clicking on the corresponding controls (buttons, links, etc.).

    Another way to monetize was to sell part of the botnet, for this very purpose, the SubId parameter was in config.ini. Subject botnets up to 20,000 computers were subject to sale. Otherwise, the creators of TDL conducted their own criminal business themselves.

    In February 2010, an unplanned update was released from Microsoft MS10-015. This patch fixed a vulnerability that allowed locally increasing its privileges, and made modifications directly to the OS kernel. After this patch, some users began to complain about the appearance of BSOD. Later it turned out that these computers were infected with TDL-3 and BSOD caused it to load incorrectly. This is due to the use of implicit calls to WinAPI functions to shift them in memory, when updating, modifications occurred, as a result, the addresses of the functions became different, and the TDL-3 code stopped working as intended. Due to this error of developers, the number of botnets has decreased significantly, especially in the USA, where the majority of users use licensed Windows with the update mechanism turned on ( source) The developers quickly responded with the release of TDL version 3.26. Now, instead of infecting a previously known driver, the rootkit infected a random driver, and the addresses of the kernel functions used in this code were searched for using checksums calculated from their names. The encryption of the storage has been changed to a simpler one using the one-byte operation XOR and increasing the value of this byte, the initial value is 0x54 ( source ).

    Despite some tricks to protect against loss of control, command center scripts contained vulnerabilities, which allowed some computer security researchers to successfully hack. Details of one of them are available here.. According to information obtained from the databases of the hacked server, the total number of computers infected with the TDL-3 rootkit from 08/12/2009 to 07/14/2010 amounted to more than 16,000,000 computers. Naturally, this is the total amount. In reality, there were about 5,000,000 “live” bots. Most of them (43%) were in the USA. This can be explained by the greater monetary return on banner promotion in this country.

    Continued here .

    Also popular now: