Rovnix bootkit update. Article translation
This article is a translation of an article dated July 13, 2012 by Alexander Matrosov, the link to which I found at the end of the post about the leak of Carberp sources . It seemed to me interesting and I decided to translate it.
To whom it became just as interesting, welcome under cat.
We have been following the activities of the Rovnix bootkit since April 2011 (hereinafter, the speech on behalf of the author - Approx. Lane). Rovnix was the first family to use the VBR (Volume Boot Record) infection to download unsigned kernel drivers for x64 platforms. The reason for close attention was the desire of developers Rovnix to bypass the detection of antivirus. The first sample payload in the wild blocked Internet users from Russia and forced them to send SMS to a short number to unlock (Hasta La Vista, Bootkit: Exploiting the VBR) .
These options with Internet blocking have stopped using the bootkit component in the summer of 2011. At that time, the Rovnix framework was sold to Carberp developers responsible for the Hodprot / Origami botnet (Evolution of Win32Carberp: going deeper) . Carberp developers only used this framework until the end of 2011. We have no information about other framework sales. We only have information confirming that the infection rate is not high with a code based on the Rovnix bootkit. A few days ago we received some interesting samples and their quick analysis showed the Rovnix.B-like modification of the VBR infection scenario.
After unpacking the dropper, we found a typical component to prepare for the next steps of installing the BkSetup.dll Rovnix bootkit module. The compilation date of the BkSetup.dll module looked fresh and dated June 24, 2012 (of course, it is possible to fake the date, but until then the developers have not changed it).
')
Also found version information in the resource segment BkSetup.dll. Here she is:
The file version was changed to 2.4: earlier, Carberp used BkSetup.dll version 2.1 and stored the information in the debug line sent by C & C as debug information.
The basic functionality of BkSetup.dll focuses on the process of infecting and creating hidden storage. The scheme of appeals of the main BkSetup.dll procedures is as follows:
The new sample with the new version of Rovnix bootkit is an indirect evidence of the resumption of sales activity, and in the near future we will be able to disclose the details of the relationship between Rovnix and other malware. And now we dive into the technical details of Rovnix.D modification.
With the modification of Rovnix.B, the boot code used polymorphism to bypass the detection of antivirus static signatures. Initially, the polymorphic code was found in Carberp samples using the bootkit. The following figure shows the basics of a polymorphic code.
A simple polymorphism trick based on permutations of the main blocks of code always results in malware control over the decoded VBR code. The main blocks of code are as follows:
[Polymorphic code Rovnix.B]
The reason for using a polymorphic code is to bypass the detection of a static signature by antiviruses: this code can only be detected using emulation. The emulation technique is closely related to the sandbox, where the code is executed in a safe virtual environment for the purpose of its dynamic analysis. Differences between Rovnix.D and Rovnix.B modifications are presented in this graph:
[Rovnix.D option (top) and Rovnix.B option (bottom)]
The storage location of the encrypted VBR code was also changed, and after executing the polymorphic code, control is transferred to the decrypted VBR code. The unequal arrangement of the encrypted VBR code is as follows:
We also found changes in the function of decrypting and reading the unsigned driver from the RAW sectors of the hard disk. These sectors are not used in shared hidden storage, but only as a place to store a malicious driver that injects payloads into specified user processes on an infected machine. The differences can be seen in the following image:
[Rovnix.D option (top) and Rovnix.B option (bottom)]
All these changes are aimed at bypassing antivirus detection and do not reflect fundamental changes in the overall structure of the Rovnix bootkit.
The structure of the hidden file system is similar to the structure from previous modifications of Rovnix and has already been described in previous blog posts (Rovnix Reloaded: new step of evolution) REFERENCE HERE. However, minor changes were found in the file system initialization code. A strange function call was detected to read the INJECTS.SYS file from the hidden storage.
This interesting feature extracts one or two paths from the INJECTS.SYS file to the files on the standard file system. The function code is shown in the figure below:
Flow control will never reach the execution of this code, because the condition is always NULL and control will never be transferred to this code. In my opinion, this modification in Rovnix.D was used for tests, and we do not see many detections in the wild. It seems that Rovnix.D is a transitional version in preparation for something else, but at the moment we do not have a clear understanding of what it can be.
The payload module includes the ability to download and run additional modules from the C & C server. This module does not provide hooks and other malicious changes to system memory, and is generally not detected by the most common antivirus programs.
C & C Domain is rtttt-windows.com
The payload module is multi-threaded and can communicate with a malicious driver. To ensure synchronization, the payload generates a mutex: Global <Generated_string>. The call graph for the main thread looks like this:
The payload module can also send encrypted arrays to a malicious driver for subsequent writing to hidden storage and embedding in processes. Prior to this, Rovnix did not use the functionality for multiple implementations, and provided only one payload module. Rovnix.D can use several payloads and can be used to lease a botnet, and at the end of the lease term the payload will be changed.
At the moment, the changes can be seen in the perspective of complex threats for the x64 platform. Family
Sirefef (ZeroAccess) has migrated into user mode, in its latest versions (ZeroAccess: code injection chronicles) REFERENCE HERE. Olmarik / Olmasco (TDL4 and MaxSS modifications) does not have a large number of infections in the wild and stopped developing (The Evolution of TDL: Conquering x64). Why do rootkits / bootkits die for the 64th platform? In my opinion, the number of ways to infect 64-bit systems is very limited, and the search for something new requires a lot of time and considerable experience from the developer. Most bootkit infections have used MBR modifications, but this method is rather old and by now the most common antivirus programs provide a check for changing the MBR. The Rovnix family uses other methods of infection with
modifications of VBR, but a constant stream of new modifications requires a large amount of debugging information about C & C. The complexity of developing and debugging on multiple platforms is one of the reasons for the high prices of the Rovnix bootkit framework. For example, a full-featured builder costs $ 60,000, including basic support for six months. This is a price only for the bootkit, eliminating the cost of privilege elevation exploits in order to allow access to allow measurement to be made deep in the system.
In the future, sophisticated stealth technologies will mainly be used for targeted attacks, since the cost of purchasing and using them is not comparable to the expected profit for typical cybercriminals. Now we have less than ten families of x64 bootkits and their activity in the wild is also declining.
SHA1 hashes of the mentioned Rovnix.D droppers:
C1C0CC056D31222D3735E6801ACBA763AC024C5B
764B4F0202097F2B41A2821D30A7424490BF3A42
Special thanks to my colleagues Pavel Smierciak and Maxim Grigoryev.
Aleksandr Matrosov, Security Intelligence Team Lead
To whom it became just as interesting, welcome under cat.
We have been following the activities of the Rovnix bootkit since April 2011 (hereinafter, the speech on behalf of the author - Approx. Lane). Rovnix was the first family to use the VBR (Volume Boot Record) infection to download unsigned kernel drivers for x64 platforms. The reason for close attention was the desire of developers Rovnix to bypass the detection of antivirus. The first sample payload in the wild blocked Internet users from Russia and forced them to send SMS to a short number to unlock (Hasta La Vista, Bootkit: Exploiting the VBR) .
These options with Internet blocking have stopped using the bootkit component in the summer of 2011. At that time, the Rovnix framework was sold to Carberp developers responsible for the Hodprot / Origami botnet (Evolution of Win32Carberp: going deeper) . Carberp developers only used this framework until the end of 2011. We have no information about other framework sales. We only have information confirming that the infection rate is not high with a code based on the Rovnix bootkit. A few days ago we received some interesting samples and their quick analysis showed the Rovnix.B-like modification of the VBR infection scenario.
After unpacking the dropper, we found a typical component to prepare for the next steps of installing the BkSetup.dll Rovnix bootkit module. The compilation date of the BkSetup.dll module looked fresh and dated June 24, 2012 (of course, it is possible to fake the date, but until then the developers have not changed it).
')
Also found version information in the resource segment BkSetup.dll. Here she is:
The file version was changed to 2.4: earlier, Carberp used BkSetup.dll version 2.1 and stored the information in the debug line sent by C & C as debug information.
The basic functionality of BkSetup.dll focuses on the process of infecting and creating hidden storage. The scheme of appeals of the main BkSetup.dll procedures is as follows:
The new sample with the new version of Rovnix bootkit is an indirect evidence of the resumption of sales activity, and in the near future we will be able to disclose the details of the relationship between Rovnix and other malware. And now we dive into the technical details of Rovnix.D modification.
Polymorphic boot code
With the modification of Rovnix.B, the boot code used polymorphism to bypass the detection of antivirus static signatures. Initially, the polymorphic code was found in Carberp samples using the bootkit. The following figure shows the basics of a polymorphic code.
A simple polymorphism trick based on permutations of the main blocks of code always results in malware control over the decoded VBR code. The main blocks of code are as follows:
[Polymorphic code Rovnix.B]
The reason for using a polymorphic code is to bypass the detection of a static signature by antiviruses: this code can only be detected using emulation. The emulation technique is closely related to the sandbox, where the code is executed in a safe virtual environment for the purpose of its dynamic analysis. Differences between Rovnix.D and Rovnix.B modifications are presented in this graph:
[Rovnix.D option (top) and Rovnix.B option (bottom)]
The storage location of the encrypted VBR code was also changed, and after executing the polymorphic code, control is transferred to the decrypted VBR code. The unequal arrangement of the encrypted VBR code is as follows:
We also found changes in the function of decrypting and reading the unsigned driver from the RAW sectors of the hard disk. These sectors are not used in shared hidden storage, but only as a place to store a malicious driver that injects payloads into specified user processes on an infected machine. The differences can be seen in the following image:
[Rovnix.D option (top) and Rovnix.B option (bottom)]
All these changes are aimed at bypassing antivirus detection and do not reflect fundamental changes in the overall structure of the Rovnix bootkit.
Hidden Storage Changes
The structure of the hidden file system is similar to the structure from previous modifications of Rovnix and has already been described in previous blog posts (Rovnix Reloaded: new step of evolution) REFERENCE HERE. However, minor changes were found in the file system initialization code. A strange function call was detected to read the INJECTS.SYS file from the hidden storage.
This interesting feature extracts one or two paths from the INJECTS.SYS file to the files on the standard file system. The function code is shown in the figure below:
Flow control will never reach the execution of this code, because the condition is always NULL and control will never be transferred to this code. In my opinion, this modification in Rovnix.D was used for tests, and we do not see many detections in the wild. It seems that Rovnix.D is a transitional version in preparation for something else, but at the moment we do not have a clear understanding of what it can be.
Payload
The payload module includes the ability to download and run additional modules from the C & C server. This module does not provide hooks and other malicious changes to system memory, and is generally not detected by the most common antivirus programs.
C & C Domain is rtttt-windows.com
The payload module is multi-threaded and can communicate with a malicious driver. To ensure synchronization, the payload generates a mutex: Global <Generated_string>. The call graph for the main thread looks like this:
The payload module can also send encrypted arrays to a malicious driver for subsequent writing to hidden storage and embedding in processes. Prior to this, Rovnix did not use the functionality for multiple implementations, and provided only one payload module. Rovnix.D can use several payloads and can be used to lease a botnet, and at the end of the lease term the payload will be changed.
Conclusion
At the moment, the changes can be seen in the perspective of complex threats for the x64 platform. Family
Sirefef (ZeroAccess) has migrated into user mode, in its latest versions (ZeroAccess: code injection chronicles) REFERENCE HERE. Olmarik / Olmasco (TDL4 and MaxSS modifications) does not have a large number of infections in the wild and stopped developing (The Evolution of TDL: Conquering x64). Why do rootkits / bootkits die for the 64th platform? In my opinion, the number of ways to infect 64-bit systems is very limited, and the search for something new requires a lot of time and considerable experience from the developer. Most bootkit infections have used MBR modifications, but this method is rather old and by now the most common antivirus programs provide a check for changing the MBR. The Rovnix family uses other methods of infection with
modifications of VBR, but a constant stream of new modifications requires a large amount of debugging information about C & C. The complexity of developing and debugging on multiple platforms is one of the reasons for the high prices of the Rovnix bootkit framework. For example, a full-featured builder costs $ 60,000, including basic support for six months. This is a price only for the bootkit, eliminating the cost of privilege elevation exploits in order to allow access to allow measurement to be made deep in the system.
In the future, sophisticated stealth technologies will mainly be used for targeted attacks, since the cost of purchasing and using them is not comparable to the expected profit for typical cybercriminals. Now we have less than ten families of x64 bootkits and their activity in the wild is also declining.
SHA1 hashes of the mentioned Rovnix.D droppers:
C1C0CC056D31222D3735E6801ACBA763AC024C5B
764B4F0202097F2B41A2821D30A7424490BF3A42
Special thanks to my colleagues Pavel Smierciak and Maxim Grigoryev.
Aleksandr Matrosov, Security Intelligence Team Lead
Source: https://habr.com/ru/post/184968/
All Articles