February 20, 2011 at 16:20Analysis of Smitnyl.A, the first hybrid bootkit and file infection
Hello!
I was a little inspired by the public reaction to my article on online sandboxes , as well as an interesting post from hormold , where it became possible to analyze the existing options for infecting computers online. And on the basis of this, I decided that perhaps some material on some modern mechanisms of the operation of malicious programs would be of interest.
I think that the mechanism of operation of existing file infectors such as Sality and Virut will not be secret. Of course, the essence of the work of such infectors is well described, and therefore it is easy to develop a new version, debugging it does not cause problems. Much more interesting will be the description of a new mechanism - infection of the file from the bootloader in the MBR. Firstly, such malware should be more complex, there is a limit on the length of the code - 62 sectors (7C00H), and in addition, special requirements are made for the absence of bugs - the slightest error can lead to a system boot failure.
The only unique example of such malware at the moment is Trojan: W32 / Smitnyl.A, which is distributed over some file-sharing networks. We will consider it today.
The Smitnyl.A infector at startup infects the MBR through direct disk access. It replaces the original MBR with a malicious version containing a file infection procedure in sector 32.
Figures 1 and 2: Overwriting the original MBR, Part 1 (top) and 2 (bottom)
Why did the author choose such a difficult way to infect the executable file? Probably because this method allows you to bypass the Windows file protection system (WFP), which allows you to effectively infect system files without the risk that they will be subsequently restored by WFP.
The original MBR is stored in sector 5, while the A00H-sized infectious procedure is located in sector 39. The target of the infection is the critical system file userinit.exe.
Figures 3: Malicious MBR code
Figures 4: Original MBR code
Figure 5: The infection code in the MBR
Figure 6: Malicious code injected into userinit.exe
Why is userinit.exe chosen as the target of infection? This is probably due to the fact that userinit.exe is one of the first processes that start when the system boots, which allows the malware to start at an early stage, before loading a number of firewalls and antiviruses, effectively performing its functionality. Experts may argue that smss.exe, csrss.exe is even earlier. Well, perhaps such an early download is inconvenient due to the absence of any critical processes for the malware.
Smitnyl infects userinit.exe during the early boot phase, when the MBR code reaches 0x7C00, the active partition from the partition table and the offset of the start area of the boot sector are determined.
Then the type of the file system is checked.
Figure 7: Determining the type of boot sector
If an NTFS system is detected, the code parses the Master File Table (MFT) and reads the attributes of the file record $ ROOT (.) To find the attribute $ INDEX_ALLOCATION. This procedure allows you to find the location of userint.exe on the disk (provided that the MFT is correctly parsed). Smitnyl checks all paths, from $ ROOT to the System32 folder, where userinit.exe is located.
Figure 8: Detecting Userinit.exe, part 1
Figure 9: Detecting Userinit.exe, part 1
The malware uses the get_userinit_data_content_addr procedure to find the userinit.exe file, which then uses the Extended Write Function (function number ah = 43H) to record malicious content originally located in sector 39. During the infection, userinit.exe will also check for the presence of a marker in the file by offset 0x28. why this is needed will be explained below.
Figure 10: Detection of Userinit.exe, part 2
Figure 11: Detection of Userinit.exe, part 2
As a result of loading an infected machine, userinit.exe becomes infected and then starts (already directly to the OS). One way to detect userinit.exe infection is to view the properties of a file in an elementary manner.
Figures 12 and 13: Properties of userinit.exe, original (above) and infected (below)
Fortunately, the difference is very obvious.
Let's now see the code of the infected file.
Figure 14: Infected Userinit.exe
Here it becomes clear why the infector during infection looked for the 0x55AA marker before infection - this prevents re-infection. So what happens when an infected file is launched? The main goal is to launch a cryptographic malicious code located in sector 45.
Figure 15: Crypted executable code in sector 45
The code has a number of preliminary procedures prior to decoding and starting the main functionality.
• Check for the availability of 360safe Internet security system. If it is, then it is turned off.
Figure 16: Verifying 360safe System Availability
• Creating a substitute explorer.exe in a temporary folder is a decoded executable code.
Figure 17: Substitute Explorer.exe
Figure 18: Substitute Explorer.exe
• After decoding,% temp% \ explorer.exe is launched using ShellExecute - userinit.exe performs exactly the same operation with the original explorer.exe! At the same time, the original explorer.exe is launched through Winexec.
Figure 19: Performing a substitute explorer.exe and the original explorer.exe
After that, the main malware functionality is executed - this is a classic downloader that downloads and executes files.
Figure 20: Downloader functionality
As a result, by disabling 360safe protection, it becomes possible to efficiently download and execute files from a remote server http: // [...] .perfectexe.com / and others.
Translation of the F-Secure blog .
PS The description of manual malware removal promised to readers is here .
I was a little inspired by the public reaction to my article on online sandboxes , as well as an interesting post from hormold , where it became possible to analyze the existing options for infecting computers online. And on the basis of this, I decided that perhaps some material on some modern mechanisms of the operation of malicious programs would be of interest.
I think that the mechanism of operation of existing file infectors such as Sality and Virut will not be secret. Of course, the essence of the work of such infectors is well described, and therefore it is easy to develop a new version, debugging it does not cause problems. Much more interesting will be the description of a new mechanism - infection of the file from the bootloader in the MBR. Firstly, such malware should be more complex, there is a limit on the length of the code - 62 sectors (7C00H), and in addition, special requirements are made for the absence of bugs - the slightest error can lead to a system boot failure.
The only unique example of such malware at the moment is Trojan: W32 / Smitnyl.A, which is distributed over some file-sharing networks. We will consider it today.
The Smitnyl.A infector at startup infects the MBR through direct disk access. It replaces the original MBR with a malicious version containing a file infection procedure in sector 32.
Figures 1 and 2: Overwriting the original MBR, Part 1 (top) and 2 (bottom)
Why did the author choose such a difficult way to infect the executable file? Probably because this method allows you to bypass the Windows file protection system (WFP), which allows you to effectively infect system files without the risk that they will be subsequently restored by WFP.
The original MBR is stored in sector 5, while the A00H-sized infectious procedure is located in sector 39. The target of the infection is the critical system file userinit.exe.
Figures 3: Malicious MBR code
Figures 4: Original MBR code
Figure 5: The infection code in the MBR
Figure 6: Malicious code injected into userinit.exe
Why is userinit.exe chosen as the target of infection? This is probably due to the fact that userinit.exe is one of the first processes that start when the system boots, which allows the malware to start at an early stage, before loading a number of firewalls and antiviruses, effectively performing its functionality. Experts may argue that smss.exe, csrss.exe is even earlier. Well, perhaps such an early download is inconvenient due to the absence of any critical processes for the malware.
Smitnyl infects userinit.exe during the early boot phase, when the MBR code reaches 0x7C00, the active partition from the partition table and the offset of the start area of the boot sector are determined.
Then the type of the file system is checked.
Figure 7: Determining the type of boot sector
If an NTFS system is detected, the code parses the Master File Table (MFT) and reads the attributes of the file record $ ROOT (.) To find the attribute $ INDEX_ALLOCATION. This procedure allows you to find the location of userint.exe on the disk (provided that the MFT is correctly parsed). Smitnyl checks all paths, from $ ROOT to the System32 folder, where userinit.exe is located.
Figure 8: Detecting Userinit.exe, part 1
Figure 9: Detecting Userinit.exe, part 1
The malware uses the get_userinit_data_content_addr procedure to find the userinit.exe file, which then uses the Extended Write Function (function number ah = 43H) to record malicious content originally located in sector 39. During the infection, userinit.exe will also check for the presence of a marker in the file by offset 0x28. why this is needed will be explained below.
Figure 10: Detection of Userinit.exe, part 2
Figure 11: Detection of Userinit.exe, part 2
As a result of loading an infected machine, userinit.exe becomes infected and then starts (already directly to the OS). One way to detect userinit.exe infection is to view the properties of a file in an elementary manner.
Figures 12 and 13: Properties of userinit.exe, original (above) and infected (below)
Fortunately, the difference is very obvious.
Let's now see the code of the infected file.
Figure 14: Infected Userinit.exe
Here it becomes clear why the infector during infection looked for the 0x55AA marker before infection - this prevents re-infection. So what happens when an infected file is launched? The main goal is to launch a cryptographic malicious code located in sector 45.
Figure 15: Crypted executable code in sector 45
The code has a number of preliminary procedures prior to decoding and starting the main functionality.
• Check for the availability of 360safe Internet security system. If it is, then it is turned off.
Figure 16: Verifying 360safe System Availability
• Creating a substitute explorer.exe in a temporary folder is a decoded executable code.
Figure 17: Substitute Explorer.exe
Figure 18: Substitute Explorer.exe
• After decoding,% temp% \ explorer.exe is launched using ShellExecute - userinit.exe performs exactly the same operation with the original explorer.exe! At the same time, the original explorer.exe is launched through Winexec.
Figure 19: Performing a substitute explorer.exe and the original explorer.exe
After that, the main malware functionality is executed - this is a classic downloader that downloads and executes files.
Figure 20: Downloader functionality
As a result, by disabling 360safe protection, it becomes possible to efficiently download and execute files from a remote server http: // [...] .perfectexe.com / and others.
Translation of the F-Secure blog .
PS The description of manual malware removal promised to readers is here .