Grouping Sednit uses bootkit in cyber attacks
The first two parts [ 1 , 2 ] of our detailed analysis of the activities of the Sednit grouping were devoted to the mechanisms of the initial compromise of users, as well as the 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 the group to disguise its presence. Sednit uses bootkit technology to compromise Windows at the earliest stage of its loading.
To compromise the victim's system with the kernel mode component, the grouping uses a special compact bootloader or downloader, which ESET specialists call Downdelph . Sednit used this daunloader quite rarely. Over the past two years, this bootloader has been used to use a bootkit, although operators also used it to install the SEDRECO and XAGENT backdoors. Downdelph was used by the group from November 2013 to September 2015.
')
Below is information about downdelph use by attackers in chronological order.
We managed 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 circumvention technique of the user account management system (UAC). The authors used two techniques to bypass the UAC. The first is the use of the already well-known “RedirectEXE” shim database method , and the second is using the hijack DLL vulnerability of the standard Windows utility called sysprep.exe . This application has the ability to automatically increase their privileges.
In the seventh case, the dropper was installed in the system using directional phishing. For the 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 lure document to disguise its 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 core logic of the (core) Downdelph is implemented in a single Delphi class, which was named by the authors of TMyDownloader . The same class is used in all other bootloader instances we analyzed. In short, the first thing that Downdelph does is that it loads the main configuration file, which expands the list of C & C servers, and then extracts the payload from each of these servers. This whole process is illustrated in the figure below.
As already mentioned, the first thing that Downdelph does is that it loads a configuration file called extended.ini from the original C & C server. The address of this server is hardwired in the body of the executable file. To send a network request, HTTP POST is used, in which the URI string contains the name of the file to be extracted. This file name is encoded using a special algorithm.
The mentioned request encoding algorithm was designed to make writing network signatures for Downdelph network requests a complex process. For this, after each character of a line special characters are inserted, which are generated in a pseudo-special way. Thus, when you type the same word in the query, each of them will be encoded differently.
The response from the server is an encrypted configuration file in INI format. The file has one section 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 loading of the payload from there.
For each of the C & C servers listed, 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 hard disk serial number. The second step is to load a configuration file called pinlt.ini, which describes the payload file. Network requests are sent in the above screenshot format. Possible keys and their configuration file values ​​are described in the table below.
At the final stage, the malware downloads the payload file from a specific C & C server and works with it in the manner indicated in the configuration file. After polling all C & C servers, Downdelph suspends its work for a while (Sleep), while the waiting time is specified 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 configuration files Downdelph in-the-wild. However, we know that in some cases, he uploaded Sedreco and Xagent backdoors to the system.
We have seen cases of using Downdelph with a bootkit in two cases, 1 and 5. In recent years, bootkits have become quite a popular way to load illegitimate kernel-mode drivers in 64-bit editions of Windows. Although this is also 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 loader in the system. Using a bootkit allows authors to deeply hide malicious components, making them invisible even before the OS is loaded.
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 documented.
The process of installing a bootkit varies depending on the version of Windows, as well as its bit depth, that is, whether it is 32 or 64 bits. In both cases, the bootkit installer begins by rewriting the MBR.
The MBR is overwritten by its malicious counterpart, and the original sector is encrypted and stored in the second sector. The main code of the bootkit is stored on the disk starting from the third sector, also in the form encrypted using the XOR operation. This core code will be different for different versions of Windows, since the hooks it installs during the Windows boot process are different. After that, the control is transferred to the rootkit driver, which is stored on the disk in the form encrypted using the RC4 algorithm. The driver can be either 32-bit or 64-bit.
To access the first disk sector, i.e. the MBR, the dropper resorts to the already known method that was previously used by the authors of the TDL4 rootkit.
After opening the handle to a disk device, the dropper uses the WriteFile API to overwrite the first disk sectors. It should be noted that this operation requires administrative rights for the dropper in the system.
Next, the dropper saves the special DLL library in the created registry section called HKLM \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ Core Packages . As we will explain later, this library is a user mode component. In addition, the Downdelph loader itself is stored along 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 is 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.
The value of the magic field is also recorded by the dropper at the 0x19B offset of the malicious MBR and serves as a marker that the MBR has already been overwritten by the malicious content.
After its installation in the system, the bootkit takes control of it and then loads Windows. The boot process of the Windows 7 bootkit system is shown below.
Obviously, the main purpose of the bootkit is to compromise Windows at an early stage and the secretive execution of the payload after it is loaded. Unfortunately, such a bootkit survival scheme in the system requires the use of significant modifications of the Windows system components in memory. A bootkit should contain in its arsenal a code both for the real mode of operation of the microprocessor and for the protected one, and also to constantly check the fact of gaining control over the system loading at each of the stages. To achieve this goal, the malicious code installs various interceptions in the 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 called Bootkits: Past, Present & Future , there are a number of features that we would like to point out.
Malicious code in the bootkit's MBR decrypts the bootkit's code, as well as the driver, which has been saved to disk since the third sector, into a memory buffer. In the system investigated by us, this buffer was located at the physical address 0x97C00. Thus, this region of memory contains the main part of the bootkit code, as well as intercepts for bootmgr, winload.exe and ACPI.sys. Thus, the hooks in these modules will redirect the flow of execution to the above buffer. This feature 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 the microprocessor mode is switched from real to protected.
In addition, the Sednit bootkit is the first instance that uses the legitimate acpi.sys driver for its download. Malicious code modifies the code at the entry point of this driver so that it points to a small piece of code from its resource section.
This fragment of malicious code receives as an input argument the load address of the kernel ntoskrnl.exe in memory, in which the unused fields of the PE header of which the bootkit stores some of its important data. Using this data, the bootkit code recovers 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 executes the bootkit driver.
The bootkit driver injects the contents of the user mode into the explorer.exe process by modifying its entry point prior to its actual execution. This user mode component starts the Downdelph loader for execution. In addition, he is trying to set the exported global boolean variable m_bLoadedByBootkit to one.
Since this global variable is not present in all Downdelph executables except the bootloader, we assume that the bootkit was originally intended for use with different payloads, and later it was reoriented by Sednit operators to the component they need. In addition, the user component of the bootkit exports two functions called Entry and ep_data .
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 the group to disguise its presence. Sednit uses bootkit technology to compromise Windows at the earliest stage of its loading.
To compromise the victim's system with the kernel mode component, the grouping uses a special compact bootloader or downloader, which ESET specialists call Downdelph . Sednit used this daunloader quite rarely. Over the past two years, this bootloader has been used to use a bootkit, although operators also used it to install the SEDRECO and XAGENT backdoors. Downdelph was used by the group from November 2013 to September 2015.
')
Below is information about downdelph use by attackers in chronological order.
We managed 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 circumvention technique of the user account management system (UAC). The authors used two techniques to bypass the UAC. The first is the use of the already well-known “RedirectEXE” shim database method , and the second is using the hijack DLL vulnerability of the standard Windows utility called sysprep.exe . This application has the ability to automatically increase their privileges.
In the seventh case, the dropper was installed in the system using directional phishing. For the 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 lure document to disguise its 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 core logic of the (core) Downdelph is implemented in a single Delphi class, which was named by the authors of TMyDownloader . The same class is used in all other bootloader instances we analyzed. In short, the first thing that Downdelph does is that it loads the main configuration file, which expands the list of C & C servers, and then extracts the payload from each of these servers. This whole process is illustrated in the figure below.
As already mentioned, the first thing that Downdelph does is that it loads a configuration file called extended.ini from the original C & C server. The address of this server is hardwired in the body of the executable file. To send a network request, HTTP POST is used, in which the URI string contains the name of the file to be extracted. This file name is encoded using a special algorithm.
The mentioned request encoding algorithm was designed to make writing network signatures for Downdelph network requests a complex process. For this, after each character of a line special characters are inserted, which are generated in a pseudo-special way. Thus, when you type the same word in the query, each of them will be encoded differently.
The response from the server is an encrypted configuration file in INI format. The file has one section 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 loading of the payload from there.
For each of the C & C servers listed, 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 hard disk serial number. The second step is to load a configuration file called pinlt.ini, which describes the payload file. Network requests are sent in the above screenshot format. Possible keys and their configuration file values ​​are described in the table below.
At the final stage, the malware downloads the payload file from a specific C & C server and works with it in the manner indicated in the configuration file. After polling all C & C servers, Downdelph suspends its work for a while (Sleep), while the waiting time is specified 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 configuration files Downdelph in-the-wild. However, we know that in some cases, he uploaded Sedreco and Xagent backdoors to the system.
We have seen cases of using Downdelph with a bootkit in two cases, 1 and 5. In recent years, bootkits have become quite a popular way to load illegitimate kernel-mode drivers in 64-bit editions of Windows. Although this is also 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 loader in the system. Using a bootkit allows authors to deeply hide malicious components, making them invisible even before the OS is loaded.
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 documented.
The process of installing a bootkit varies depending on the version of Windows, as well as its bit depth, that is, whether it is 32 or 64 bits. In both cases, the bootkit installer begins by rewriting the MBR.
The MBR is overwritten by its malicious counterpart, and the original sector is encrypted and stored in the second sector. The main code of the bootkit is stored on the disk starting from the third sector, also in the form encrypted using the XOR operation. This core code will be different for different versions of Windows, since the hooks it installs during the Windows boot process are different. After that, the control is transferred to the rootkit driver, which is stored on the disk in the form encrypted using the RC4 algorithm. The driver can be either 32-bit or 64-bit.
To access the first disk sector, i.e. the MBR, the dropper resorts to the already known method that was previously used by the authors of the TDL4 rootkit.
After opening the handle to a disk device, the dropper uses the WriteFile API to overwrite the first disk sectors. It should be noted that this operation requires administrative rights for the dropper in the system.
Next, the dropper saves the special DLL library in the created registry section called HKLM \ SYSTEM \ CurrentControlSet \ Control \ Lsa \ Core Packages . As we will explain later, this library is a user mode component. In addition, the Downdelph loader itself is stored along 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 is 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 0x19B offset of the malicious MBR and serves as a marker that the MBR has already been overwritten by the malicious content.
After its installation in the system, the bootkit takes control of it and then loads Windows. The boot process of the Windows 7 bootkit system is shown below.
Obviously, the main purpose of the bootkit is to compromise Windows at an early stage and the secretive execution of the payload after it is loaded. Unfortunately, such a bootkit survival scheme in the system requires the use of significant modifications of the Windows system components in memory. A bootkit should contain in its arsenal a code both for the real mode of operation of the microprocessor and for the protected one, and also to constantly check the fact of gaining control over the system loading at each of the stages. To achieve this goal, the malicious code installs various interceptions in the 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 called Bootkits: Past, Present & Future , there are a number of features that we would like to point out.
Malicious code in the bootkit's MBR decrypts the bootkit's code, as well as the driver, which has been saved to disk since the third sector, into a memory buffer. In the system investigated by us, this buffer was located at the physical address 0x97C00. Thus, this region of memory contains the main part of the bootkit code, as well as intercepts for bootmgr, winload.exe and ACPI.sys. Thus, the hooks in these modules will redirect the flow of execution to the above buffer. This feature 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 the microprocessor mode is switched from real to protected.
In addition, the Sednit bootkit is the first instance that uses the legitimate acpi.sys driver for its download. Malicious code modifies the code at the entry point of this driver so that it points to a small piece of code from its resource section.
This fragment of malicious code receives as an input argument the load address of the kernel ntoskrnl.exe in memory, in which the unused fields of the PE header of which the bootkit stores some of its important data. Using this data, the bootkit code recovers 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 executes the bootkit driver.
The bootkit driver injects the contents of the user mode into the explorer.exe process by modifying its entry point prior to its actual execution. This user mode component starts the Downdelph loader for execution. In addition, he is trying to set the exported global boolean variable m_bLoadedByBootkit to one.
Since this global variable is not present in all Downdelph executables except the bootloader, we assume that the bootkit was originally intended for use with different payloads, and later it was reoriented by Sednit operators to the component they need. In addition, the user component of the bootkit exports two functions called Entry and ep_data .
Source: https://habr.com/ru/post/314058/
All Articles