Modern bootkit technology and detailed analysis of Win32 / Gapz
In the past few years, the spread of malicious programs (bootkits) that modify the boot sector in the process of system infection has increased. Among the most prominent representatives are TDL4, Olmasco and Rovnix. Each of them uses different methods of infecting the hard disk, it is either a modification of the master boot record (MBR) or a modification of the first sectors of the boot partition, i.e. VBR or IPL (the first sectors of the volume where control is transferred from the MBR - Volume Boot Record / Initial Program Loader ). These families are clearly shown in the figure below.
Fig. 1. Diagram of various bootkit families and disk infection methods.
There are several reasons for the use of bootkits in modern threats:
● Ability to run malicious code before the OS code, which provides undeniable advantages and allows you to control the OS boot process.
● As a consequence of the first point, it allows you to bypass the integrity monitoring system of the key core components - PatchGuard (almost the only way to ensure the survival of the rootkit in the x64 environment).
● Ability to hide your code deeply and thus make it invisible to AV scanners.
● A bootkit has a sector-by-sector architecture for storing its body on a disk, which makes it possible to carry its malicious code and payload code far beyond the file system and even disk partitions, making it almost impossible to detect it.
● Secure rootkit installation in the system.
')
In the ESET report on threats and trends for 2012 , we indicated that bootkits are one of the key technical trends of the past year. Our experts track the emergence of new complex threats. We also did not bypass Win32 / Gapz, as it contains a number of technical features that make it really interesting. Alexander Matrosov and Yevgeny Rodionov did a great job, analyzing this bootkit. Our today's post is dedicated to this analysis.
Dropper
Let's start with the dropper - the component that is the original carrier of the bootkit code and is responsible for its installation in the system. We detect it as: Win32 / Gapz.X , X-version. We found three of its versions, A, B and C. The following table shows their characteristics:
Fig. 2
In accordance with our observations, the first known version of the dropper was compiled in April last year and contained a lot of debugging information, that is, it was not meant for mass distribution. It is likely that Win32 / Gapz began to massively distribute in late summer or early September last year. To raise its privileges in the Win32 / Gapz system, it uses LPE exploits and the COM Elevation method.
In the process of analysis, we found that Win32 / Gapz could be infected with: 32-bit Windows XP SP2 and above (excluding Windows Vista and Vista SP1) and 64-bit Windows XP SP2 and above. The discussed version of the Win32 / Gapz dropper is capable of infecting Windows XP and Windows 7, including the x64 version, however on Windows 8 the bootkit part does not work properly and after infection the part that was necessary for execution in kernel mode was not executed.
Fig. 3. Part of the dropper code that checks the version of the OS.
Dropper, who installs a bootkit into the system, has been carefully thought out and is able to bypass modern proactive defenses (HIPS), as well as raise its privileges to the level of the system. In addition, it contains a clever method for embedding code into the process address space. The dropper file exports several functions from itself, which are shown in the figure below.
Fig. 4. Functions exported by the dropper executable.
There are three exported functions that you should pay attention to: start, icmnf and isyspf. Short description:
● start - entry point into the dropper, implements its implementation into the address space of the trusted explorer.exe process;
● icmnf - is responsible for increasing (escalating) privileges;
● isyspf - infects a victim with a bootkit code.
The dropper code uses a special section that is projected into the address space of the explorer process. Through this section, he loads the shellcode into this process and further, using a specially crafted API call, activates it. Accordingly, after the shellcode is activated, it loads the image of the dropper into the address space of the explorer process, calls the privilege elevation function and initiates the infection procedure with the bootkit code, writing it to the disk.
Fig. 5. Stages of dropping and infection of the victim with the bootkit code.
After the dropper has infected the system with a bootkit, his task is executed and he deletes his file from the disk.
Malicious MBR code
We found two modifications of the Win32 / Gapz bootkit, which differ in methods of infecting the victim's disk. The earliest modification appeared in the early summer of 2012; this version was aimed at infecting the MBR. Another later modification that infects VBR was seen in late fall 2012.
Fig. 6. Two Win32 / Gapz modifications aimed at infecting MBR and VBR.
Let's look at an earlier modification of the bootkit, which is aimed at infecting the MBR, in more detail. In this case, the bootkit code can be divided into several parts:
● malicious MBR;
● kernel mode code and payload embedded in processes.
Malicious code saves its kernel mode code and payload either before the very first partition or after the last partition on the hard disk. This approach is very similar to the one used in the Rovnix bootkit, except that Rovnix infects VBR.
As for the Win32 / Gapz bootkit, there is nothing unusual in it: as soon as the code from the malicious MBR is completed, it restores the original code in memory and reads the following sectors of the hard disk, containing the code for subsequent execution, to which control is transferred. The bootkit code intercepts the 0x13 interrupt handler, int 13h, and thus tracks the load of the following OS modules to install hooks there:
● ntldr (on systems up to Windows Vista)
● bootmgr (on Vista + systems)
● winload.ex e (on Vista + systems)
The bootkit code identifies each of the above modules using special byte sequences. Below is a list of functions that the bootkit intercepts in these modules:
As soon as the malicious code detects that a particular module is being read from the hard disk, it modifies it in such a way as to regain control after the processor switches to protected mode. The bootkit installs hooks on the OS kernel loader: this is either ntldr on legacy systems prior to Windows Vista, or bootmgr on Vista and higher. In the case of bootmgr, it also intercepts the OslArchTransferToKernel function in winload.exe.
Fig. 7. OslArchTransferToKernel function interceptor in winload.exe.
The next step is to set the interception on the IoInitSystem function, which is called during the OS initialization process. It is intercepted by malicious code from either ntldr or winload.exe, depending on the version of the OS.
Fig. 8. Interception code installed on the IoInitSystem function.
After the malicious code from IoInitSystem was executed, the bootkit recovers the modified bytes in the ntoskrnl kernel image and transfers control to the original IoInitSystem . Before transferring control to the original code, the bootkit rewrites the return address in the stack to its function, which, accordingly, will be executed upon completion of the IoInitSystem execution. With this trick, the malicious code gets control after the OS kernel is initialized. Next, the malicious code reads the rest of its part from the hard disk and creates a separate system thread that executes these instructions and finally returns control to the kernel. This part of the bootkit, which runs in kernel mode, implements rootkit functionality, integrating payloads into processes and interacting with the C & C server.
Malicious VBR code
As we already mentioned, the latest Win32 / Gapz modification infects the VBR of a volume that is marked as active in the MBR (Volume Boot Record - the first sectors of the volume that contain service information, as well as the VBR code to which control is transferred from the MBR and which responds for further OS loading). The bootkit uses the original approach to infect VBR and then transfer control to its code. In order to be more secretive and inconspicuous, it modifies only a few bytes of the original VBR. The essence of this approach is that it modifies the value of the “Hidden Sectors” field in the VBR service structure field, while leaving the VBR code and the IPL code intact! IPL, Initial Program Loader - the code to which control is transferred after the execution of the VBR code, it is responsible for finding the loader within the file system of the volume and transfers control to it. The VBR includes the following parts:
● Bootstrap code (VBR code), which is responsible for loading IPL.
● BIOS Parameter Block (BPB) is a data structure that stores an NTFS parameter block.
● Text strings displayed to the user in case of an error.
● 0xAA55 - standard double-byte signature, service sector marker.
Fig. 9. Diagram of the first sector VBR.
In the case of Win32 / Gapz, the most interesting place to analyze is the BPB and especially the “Hidden Sectors” field. This field contains the number of sectors preceding the IPL (i.e., the offset to IPL in sectors, with which the code from VBR determines where to transfer control further) and stored on the NTFS volume, as shown below.
Fig. 10. The structure of the NTFS-volume.
Thus, in the boot process on a clean system, the VBR code reads 15 sectors, starting at the offset specified in Hidden Sectors, and transfers control there. This is what the bootkit uses to transfer control to itself. It overwrites this value, indicating the offset in the sectors to its malicious code stored on the disk. After infection, the volume looks like this:
Fig. 11. The bootkit-modified value of “Hidden Sectors” causes the VBR code to transfer control to the bootkit code, and not to the IPL.
In the event of a system infection, the VBR code calls the bootkit code instead of the legal IPL for execution. The bootkit code, as already mentioned, is recorded either before the very first partition of the disk, or after the last one. The rest of the bootkit code is essentially the same as the version with the MBR infector.
Kernel-Mode Malicious Code
The main purpose of the directly part, which is called the bootkit, described above, is to load the malicious code of the kernel mode or rootkit into the system address space, bypassing the restrictions imposed by the OS for such privileged code. We have already mentioned that this bootkit-loaded code contains a rootkit to hide its presence, a mechanism for working with the managing C & C server, as well as a payload (payload), which is intended for implementation into processes.
Unlike Rovnix, TDL4 and other common bootkits, the malicious kernel-mode code in Win32 / Gapz does not have the structure of an executable PE file. Instead, it is structured in a special way. The code consists of 12 interconnected blocks, each of which has a header - a structure that stores service information about it. It has the following form:
Each block implements a specific functionality: the introduction of the payload, interaction with C & C servers, self-defense, and so on. The functionality of the kernel mode code is quite complex and can be considered separately (beyond the scope of this post).
Bootkits vs. Microsoft ELAM
In this part of our post, we want to focus on a special tool that Microsoft decided to use to combat various kinds of threats, especially rootkits and bootkits, which try to load themselves before other drivers in the system. The tool is called ELAM, Early Launch Anti-Malware Module and comes as part of the OS, starting with Windows 8. In essence, ELAM is a driver provided by an anti-virus vendor that is guaranteed priority when loading kernel-mode drivers. From the point of view of the OS kernel, ELAM is an API for anti-virus drivers, as well as a set of rules that such a driver should follow. One of the main features of this tool is that it is guaranteed to allow the AV driver to load before the rest of the drivers in the system and, thus, go beyond the usual rules for autoloading, which are regulated by other drivers.
We note that ELAM by itself cannot be as effective for fighting bootkits, since it is part of the OS kernel, and the bootkit gets control much earlier.
Fig. 12. We see that a bootkit can compromise a system with an active ELAM, making it a useless tool. Since the bootkit is loaded before the OS is initialized, it will already be in memory at the time that ELAM gets control.
At the same time, it should be noted that ELAM is part of the Microsoft Secure Boot concept or scheme “Secure Boot”. In the case of Secure Boot, software embedded in UEFI (such software gets control as soon as the computer starts its work) can control the integrity and legitimacy of the code to which control is transferred during the execution of the code preceding the execution of the main OS code. The concept of Secure Boot, together with the new UEFI standard, is designed to prevent the bootkit from compromising critical OS / UEFI data structures.
Fig. 1. Diagram of various bootkit families and disk infection methods.
There are several reasons for the use of bootkits in modern threats:
● Ability to run malicious code before the OS code, which provides undeniable advantages and allows you to control the OS boot process.
● As a consequence of the first point, it allows you to bypass the integrity monitoring system of the key core components - PatchGuard (almost the only way to ensure the survival of the rootkit in the x64 environment).
● Ability to hide your code deeply and thus make it invisible to AV scanners.
● A bootkit has a sector-by-sector architecture for storing its body on a disk, which makes it possible to carry its malicious code and payload code far beyond the file system and even disk partitions, making it almost impossible to detect it.
● Secure rootkit installation in the system.
')
In the ESET report on threats and trends for 2012 , we indicated that bootkits are one of the key technical trends of the past year. Our experts track the emergence of new complex threats. We also did not bypass Win32 / Gapz, as it contains a number of technical features that make it really interesting. Alexander Matrosov and Yevgeny Rodionov did a great job, analyzing this bootkit. Our today's post is dedicated to this analysis.
Dropper
Let's start with the dropper - the component that is the original carrier of the bootkit code and is responsible for its installation in the system. We detect it as: Win32 / Gapz.X , X-version. We found three of its versions, A, B and C. The following table shows their characteristics:
Fig. 2
In accordance with our observations, the first known version of the dropper was compiled in April last year and contained a lot of debugging information, that is, it was not meant for mass distribution. It is likely that Win32 / Gapz began to massively distribute in late summer or early September last year. To raise its privileges in the Win32 / Gapz system, it uses LPE exploits and the COM Elevation method.
In the process of analysis, we found that Win32 / Gapz could be infected with: 32-bit Windows XP SP2 and above (excluding Windows Vista and Vista SP1) and 64-bit Windows XP SP2 and above. The discussed version of the Win32 / Gapz dropper is capable of infecting Windows XP and Windows 7, including the x64 version, however on Windows 8 the bootkit part does not work properly and after infection the part that was necessary for execution in kernel mode was not executed.
Fig. 3. Part of the dropper code that checks the version of the OS.
Dropper, who installs a bootkit into the system, has been carefully thought out and is able to bypass modern proactive defenses (HIPS), as well as raise its privileges to the level of the system. In addition, it contains a clever method for embedding code into the process address space. The dropper file exports several functions from itself, which are shown in the figure below.
Fig. 4. Functions exported by the dropper executable.
There are three exported functions that you should pay attention to: start, icmnf and isyspf. Short description:
● start - entry point into the dropper, implements its implementation into the address space of the trusted explorer.exe process;
● icmnf - is responsible for increasing (escalating) privileges;
● isyspf - infects a victim with a bootkit code.
The dropper code uses a special section that is projected into the address space of the explorer process. Through this section, he loads the shellcode into this process and further, using a specially crafted API call, activates it. Accordingly, after the shellcode is activated, it loads the image of the dropper into the address space of the explorer process, calls the privilege elevation function and initiates the infection procedure with the bootkit code, writing it to the disk.
Fig. 5. Stages of dropping and infection of the victim with the bootkit code.
After the dropper has infected the system with a bootkit, his task is executed and he deletes his file from the disk.
Malicious MBR code
We found two modifications of the Win32 / Gapz bootkit, which differ in methods of infecting the victim's disk. The earliest modification appeared in the early summer of 2012; this version was aimed at infecting the MBR. Another later modification that infects VBR was seen in late fall 2012.
Fig. 6. Two Win32 / Gapz modifications aimed at infecting MBR and VBR.
Let's look at an earlier modification of the bootkit, which is aimed at infecting the MBR, in more detail. In this case, the bootkit code can be divided into several parts:
● malicious MBR;
● kernel mode code and payload embedded in processes.
Malicious code saves its kernel mode code and payload either before the very first partition or after the last partition on the hard disk. This approach is very similar to the one used in the Rovnix bootkit, except that Rovnix infects VBR.
As for the Win32 / Gapz bootkit, there is nothing unusual in it: as soon as the code from the malicious MBR is completed, it restores the original code in memory and reads the following sectors of the hard disk, containing the code for subsequent execution, to which control is transferred. The bootkit code intercepts the 0x13 interrupt handler, int 13h, and thus tracks the load of the following OS modules to install hooks there:
● ntldr (on systems up to Windows Vista)
● bootmgr (on Vista + systems)
● winload.ex e (on Vista + systems)
The bootkit code identifies each of the above modules using special byte sequences. Below is a list of functions that the bootkit intercepts in these modules:
As soon as the malicious code detects that a particular module is being read from the hard disk, it modifies it in such a way as to regain control after the processor switches to protected mode. The bootkit installs hooks on the OS kernel loader: this is either ntldr on legacy systems prior to Windows Vista, or bootmgr on Vista and higher. In the case of bootmgr, it also intercepts the OslArchTransferToKernel function in winload.exe.
Fig. 7. OslArchTransferToKernel function interceptor in winload.exe.
The next step is to set the interception on the IoInitSystem function, which is called during the OS initialization process. It is intercepted by malicious code from either ntldr or winload.exe, depending on the version of the OS.
Fig. 8. Interception code installed on the IoInitSystem function.
After the malicious code from IoInitSystem was executed, the bootkit recovers the modified bytes in the ntoskrnl kernel image and transfers control to the original IoInitSystem . Before transferring control to the original code, the bootkit rewrites the return address in the stack to its function, which, accordingly, will be executed upon completion of the IoInitSystem execution. With this trick, the malicious code gets control after the OS kernel is initialized. Next, the malicious code reads the rest of its part from the hard disk and creates a separate system thread that executes these instructions and finally returns control to the kernel. This part of the bootkit, which runs in kernel mode, implements rootkit functionality, integrating payloads into processes and interacting with the C & C server.
Malicious VBR code
As we already mentioned, the latest Win32 / Gapz modification infects the VBR of a volume that is marked as active in the MBR (Volume Boot Record - the first sectors of the volume that contain service information, as well as the VBR code to which control is transferred from the MBR and which responds for further OS loading). The bootkit uses the original approach to infect VBR and then transfer control to its code. In order to be more secretive and inconspicuous, it modifies only a few bytes of the original VBR. The essence of this approach is that it modifies the value of the “Hidden Sectors” field in the VBR service structure field, while leaving the VBR code and the IPL code intact! IPL, Initial Program Loader - the code to which control is transferred after the execution of the VBR code, it is responsible for finding the loader within the file system of the volume and transfers control to it. The VBR includes the following parts:
● Bootstrap code (VBR code), which is responsible for loading IPL.
● BIOS Parameter Block (BPB) is a data structure that stores an NTFS parameter block.
● Text strings displayed to the user in case of an error.
● 0xAA55 - standard double-byte signature, service sector marker.
Fig. 9. Diagram of the first sector VBR.
In the case of Win32 / Gapz, the most interesting place to analyze is the BPB and especially the “Hidden Sectors” field. This field contains the number of sectors preceding the IPL (i.e., the offset to IPL in sectors, with which the code from VBR determines where to transfer control further) and stored on the NTFS volume, as shown below.
Fig. 10. The structure of the NTFS-volume.
Thus, in the boot process on a clean system, the VBR code reads 15 sectors, starting at the offset specified in Hidden Sectors, and transfers control there. This is what the bootkit uses to transfer control to itself. It overwrites this value, indicating the offset in the sectors to its malicious code stored on the disk. After infection, the volume looks like this:
Fig. 11. The bootkit-modified value of “Hidden Sectors” causes the VBR code to transfer control to the bootkit code, and not to the IPL.
In the event of a system infection, the VBR code calls the bootkit code instead of the legal IPL for execution. The bootkit code, as already mentioned, is recorded either before the very first partition of the disk, or after the last one. The rest of the bootkit code is essentially the same as the version with the MBR infector.
Kernel-Mode Malicious Code
The main purpose of the directly part, which is called the bootkit, described above, is to load the malicious code of the kernel mode or rootkit into the system address space, bypassing the restrictions imposed by the OS for such privileged code. We have already mentioned that this bootkit-loaded code contains a rootkit to hide its presence, a mechanism for working with the managing C & C server, as well as a payload (payload), which is intended for implementation into processes.
Unlike Rovnix, TDL4 and other common bootkits, the malicious kernel-mode code in Win32 / Gapz does not have the structure of an executable PE file. Instead, it is structured in a special way. The code consists of 12 interconnected blocks, each of which has a header - a structure that stores service information about it. It has the following form:
Each block implements a specific functionality: the introduction of the payload, interaction with C & C servers, self-defense, and so on. The functionality of the kernel mode code is quite complex and can be considered separately (beyond the scope of this post).
Bootkits vs. Microsoft ELAM
In this part of our post, we want to focus on a special tool that Microsoft decided to use to combat various kinds of threats, especially rootkits and bootkits, which try to load themselves before other drivers in the system. The tool is called ELAM, Early Launch Anti-Malware Module and comes as part of the OS, starting with Windows 8. In essence, ELAM is a driver provided by an anti-virus vendor that is guaranteed priority when loading kernel-mode drivers. From the point of view of the OS kernel, ELAM is an API for anti-virus drivers, as well as a set of rules that such a driver should follow. One of the main features of this tool is that it is guaranteed to allow the AV driver to load before the rest of the drivers in the system and, thus, go beyond the usual rules for autoloading, which are regulated by other drivers.
We note that ELAM by itself cannot be as effective for fighting bootkits, since it is part of the OS kernel, and the bootkit gets control much earlier.
Fig. 12. We see that a bootkit can compromise a system with an active ELAM, making it a useless tool. Since the bootkit is loaded before the OS is initialized, it will already be in memory at the time that ELAM gets control.
At the same time, it should be noted that ELAM is part of the Microsoft Secure Boot concept or scheme “Secure Boot”. In the case of Secure Boot, software embedded in UEFI (such software gets control as soon as the computer starts its work) can control the integrity and legitimacy of the code to which control is transferred during the execution of the code preceding the execution of the main OS code. The concept of Secure Boot, together with the new UEFI standard, is designed to prevent the bootkit from compromising critical OS / UEFI data structures.
Source: https://habr.com/ru/post/169131/
All Articles