Evolution of the TDL4 rootkit or field reports of recent months
We have been closely monitoring TDL4 for a long time, as well as botnets based on this family of rootkits. But lately it has been particularly interesting to watch the release of patches by Microsoft to block the download methods for unsigned drivers for the x64 systems used to install Win64 / Olmarik.
Let's start from afar, so on April X, in addition to all the others, there was a fix KB2506014 , the task of which was to make several changes to the winloader.exe module for x64 OS versions and thus counteract the loading of unsigned drivers. Before installing the patch, BCD (Boot Configuration Data) has three different boot options:
BcdLibraryBoolean_DisableIntegrityCheck - forced disabling of the scan (most often used for debugging purposes);
BcdOSLoaderBoolean_WinPEMode - disabling in OS installation or repair mode
BcdLibraryBoolean_AllowPrereleaseSignatures - allow uploading modules having a test digital signature
')
After installing the patch, only two options remain - BcdLibraryBoolean_DisableIntegrityCheck and BcdLibraryBoolean_AllowPrereleaseSignatures , and BcdOSLoaderBoolean_WinPEMode is no longer used in the configuration of the integrity check of loaded drivers. In winloader.exe there is a special function BlImgQueryCodeIntegrityBootOptions , which returns the value that determines the checking policy.
The figure below shows the BlImgQueryCode IntegrityBootOptions procedure after the patch:
As we can see, the BcdOSLoaderBoolean_WinPEMode option is no longer used, and the boot method used in TDL4 ceased to work after that (for more details about its work, see our research report “The Evolution of TDL: Conquering x64” ).
However, a new version of the TDL4 bootkit was released recently, which bypasses this fix - the ldr16 component was changed, allowing TDL4 to regain the ability to infect x64-bit systems. In addition, malware protection against detection and deletion has been improved by improving low-level, kernel-mode event handlers related to the storage device miniport object.
After the last patch from Microsoft, it became impossible to bypass the code digital signature verification policy in WinPE mode. The creators of TDL4 had to change the tactics of infection of 64-bit OS. The idea remains the same: change the components ld32 or ldr64 in the library kdcom.dll depending on the bitness of the OS being infected. Instead of switching to WinPE mode, the new TDL4 version fixes the I_CheckImageHashInCatalog procedure. This procedure checks the integrity of the modules loaded by the winload.exe program.
Under normal conditions, when the I_CheckImageHashInCatalog procedure cannot verify the integrity of the module, a value of 0xC0000428 (STATUS_INVALID_IMAGE_HASH) is returned , preventing the system from loading. The TDL4 bootkit introduces changes that result in 0x0000C428 instead of 0xC0000428 . The new value is not an error code (in kernel mode, the most significant bit of error codes is usually set to 1). Thus, the OS does not detect the replacement of the kdcom.dll library.
The following illustration shows the code that fixes the ldr16 component in the winload.exe program on the fly:
However, this new mechanism, as it turned out, does not work quite stably. On some systems, the OS can detect changes and run a startup recovery, as shown in the following screenshot.
After a forced reboot, the system becomes completely unbootable.
The second enhancement to the new TDL4 version concerned low-level, kernel-mode event handlers related to the storage device miniport driver object. Previous versions of the malware captured a driver object belonging to the lowest-level device object in the storage stack, as shown in the following diagram:
In this case, you can quickly access the miniport device object (Hard drive PDO, hard disk PDO object) and then go through the list of adjacent device objects to get a pointer to the “real” hard disk miniport driver object. In the new TDL4 version, the hard drive miniport driver object is masked in a more sophisticated way:
In this case, the lowest-level device object in the storage stack is no longer the PDO object corresponding to the hard disk. After such a change, it becomes much more difficult to detect and remove this malware. ESET antivirus products detect the latest TDL4 dropper as Win32 / Olmarik.AMN, and all treatment procedures work correctly.
In the previous generation TDL3, there was already a similar case, when an update from MS dropped infected systems into a blue screen.
Let's start from afar, so on April X, in addition to all the others, there was a fix KB2506014 , the task of which was to make several changes to the winloader.exe module for x64 OS versions and thus counteract the loading of unsigned drivers. Before installing the patch, BCD (Boot Configuration Data) has three different boot options:
BcdLibraryBoolean_DisableIntegrityCheck - forced disabling of the scan (most often used for debugging purposes);
BcdOSLoaderBoolean_WinPEMode - disabling in OS installation or repair mode
BcdLibraryBoolean_AllowPrereleaseSignatures - allow uploading modules having a test digital signature
')
After installing the patch, only two options remain - BcdLibraryBoolean_DisableIntegrityCheck and BcdLibraryBoolean_AllowPrereleaseSignatures , and BcdOSLoaderBoolean_WinPEMode is no longer used in the configuration of the integrity check of loaded drivers. In winloader.exe there is a special function BlImgQueryCodeIntegrityBootOptions , which returns the value that determines the checking policy.
The figure below shows the BlImgQueryCode IntegrityBootOptions procedure after the patch:
As we can see, the BcdOSLoaderBoolean_WinPEMode option is no longer used, and the boot method used in TDL4 ceased to work after that (for more details about its work, see our research report “The Evolution of TDL: Conquering x64” ).
However, a new version of the TDL4 bootkit was released recently, which bypasses this fix - the ldr16 component was changed, allowing TDL4 to regain the ability to infect x64-bit systems. In addition, malware protection against detection and deletion has been improved by improving low-level, kernel-mode event handlers related to the storage device miniport object.
After the last patch from Microsoft, it became impossible to bypass the code digital signature verification policy in WinPE mode. The creators of TDL4 had to change the tactics of infection of 64-bit OS. The idea remains the same: change the components ld32 or ldr64 in the library kdcom.dll depending on the bitness of the OS being infected. Instead of switching to WinPE mode, the new TDL4 version fixes the I_CheckImageHashInCatalog procedure. This procedure checks the integrity of the modules loaded by the winload.exe program.
Under normal conditions, when the I_CheckImageHashInCatalog procedure cannot verify the integrity of the module, a value of 0xC0000428 (STATUS_INVALID_IMAGE_HASH) is returned , preventing the system from loading. The TDL4 bootkit introduces changes that result in 0x0000C428 instead of 0xC0000428 . The new value is not an error code (in kernel mode, the most significant bit of error codes is usually set to 1). Thus, the OS does not detect the replacement of the kdcom.dll library.
The following illustration shows the code that fixes the ldr16 component in the winload.exe program on the fly:
However, this new mechanism, as it turned out, does not work quite stably. On some systems, the OS can detect changes and run a startup recovery, as shown in the following screenshot.
After a forced reboot, the system becomes completely unbootable.
The second enhancement to the new TDL4 version concerned low-level, kernel-mode event handlers related to the storage device miniport driver object. Previous versions of the malware captured a driver object belonging to the lowest-level device object in the storage stack, as shown in the following diagram:
In this case, you can quickly access the miniport device object (Hard drive PDO, hard disk PDO object) and then go through the list of adjacent device objects to get a pointer to the “real” hard disk miniport driver object. In the new TDL4 version, the hard drive miniport driver object is masked in a more sophisticated way:
In this case, the lowest-level device object in the storage stack is no longer the PDO object corresponding to the hard disk. After such a change, it becomes much more difficult to detect and remove this malware. ESET antivirus products detect the latest TDL4 dropper as Win32 / Olmarik.AMN, and all treatment procedures work correctly.
In the previous generation TDL3, there was already a similar case, when an update from MS dropped infected systems into a blue screen.
Source: https://habr.com/ru/post/120261/
All Articles