Whistler Bootkit - our regiment arrived
Recently, user complaints about the presence of malicious files have appeared and are gradually gaining momentum, which cannot be deleted in any way. These files can be seen in the list of active processes, and characteristically - they are all located in the C: \ System Volume Information \ folder (or subfolders) and run with NT-AUTHORITY \ SYSTEM rights.
If you find this behavior - congratulations, you picked up the Whistrler Bootkit. About him and will be discussed today.
At the moment, I, like some of my friends in antivirus companies, do not have an infector of this bootkit. However, it is clear that the malware is not a new invention, but is a continuation of the idea of ​​Peter Kleissner, expressed in the Stoned PoC project . In this case, the virmaker probably copied the code frankly, without even bothering to add or change it. So, the story ...
Until some time, the Stoned Peter Kleissner project was a way to show the ability to load code into the system’s memory before the actual system load. This made it possible to gain complete control over the OS: starting from executing arbitrary processes with arbitrary permissions to bypassing the Windows security system and controlling the license key on Vista / Seven. The project developed quite stably within the framework of open source, until Kaspersky Lab and some other organizations sued the author for allegedly distributing malicious software. I will not comment on this act and how reasonable it is, but since the end of last year, the author stopped distributing new versions and significantly cut down the available public version. Development of support for Linux platforms was also suspended at the time of the trial. And Whistler appeared ...
')
According to Peter, the leak most likely occurred before January of this year, since the first “promotional” move about Whistler appeared on this blog in January. A month later, the blogger was forced to throw out clearly advertising information, as well as information about the cost of the bootkit and the cost of supporting it, making the article more “informational” rather than advertising. Now the “offsite” of the bootkit is located here , where there is less information, but I want money more openly :)
Based on this date, it can be assumed that Whistler is based on Stoned v2 Alpha 3 dated October 20, 2009. It was this version that came with the compiled infector and disinfector files. Taking it as a working hypothesis, in the absence of a dropper, the following information is made precisely on the basis of the work and capabilities of this version of Stoned.
Initially, a variety of infection methods were well documented: autorun from flash drives, pdf exploits (infections from an infected pdf file), infectors, infections when loading special LiveCD / LiveUFD images. Therefore, an infector can be anything that makes it difficult to understand how Whistler is transmitted and where it is taken.
The list of infected OS is impressive: 2000, XP, Vista, Seven, Server 2003, Server 2008, supports x64. At the same time it works correctly with hardware and software encryption of the entire contents of the hard drive. Disabling the ability to modify the MBR in the BIOS does not help (it worked only in DOS and win95 / 98, so it is already irrelevant in principle).
On the infected system, the boot loader in the MBR is patched to the initial execution of the bootkit code with the subsequent transfer of control to the original loader. The original bootloader, bootkit code and its plugins are stored in an unallocated area at the end of the physical disk in a special file system (RawFS - this was in the original Stoned). In this case, the bootkit code is the first file of this system and its location is precisely known. This is an important point, which allows even fully encrypted disks to be infected, because the bootloader is not encrypted in them and the beginning of the unpartitioned area is known exactly - and this is quite enough.
After loading the bootkit code is placed in memory and allows you to implement various functionalities, loading plugins into existing processes. It is difficult to say whether the Whistler author got a public version, or a closed one (which included a ready-made application launch plugin with NT-AUTHORITY \ SYSTEM rights), but in general the execution scheme of the plugins from the bootkit is as follows.
1. The function of PsGetVersion / RtlGetVersion determines the version of the operating system.
2. Based on this information, EPROCESS and KTHREAD structures are determined.
3. A bootkit, through an asynchronous procedure call, injects the plug-in code into any user-mode executable process.
As can be seen from paragraphs. 1-2, the bootkit code allows you to work on any OS. However, its plug-ins should be distinguished from the bootkit: the latter are OS-dependent (especially the bit depth - x32 or x64), and therefore different versions for different systems can be found in the RawFS system. If the author of Whistler wrote a plugin that allows you to run processes with elevated rights - and this plugin is written under x32, then in general Whistler will infect both x32 and x64, there will be a bootkit in memory - but it will reveal its potential only on x32, since the plugin On the other bit does not work.
If the author of Whistler came across a closed version of Stoned - there was no possibility of launching and escalating the rights of processes on x64 ( NB !!! )
The original Stoned did not hide its presence and the change in the MBR (as it was done, for example, by Sinowal). In principle, this can be done with the help of an additional plug-in (see above), but it needs to be encoded. Whether the mind and capabilities of the author Whistler is enough for this is unknown.
What to do if you have a Whistler? Based on the availability of the MBR, a standard fixmbr is sufficient. However, taking into account the fact that while this virus is a “dark horse,” it is strongly recommended to first remove the MBR dumps. This can be done, for example, using the MBRWizard by running the following command line:
You can try in action and antiboot . I changed this utility a bit , or rather, automated the quarantine collection. Essence: junk conducts a study of antiboot on the following command:
Then it packs the MBR folder into a quarantine.zip zip archive with the password virus and deletes the MBR folder.
Directly in the utility there are bugs: brakes during operation and hang on some machines. It looks like this: in the console it writes:
after which - silence and for a long time. In this case, you need to ask the user to close the window and manually send the created MBR folder (there will already be dumps in it).
(According to the representative of LC, they know about this bug, but it is not possible to eliminate it for various reasons).
Of course, it is possible to use the well-known “universal” treatment of bootkits eSage Bootkit Remover . However, there is evidence that, if there is an active TDL2 infection, this tool gives out “no disk found”. This should be borne in mind when using it, but in general it is quite a good thing, also recommended for use. But not directly, but at least with the following script:
These MBR dumps can be sent to your favorite antivirus vendor :) This will allow you to assess how much Whistler differs from Stoned. I strongly suspect that there is no way :)
PS Many thanks to Peter Kleissner for the assistance provided in the preparation of this material and in general for the work done in the framework of the Stoned project.
If you find this behavior - congratulations, you picked up the Whistrler Bootkit. About him and will be discussed today.
At the moment, I, like some of my friends in antivirus companies, do not have an infector of this bootkit. However, it is clear that the malware is not a new invention, but is a continuation of the idea of ​​Peter Kleissner, expressed in the Stoned PoC project . In this case, the virmaker probably copied the code frankly, without even bothering to add or change it. So, the story ...
Until some time, the Stoned Peter Kleissner project was a way to show the ability to load code into the system’s memory before the actual system load. This made it possible to gain complete control over the OS: starting from executing arbitrary processes with arbitrary permissions to bypassing the Windows security system and controlling the license key on Vista / Seven. The project developed quite stably within the framework of open source, until Kaspersky Lab and some other organizations sued the author for allegedly distributing malicious software. I will not comment on this act and how reasonable it is, but since the end of last year, the author stopped distributing new versions and significantly cut down the available public version. Development of support for Linux platforms was also suspended at the time of the trial. And Whistler appeared ...
')
According to Peter, the leak most likely occurred before January of this year, since the first “promotional” move about Whistler appeared on this blog in January. A month later, the blogger was forced to throw out clearly advertising information, as well as information about the cost of the bootkit and the cost of supporting it, making the article more “informational” rather than advertising. Now the “offsite” of the bootkit is located here , where there is less information, but I want money more openly :)
Based on this date, it can be assumed that Whistler is based on Stoned v2 Alpha 3 dated October 20, 2009. It was this version that came with the compiled infector and disinfector files. Taking it as a working hypothesis, in the absence of a dropper, the following information is made precisely on the basis of the work and capabilities of this version of Stoned.
Initially, a variety of infection methods were well documented: autorun from flash drives, pdf exploits (infections from an infected pdf file), infectors, infections when loading special LiveCD / LiveUFD images. Therefore, an infector can be anything that makes it difficult to understand how Whistler is transmitted and where it is taken.
The list of infected OS is impressive: 2000, XP, Vista, Seven, Server 2003, Server 2008, supports x64. At the same time it works correctly with hardware and software encryption of the entire contents of the hard drive. Disabling the ability to modify the MBR in the BIOS does not help (it worked only in DOS and win95 / 98, so it is already irrelevant in principle).
On the infected system, the boot loader in the MBR is patched to the initial execution of the bootkit code with the subsequent transfer of control to the original loader. The original bootloader, bootkit code and its plugins are stored in an unallocated area at the end of the physical disk in a special file system (RawFS - this was in the original Stoned). In this case, the bootkit code is the first file of this system and its location is precisely known. This is an important point, which allows even fully encrypted disks to be infected, because the bootloader is not encrypted in them and the beginning of the unpartitioned area is known exactly - and this is quite enough.
After loading the bootkit code is placed in memory and allows you to implement various functionalities, loading plugins into existing processes. It is difficult to say whether the Whistler author got a public version, or a closed one (which included a ready-made application launch plugin with NT-AUTHORITY \ SYSTEM rights), but in general the execution scheme of the plugins from the bootkit is as follows.
1. The function of PsGetVersion / RtlGetVersion determines the version of the operating system.
2. Based on this information, EPROCESS and KTHREAD structures are determined.
3. A bootkit, through an asynchronous procedure call, injects the plug-in code into any user-mode executable process.
As can be seen from paragraphs. 1-2, the bootkit code allows you to work on any OS. However, its plug-ins should be distinguished from the bootkit: the latter are OS-dependent (especially the bit depth - x32 or x64), and therefore different versions for different systems can be found in the RawFS system. If the author of Whistler wrote a plugin that allows you to run processes with elevated rights - and this plugin is written under x32, then in general Whistler will infect both x32 and x64, there will be a bootkit in memory - but it will reveal its potential only on x32, since the plugin On the other bit does not work.
If the author of Whistler came across a closed version of Stoned - there was no possibility of launching and escalating the rights of processes on x64 ( NB !!! )
The original Stoned did not hide its presence and the change in the MBR (as it was done, for example, by Sinowal). In principle, this can be done with the help of an additional plug-in (see above), but it needs to be encoded. Whether the mind and capabilities of the author Whistler is enough for this is unknown.
What to do if you have a Whistler? Based on the availability of the MBR, a standard fixmbr is sufficient. However, taking into account the fact that while this virus is a “dark horse,” it is strongly recommended to first remove the MBR dumps. This can be done, for example, using the MBRWizard by running the following command line:
mbrwiz.exe /save=mbr /filename=mbr.binYou can try in action and antiboot . I changed this utility a bit , or rather, automated the quarantine collection. Essence: junk conducts a study of antiboot on the following command:
antiboot.exe -l "%cd%\log.txt" -p "%cd%\MBR"Then it packs the MBR folder into a quarantine.zip zip archive with the password virus and deletes the MBR folder.
Directly in the utility there are bugs: brakes during operation and hang on some machines. It looks like this: in the console it writes:
Antibootkt, (c) Kaspersky Lab 2010, version 1.2.1
Log started
Unpacking driver
Starting up driverafter which - silence and for a long time. In this case, you need to ask the user to close the window and manually send the created MBR folder (there will already be dumps in it).
(According to the representative of LC, they know about this bug, but it is not possible to eliminate it for various reasons).
Of course, it is possible to use the well-known “universal” treatment of bootkits eSage Bootkit Remover . However, there is evidence that, if there is an active TDL2 infection, this tool gives out “no disk found”. This should be borne in mind when using it, but in general it is quite a good thing, also recommended for use. But not directly, but at least with the following script:
start /wait remover.exe dump \\.\PhysicalDrive0 mbr.bin
remover.exe fix \\.\PhysicalDrive0These MBR dumps can be sent to your favorite antivirus vendor :) This will allow you to assess how much Whistler differs from Stoned. I strongly suspect that there is no way :)
PS Many thanks to Peter Kleissner for the assistance provided in the preparation of this material and in general for the work done in the framework of the Stoned project.
Source: https://habr.com/ru/post/96850/
All Articles