February 12, 2013 at 12:02Modern bootkit technology and detailed analysis of Win32 / Gapz
In the last few years, the spread of malware (bootkits) that modify boot sectors during the infection of the system has increased. Among the most prominent representatives are TDL4, Olmasco and Rovnix. Each of them uses different methods of infection of the hard drive, 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 to which control is transferred from the MBR - Volume Boot Record / Initial Program Loader ). These families are clearly illustrated in the figure below.
Fig. 1. Scheme of various bootkit families and disk infection methods.
There are several reasons for using bootkits in modern threats:
● The ability to run malicious code earlier than the OS code, which gives undeniable advantages and allows you to control the process of loading the OS.
● As a consequence of the first paragraph, it allows you to bypass the integrity monitoring system of key kernel components - PatchGuard (almost the only way to ensure rootkit survivability in the x64 environment).
● The ability to deeply hide your code and, thus, make it invisible to AV scanners.
● The bootkit has a sector-by-sector architecture for storing its body on disk, which makes it possible to take 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 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 monitor the emergence of new complex threats. We also did not pass Win32 / Gapz, as it contains a number of technical features that make it really interesting. Alexander Matrosov and Evgeny Rodionov did a great job analyzing this bootkit. Our post today is dedicated to this analysis.
Dropper
Let's start with the dropper - the component that is the initial carrier of the bootkit code and is responsible for installing it in the system. We detect it as: Win32 / Gapz.X , X-version. We found three versions of it, A, B and C. Their characteristics are given in the table below:
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, i.e. it was not meant for mass distribution. It is likely that Win32 / Gapz began to be massively distributed in late summer or early September last year. Win32 / Gapz uses LPE exploits and the COM Elevation method to elevate its privileges on a system.
In the process of analysis, we found that Win32 / Gapz is affected by: 32-bit Windows XP SP2 and higher (excluding Windows Vista and Vista SP1) and 64-bit Windows XP SP2 and higher. The discussed version of the Win32 / Gapz dropper is capable of infecting Windows XP and Windows 7, including the x64 version, however, the bootkit part does not work properly on Windows 8 and after the infection, the part proper for execution in kernel mode was not executed.
Fig. 3. Part of the dropper code that checks the OS version.
The dropper that installs the bootkit in the system is carefully thought out and is able to circumvent modern proactive defenses (HIPS), as well as raise its privileges to the level of the system. In addition, it contains a tricky method for injecting code into the address space of a process. The dropper file exports several functions from itself, which are indicated 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 - the entry point to the dropper, it is implemented in the address space of the explorer.exe trusted process;
● icmnf - is responsible for increasing (escalating) privileges;
● isyspf — Infects the 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 shell code into this process and then, using a specially formed API call, makes its activation. Accordingly, after the shell code is activated, it loads the dropper image into the address space of the explorer process, calls the privilege escalation function, and initiates the bootkit infection procedure by writing it to disk.
Fig. 5. The stages of the dropper and infection of the victim with the bootkit code.
After the dropper infected the system with a bootkit, its task is completed, and it deletes its file from the disk.
Malicious code MBR
We found two modifications of the Win32 / Gapz bootkit, which differ in the methods of infection of the victim’s disk. The earliest modification appeared in the early summer of 2012, this version was aimed at infecting MBR. Another, later modification that infects VBR was seen in late autumn 2012
. 6. Two Win32 / Gapz modifications aimed at infecting MBR and VBR.
Let's look at an earlier bootkit modification that targets MBR infection 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 drive. This approach is very similar to the one used in the Rovnix bootkit, except that Rovnix infects VBR.
As for the Win32 / Gapz bootkit part, there is nothing unusual in it: as soon as the code from the malicious MBR is executed, it restores the original code in memory and reads the following sectors of the hard drive containing the code for subsequent execution, to which control is transferred. The bootkit code intercepts the interrupt handler 0x13, int 13h and thus monitors the loading of the following OS modules to install intercepts there:
● ntldr (on systems prior 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. The following 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 drive, it modifies it so that it regains control after the processor switches to protected mode. The bootkit installs hooks on the OS kernel bootloader: either ntldr on legacy systems prior to Windows Vista, or bootmgr on Vista and later. In the case of bootmgr, it also intercepts the OslArchTransferToKernel function in winload.exe.
Fig. 7. Function interceptorOslArchTransferToKernel in winload.exe.
The next step is to install the interception on the IoInitSystem function , which is called during the OS initialization process. It is intercepted by malicious code either from ntldr or from winload.exe, depending on the version of the OS.
Fig. 8. The interception code set on the IoInitSystem function .
After the malicious code from IoInitSystem has been 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 executionIoInitSystem . With this trick, the malicious code takes control after the OS kernel is initialized. Next, the malicious code reads the rest of it from the hard drive and creates a separate system thread that executes these instructions and returns control to the kernel at the end. In this part of the bootkit, which is executed in kernel mode, rootkit functionality is implemented, the implementation of the payload in the processes and interaction 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 loading the OS). The bootkit uses an original approach to infect VBR and then transfer control to its code. In order to be more secretive and invisible, 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 field of the VBR service structure, while leaving the VBR code and IPL code intact! IPL, Initial Program Loader - code to which control is transferred after the VBR code is executed, he is responsible for finding the bootloader within the volume file system and transfers control to it. The following parts are included in VBR:
● Bootstrap code (VBR code) responsible for loading the IPL.
● BIOS Parameter Block (BPB) - A data structure that stores an NTFS parameter block.
● Text strings displayed to the user in case of error.
● 0xAA55 - standard two-byte signature, service sector marker.
Fig. 9. Scheme of the first sector VBR.
In the case of Win32 / Gapz, the most interesting place for analysis is BPB and especially the “Hidden Sectors” field. This field contains the number of sectors preceding the IPL (i.e., the offset to the IPL in the sectors by which the code from VBR determines where to transfer control further) and stored on an NTFS volume, as shown below.
Fig. 10. The structure of an NTFS volume.
Thus, during the boot process on a clean system, the VBR code reads 15 sectors, starting from the offset specified in the "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 sectors to its malicious code stored on disk. After infection, the volume looks like this:
Fig. 11. The “Hidden Sectors” value modified by the bootkit causes the VBR code to transfer control to the bootkit code, and not to the IPL.
In case of system infection, the VBR code calls the bootkit code for execution instead of the legal IPL. The bootkit code, as already mentioned, is written either before the very first partition of the disk, or after the last. Otherwise, the bootkit code is essentially no different from the version with the MBR infector.
Kernel-mode malicious code
The main purpose of this part, which is called the bootkit described above, is to download malicious kernel-mode or rootkit code 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 C&C management server, and also payload, which is intended for implementation in processes.
Unlike Rovnix, TDL4, and other common bootkits, the kernel mode malicious code in Win32 / Gapz does not have an executable PE file structure. Instead, it is structured in a special way. The code consists of 12 blocks interconnected, each of which has a heading - a structure that stores service information about it. It has the following form:
Each of the blocks implements a certain functionality: implementation 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 dwell on a special tool that Microsoft decided to use to combat various kinds of threats, especially rootkits and bootkits that try to load themselves before other drivers in the system. The tool is called ELAM, Early Launch Anti-Malware Module, and is shipped with the operating system starting with Windows 8. In essence, ELAM is a driver provided by an anti-virus vendor, which 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 adhere to. One of the main features of this tool is that it is guaranteed to allow the AV driver to boot before the other drivers in the system, and thus
We note that ELAM alone cannot be so effective at 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 active ELAM, making it a useless tool. Since the bootkit boots before OS initialization, it will already be in memory at the moment ELAM takes control.
At the same time, it should be noted that ELAM is part of Microsoft's declared Safe Boot concept or scheme - Secure Boot. In the case of Secure Boot, the software built into UEFI (such software takes 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 Secure Boot concept, in conjunction with the new UEFI standard, is designed to prevent the critical boot structures from compromising OS / UEFI data structures.
Fig. 1. Scheme of various bootkit families and disk infection methods.
There are several reasons for using bootkits in modern threats:
● The ability to run malicious code earlier than the OS code, which gives undeniable advantages and allows you to control the process of loading the OS.
● As a consequence of the first paragraph, it allows you to bypass the integrity monitoring system of key kernel components - PatchGuard (almost the only way to ensure rootkit survivability in the x64 environment).
● The ability to deeply hide your code and, thus, make it invisible to AV scanners.
● The bootkit has a sector-by-sector architecture for storing its body on disk, which makes it possible to take 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 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 monitor the emergence of new complex threats. We also did not pass Win32 / Gapz, as it contains a number of technical features that make it really interesting. Alexander Matrosov and Evgeny Rodionov did a great job analyzing this bootkit. Our post today is dedicated to this analysis.
Dropper
Let's start with the dropper - the component that is the initial carrier of the bootkit code and is responsible for installing it in the system. We detect it as: Win32 / Gapz.X , X-version. We found three versions of it, A, B and C. Their characteristics are given in the table below:
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, i.e. it was not meant for mass distribution. It is likely that Win32 / Gapz began to be massively distributed in late summer or early September last year. Win32 / Gapz uses LPE exploits and the COM Elevation method to elevate its privileges on a system.
In the process of analysis, we found that Win32 / Gapz is affected by: 32-bit Windows XP SP2 and higher (excluding Windows Vista and Vista SP1) and 64-bit Windows XP SP2 and higher. The discussed version of the Win32 / Gapz dropper is capable of infecting Windows XP and Windows 7, including the x64 version, however, the bootkit part does not work properly on Windows 8 and after the infection, the part proper for execution in kernel mode was not executed.
Fig. 3. Part of the dropper code that checks the OS version.
The dropper that installs the bootkit in the system is carefully thought out and is able to circumvent modern proactive defenses (HIPS), as well as raise its privileges to the level of the system. In addition, it contains a tricky method for injecting code into the address space of a process. The dropper file exports several functions from itself, which are indicated 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 - the entry point to the dropper, it is implemented in the address space of the explorer.exe trusted process;
● icmnf - is responsible for increasing (escalating) privileges;
● isyspf — Infects the 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 shell code into this process and then, using a specially formed API call, makes its activation. Accordingly, after the shell code is activated, it loads the dropper image into the address space of the explorer process, calls the privilege escalation function, and initiates the bootkit infection procedure by writing it to disk.
Fig. 5. The stages of the dropper and infection of the victim with the bootkit code.
After the dropper infected the system with a bootkit, its task is completed, and it deletes its file from the disk.
Malicious code MBR
We found two modifications of the Win32 / Gapz bootkit, which differ in the methods of infection of the victim’s disk. The earliest modification appeared in the early summer of 2012, this version was aimed at infecting MBR. Another, later modification that infects VBR was seen in late autumn 2012
. 6. Two Win32 / Gapz modifications aimed at infecting MBR and VBR.
Let's look at an earlier bootkit modification that targets MBR infection 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 drive. This approach is very similar to the one used in the Rovnix bootkit, except that Rovnix infects VBR.
As for the Win32 / Gapz bootkit part, there is nothing unusual in it: as soon as the code from the malicious MBR is executed, it restores the original code in memory and reads the following sectors of the hard drive containing the code for subsequent execution, to which control is transferred. The bootkit code intercepts the interrupt handler 0x13, int 13h and thus monitors the loading of the following OS modules to install intercepts there:
● ntldr (on systems prior 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. The following 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 drive, it modifies it so that it regains control after the processor switches to protected mode. The bootkit installs hooks on the OS kernel bootloader: either ntldr on legacy systems prior to Windows Vista, or bootmgr on Vista and later. In the case of bootmgr, it also intercepts the OslArchTransferToKernel function in winload.exe.
Fig. 7. Function interceptorOslArchTransferToKernel in winload.exe.
The next step is to install the interception on the IoInitSystem function , which is called during the OS initialization process. It is intercepted by malicious code either from ntldr or from winload.exe, depending on the version of the OS.
Fig. 8. The interception code set on the IoInitSystem function .
After the malicious code from IoInitSystem has been 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 executionIoInitSystem . With this trick, the malicious code takes control after the OS kernel is initialized. Next, the malicious code reads the rest of it from the hard drive and creates a separate system thread that executes these instructions and returns control to the kernel at the end. In this part of the bootkit, which is executed in kernel mode, rootkit functionality is implemented, the implementation of the payload in the processes and interaction 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 loading the OS). The bootkit uses an original approach to infect VBR and then transfer control to its code. In order to be more secretive and invisible, 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 field of the VBR service structure, while leaving the VBR code and IPL code intact! IPL, Initial Program Loader - code to which control is transferred after the VBR code is executed, he is responsible for finding the bootloader within the volume file system and transfers control to it. The following parts are included in VBR:
● Bootstrap code (VBR code) responsible for loading the IPL.
● BIOS Parameter Block (BPB) - A data structure that stores an NTFS parameter block.
● Text strings displayed to the user in case of error.
● 0xAA55 - standard two-byte signature, service sector marker.
Fig. 9. Scheme of the first sector VBR.
In the case of Win32 / Gapz, the most interesting place for analysis is BPB and especially the “Hidden Sectors” field. This field contains the number of sectors preceding the IPL (i.e., the offset to the IPL in the sectors by which the code from VBR determines where to transfer control further) and stored on an NTFS volume, as shown below.
Fig. 10. The structure of an NTFS volume.
Thus, during the boot process on a clean system, the VBR code reads 15 sectors, starting from the offset specified in the "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 sectors to its malicious code stored on disk. After infection, the volume looks like this:
Fig. 11. The “Hidden Sectors” value modified by the bootkit causes the VBR code to transfer control to the bootkit code, and not to the IPL.
In case of system infection, the VBR code calls the bootkit code for execution instead of the legal IPL. The bootkit code, as already mentioned, is written either before the very first partition of the disk, or after the last. Otherwise, the bootkit code is essentially no different from the version with the MBR infector.
Kernel-mode malicious code
The main purpose of this part, which is called the bootkit described above, is to download malicious kernel-mode or rootkit code 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 C&C management server, and also payload, which is intended for implementation in processes.
Unlike Rovnix, TDL4, and other common bootkits, the kernel mode malicious code in Win32 / Gapz does not have an executable PE file structure. Instead, it is structured in a special way. The code consists of 12 blocks interconnected, each of which has a heading - a structure that stores service information about it. It has the following form:
Each of the blocks implements a certain functionality: implementation 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 dwell on a special tool that Microsoft decided to use to combat various kinds of threats, especially rootkits and bootkits that try to load themselves before other drivers in the system. The tool is called ELAM, Early Launch Anti-Malware Module, and is shipped with the operating system starting with Windows 8. In essence, ELAM is a driver provided by an anti-virus vendor, which 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 adhere to. One of the main features of this tool is that it is guaranteed to allow the AV driver to boot before the other drivers in the system, and thus
We note that ELAM alone cannot be so effective at 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 active ELAM, making it a useless tool. Since the bootkit boots before OS initialization, it will already be in memory at the moment ELAM takes control.
At the same time, it should be noted that ELAM is part of Microsoft's declared Safe Boot concept or scheme - Secure Boot. In the case of Secure Boot, the software built into UEFI (such software takes 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 Secure Boot concept, in conjunction with the new UEFI standard, is designed to prevent the critical boot structures from compromising OS / UEFI data structures.