Sednit gang uses bootkit in cyber attacks

    The first two parts [ 1 , 2 ] of our detailed analysis of the activities of the Sednit group were devoted to the mechanisms of the initial compromise of users, as well as a description of the backdoors of the group called SEDRECO, XAGENT and XTUNNEL. These backdoors were used for cyber espionage for compromised users, as well as for exfiltration of data from infected systems.



    The final part of our study is devoted to an interesting mechanism for covertly maintaining its presence in the system, which is also used by a group to mask its presence. Sednit uses bootkit technology for this purpose, which allows you to compromise Windows at the very early stage of its boot.

    To compromise the victim's system with a kernel mode component, the group uses a special compact bootloader or downloader, which ESET experts call Downdelph . Sednit has used this downloader quite rarely. Over the past two years, this bootloader has been involved in using the bootkit, although operators also used it to install SEDRECO and XAGENT backdoors into the system. Downdelph was used by the grouping from November 2013 to September 2015.

    Below is information about the use of Downdelph by attackers in chronological order.



    We were able to track only seven cases of installing Downdelph on users' computers. In all these cases, a dropper was used, which was responsible for installing malware components into the system.



    It can be seen that in cases 3, 4, 5, 6, the dropper used the technique of bypassing the user account management system (UAC). The authors used two techniques to circumvent UAC. The first is to use the already known “RedirectEXE” shim database method , and the second is to use the hijack DLL vulnerability in a standard Windows utility called sysprep.exe . This application has the ability to automatically elevate its privileges.

    In the seventh case, the dropper was installed into the system using directional phishing. For other cases mentioned in the diagram, this method of installing malware is not relevant. In this case, after its launch, the dropper shows the user a bait document to mask his malicious activity. The figure below shows this document, which is an invitation to a conference organized by the Slovak Foreign Policy Association in November 2015. The conference is dedicated to Russian-Ukrainian relations.



    The basic logic of the (core) Downdelph operation is implemented in one Delphi class, which was named by the authors of TMyDownloader. The same class is used in all other instances of the bootloader that we analyzed. In short, the first thing Downdelph does is download the main configuration file, which allows you to expand the list of C&C servers, and then extracts the payload from each of these servers. The whole process is graphically presented in the figure below.



    As already mentioned, the first thing Downdelph does is download a configuration file called extended.ini from the original C&C server. The address of this server is hard-wired in the body of the executable file. To send a network request, an HTTP POST is used, in which the URI string contains the name of the file to retrieve. This file name is encoded using a special algorithm.



    The referenced request encoding algorithm was developed to make writing network signatures for Downdelph network requests a complex process. To do this, after each character of the string, special characters are inserted, which are generated in a pseudo-special way. Thus, when you enter the same word into a query, each of them will be encoded differently.

    The response from the server is an encrypted configuration file in INI format. There is one section in the file called [options], which contains key-value pairs, as indicated in the table below.



    If the value of the Servers key is not empty, Downdelph adds the addresses of the specified C&C servers to its list for subsequent download from there payload.

    For each of the C&C servers on the list, the malware performs three steps that are used to load the payload. In the first step, Downdelph sends to the server the system ID that was generated based on the serial number of the hard disk. The second step is to download the configuration file called pinlt.ini, which describes the payload file. Network requests are sent in the format shown above in the screenshot. Possible keys and their configuration file values ​​are described in the table below.



    At the last stage, the malicious program downloads the payload file from a specific C&C server and works with it in the manner specified in the configuration file. After interrogating all C&C servers, Downdelph suspends its work for some time (Sleep), while the time for such a wait is indicated in the Sleep parameter of the configuration file. After that, Downdelph begins the process of polling C&C servers from the very beginning. We did not observe examples of Downdelph in-the-wild configuration files. However, we know that in some cases, he loaded Sedreco and Xagent backdoors into the system.

    We have seen cases of using Downdelph with a bootkit in two cases - 1 and 5. In recent years, bootkits have become a fairly popular way to load illegitimate kernel-mode drivers in 64-bit editions of Windows. Although this is true for our case, it is worth noting that the use of a bootkit is determined by the mechanism for ensuring the survival of the Downdelph bootloader in the system. Using a bootkit allows authors to deeply hide malicious components, making them invisible even before loading the OS.

    The Sednit bootkit is capable of compromising the 32-bit and 64-bit editions of Windows XP - 7. As far as we know, this bootkit has never been documented by any of the researchers, even though other representatives of this kind of malware are already well are documented.

    The installation process of the bootkit varies depending on the version of Windows, as well as on its bit depth, i.e. whether it is 32-bit or 64-bit. In both cases, the bootkit installer begins its execution by rewriting the MBR.



    MBR is overwritten by its malicious counterpart, and the original sector is encrypted and stored in the second sector. The main bootkit code is stored on the disk starting from the third sector, also in the form of encryption using the XOR operation. This core code will be different for different versions of Windows, since the hooks it sets during the boot process are different. After that, control is transferred to the rootkit driver, which is stored on the disk in encrypted form using the RC4 algorithm. The driver can be either 32-bit or 64-bit.

    To access the first sector of the disk, i.e., MBR, the dropper resorts to the already known method, which was previously used by the authors of the TDL4 rootkit.



    After opening the handle to the disk device, the dropper uses the WriteFile API to overwrite the first sectors of the disk. It should be noted that this operation requires administrator rights on the dropper in the system.

    Next, the dropper saves a special DLL in the created registry key called HKLM \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ Core Packages . As we will explain later, this library is a user-mode component. In addition, the Downdelph bootloader itself is stored in the same registry path, but in a section called Impersonation Packages.

    These two files are stored in the registry settings after other encrypted data, which are also used by the bootkit code. This data is compressed with aPLib and then encrypted with RC4 and begins with the header of the following structure.

    struct PackedChunkHeader
    {
     DWORD magic; // значение установлено в '0x203a3320' или " :3 " в ASCII
     DWORD packed_size;
     DWORD unpacked_size;
     DWORD key_size;
     BYTE rc4_key[16];
    };

    The value of the magic field is also recorded by the dropper at the offset 0x19B of the malicious MBR and serves as a marker that the MBR is already overwritten by the malicious contents.

    After installing it in the system, the bootkit takes control of it and then loads Windows. The boot process of a Windows 7 system with a bootkit is shown in the figure below.



    Obviously, the main goal of the bootkit is to compromise Windows at an early stage and to covertly execute the payload after loading it. Unfortunately, such a bootkit survival scheme in the system requires the use of significant modifications of the Windows system components in memory. The bootkit should contain in its arsenal code for both the real mode of operation of the microprocessor and for the protected one, and also constantly check the fact of gaining control over the loading of the system at each stage. To achieve this, the malicious code installs various intercepts in system components in memory. Despite the fact that the process of executing the bootkit code in the system is described in the picture above, as well as in the presentation of our specialists under the name Bootkits: Past, Present & FutureThere are a number of features that we would like to note.

    Malicious code in the MBR of the bootkit decrypts the bootkit code, as well as the driver that has been saved to disk since the third sector, into the memory buffer. In the system we studied, this buffer was located at the physical address 0x97C00. Thus, this memory region contains the bulk of the bootkit code, as well as hooks for bootmgr, winload.exe, and ACPI.sys. Thus, interceptions in these modules will redirect the execution thread to the above buffer. This property is not typical for bootkits, since, as a rule, they copy their code at each stage of loading into a new memory area in order to ensure their survival when switching the microprocessor mode from real to protected.

    In addition, the Sednit bootkit is the first instance that uses the legitimate acpi.sys driver to boot. Malicious code modifies the code at the entry point to this driver so that it points to a small piece of code from its resource section.



    This piece of malicious code receives, as an input argument, the ntoskrnl.exe kernel boot address in memory, in the unused fields of the PE header of which the bootkit stores some of its important data. Using this data, the bootkit code restores the first five bytes of the acpi.sys entry point, and then redirects the bootkit code to the physical address 0x97C00. This region of physical memory was projected onto protected-mode virtual memory using the MmMapIoSpace kernel API. This code decrypts and launches the bootkit driver.

    The bootkit driver embeds user mode content into the explorer.exe process by modifying its entry point before it actually executes. This user-mode component launches the Downdelph loader itself. In addition, he tries to set the exported global boolean variable m_bLoadedByBootkit to one.



    Since this global variable is absent in all Downdelph executables except the bootloader, we assume that the bootkit was originally intended for use with various payloads, and later it was reoriented by Sednit operators to the component they need. In addition, the custom bootkit component exports two functions under the names Entry and ep_data .

    Also popular now: