Analysis of Smitnyl.A - the first hybrid of the bootkit and file infector
Hello!
I was a little inspired by the reaction of society 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 it would be of interest to present material on some modern mechanisms for the operation of malware.
I think the majority will not be a secret mechanism for the operation of existing file infectors like Sality and Virut. 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 the new mechanism - file infection from the bootloader in the MBR. Firstly, such a malware should be more complex, there is a limit on the length of the code - 62 sectors (7C00H), and in addition there are special requirements for the absence of bugs - the slightest mistake can lead to a system boot failure.
')
The only unique at the moment example of such malware is Trojan: W32 / Smitnyl.A, distributed over some file-sharing networks. We will consider it today.
The infector Smitnyl.A on startup infects the MBR through direct disk access. It replaces the original MBR with a malicious variant containing a file infector 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? This is probably because this method allows you to bypass the Windows File Protection System (WFP), which allows you to effectively infect system files without the danger that they will be later restored by WFP.
The original MBR is stored in sector 5, while the infector procedure of size A00H is located in sector 39. The aim of the infector is the critical system file userinit.exe.
Figures 3: Malicious MBR code
Figures 4: Code of the original MBR
Figure 5: MBR infector code
Figure 6: Malicious code injected into userinit.exe
Why is the purpose of infection selected userinit.exe? This is probably done for the reason that userinit.exe is one of the first processes that start when the system is booted, which allows the malware to run at an early stage, before loading a number of firewalls and antiviruses, effectively performing its functionality. Experts may argue that even earlier are smss.exe, csrss.exe. Well, perhaps this early loading is inconvenient due to the absence of any critical processes for malware.
Smitnyl infects userinit.exe at the early system boot stage, when the MBR code execution reaches 0x7C00, the active partition is determined from the partition table and the offset of the starting area of the boot sector.
Then the file system type is checked.
Figure 7: Defining the boot sector type
In case NTFS is detected, the Master File Table (MFT) parses code and reads the $ ROOT (.) File record attributes to find the $ INDEX_ALLOCATION attribute. This procedure allows you to find the location of userint.exe on the disk (assuming that the MFT is parsed correctly). Smitnyl checks all paths starting from $ ROOT to the System32 folder where userinit.exe is located.
Figure 8: Userinit.exe detection, part 1
Figure 9: Userinit.exe detection, part 1
The malware uses the get_userinit_data_content_addr procedure to locate the userinit.exe file, which then uses the Extended Write Function (function number ah = 43H) to write the malicious content originally located in sector 39. During the userinit.exe infection, the malware will also check for a marker in the file by offset 0x28. why it is needed will be explained below.
Figure 10: Userinit.exe detection, part 2
Figure 11: Userinit.exe detection, part 2
As a result of booting an infected machine, userinit.exe gets infected and then it starts (directly the OS itself). One way to detect userinit.exe infection is to look at the properties of the file.
Figures 12 and 13: Properties of userinit.exe, original (above) and infected (below)
Fortunately, the difference is quite obvious.
Let's now look at the code of the infected file.
Figure 14: Infected Userinit.exe
Here it becomes clear why the infection sector, when infected, looked for the 0x55AA marker before the infection occurred - this is to prevent re-infection. So what happens when you run an infected file? The main goal is the launch of encrypted malicious code located in sector 45.
Figure 15: Encrypted executable code in sector 45
The code has a number of preliminary procedures preceding the decoding and start of the main functionality.
• Check for the availability of the 360safe Internet security system. If it is, then it is turned off.
Figure 16: Checking the availability of the 360safe system
• Creating a substitute explorer.exe in a temporary folder is a decoded executable code.
Figure 17: Swapping Explorer.exe
Figure 18: Swap Explorer.exe
• After decoding, run% temp% \ explorer.exe through ShellExecute - userinit.exe performs an absolutely similar operation with the original explorer.exe! At the same time, the original explorer.exe is launched via Winexec.
Figure 19: Execution of the substitute explorer.exe and the original explorer.exe
After that, the main functionality of the malware is executed - this is a classic downloader that loads and executes files.
Figure 20: Downloader functionality
In total, by turning off 360safe protection, it becomes possible to efficiently download and execute files from a remote server http: // [...] .perfectexe.com / and others.
Translation blog F-Secure .
PS The description of removing the malware manually promised to readers is here .
I was a little inspired by the reaction of society 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 it would be of interest to present material on some modern mechanisms for the operation of malware.
I think the majority will not be a secret mechanism for the operation of existing file infectors like Sality and Virut. 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 the new mechanism - file infection from the bootloader in the MBR. Firstly, such a malware should be more complex, there is a limit on the length of the code - 62 sectors (7C00H), and in addition there are special requirements for the absence of bugs - the slightest mistake can lead to a system boot failure.
')
The only unique at the moment example of such malware is Trojan: W32 / Smitnyl.A, distributed over some file-sharing networks. We will consider it today.
The infector Smitnyl.A on startup infects the MBR through direct disk access. It replaces the original MBR with a malicious variant containing a file infector 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? This is probably because this method allows you to bypass the Windows File Protection System (WFP), which allows you to effectively infect system files without the danger that they will be later restored by WFP.
The original MBR is stored in sector 5, while the infector procedure of size A00H is located in sector 39. The aim of the infector is the critical system file userinit.exe.
Figures 3: Malicious MBR code
Figures 4: Code of the original MBR
Figure 5: MBR infector code
Figure 6: Malicious code injected into userinit.exe
Why is the purpose of infection selected userinit.exe? This is probably done for the reason that userinit.exe is one of the first processes that start when the system is booted, which allows the malware to run at an early stage, before loading a number of firewalls and antiviruses, effectively performing its functionality. Experts may argue that even earlier are smss.exe, csrss.exe. Well, perhaps this early loading is inconvenient due to the absence of any critical processes for malware.
Smitnyl infects userinit.exe at the early system boot stage, when the MBR code execution reaches 0x7C00, the active partition is determined from the partition table and the offset of the starting area of the boot sector.
Then the file system type is checked.
Figure 7: Defining the boot sector type
In case NTFS is detected, the Master File Table (MFT) parses code and reads the $ ROOT (.) File record attributes to find the $ INDEX_ALLOCATION attribute. This procedure allows you to find the location of userint.exe on the disk (assuming that the MFT is parsed correctly). Smitnyl checks all paths starting from $ ROOT to the System32 folder where userinit.exe is located.
Figure 8: Userinit.exe detection, part 1
Figure 9: Userinit.exe detection, part 1
The malware uses the get_userinit_data_content_addr procedure to locate the userinit.exe file, which then uses the Extended Write Function (function number ah = 43H) to write the malicious content originally located in sector 39. During the userinit.exe infection, the malware will also check for a marker in the file by offset 0x28. why it is needed will be explained below.
Figure 10: Userinit.exe detection, part 2
Figure 11: Userinit.exe detection, part 2
As a result of booting an infected machine, userinit.exe gets infected and then it starts (directly the OS itself). One way to detect userinit.exe infection is to look at the properties of the file.
Figures 12 and 13: Properties of userinit.exe, original (above) and infected (below)
Fortunately, the difference is quite obvious.
Let's now look at the code of the infected file.
Figure 14: Infected Userinit.exe
Here it becomes clear why the infection sector, when infected, looked for the 0x55AA marker before the infection occurred - this is to prevent re-infection. So what happens when you run an infected file? The main goal is the launch of encrypted malicious code located in sector 45.
Figure 15: Encrypted executable code in sector 45
The code has a number of preliminary procedures preceding the decoding and start of the main functionality.
• Check for the availability of the 360safe Internet security system. If it is, then it is turned off.
Figure 16: Checking the availability of the 360safe system
• Creating a substitute explorer.exe in a temporary folder is a decoded executable code.
Figure 17: Swapping Explorer.exe
Figure 18: Swap Explorer.exe
• After decoding, run% temp% \ explorer.exe through ShellExecute - userinit.exe performs an absolutely similar operation with the original explorer.exe! At the same time, the original explorer.exe is launched via Winexec.
Figure 19: Execution of the substitute explorer.exe and the original explorer.exe
After that, the main functionality of the malware is executed - this is a classic downloader that loads and executes files.
Figure 20: Downloader functionality
In total, by turning off 360safe protection, it becomes possible to efficiently download and execute files from a remote server http: // [...] .perfectexe.com / and others.
Translation blog F-Secure .
PS The description of removing the malware manually promised to readers is here .
Source: https://habr.com/ru/post/114138/
All Articles