Security-X
Forum Security-X => News => Discussion démarrée par: SX-News le février 20, 2011, 20:28:30
-
Analysis of MBR File System Infector
Description : It is very common to see Portable Executable (PE) file infector viruses. It is a bit more unusual to see file infection via the raw file system — in this case, a Master Boot Record (MBR) file system infector.
Partly this is because PE infectors are less troublesome to create — they can be more robust, are easier to develop, and to control. In contrast, MBR infectors are more complex and their size is limited to 62 sectors (7C00H). Also, there's less room for error — a small mistake or bug in an MBR file system infector causes the system to be unbootable.
So an MBR file system infector such as Trojan:W32/Smitnyl.A (98b349c7880eda46c63ae1061d2475181b2c9d7b), which appears to be distributed via some free file-sharing networks, seems worth a quick analysis, even if it only targets one portable executable system file and the infection is straightforward compared to common virus file infectors.
Smitnyl.A first infects the MBR via raw disk access. Then it replaces it with a malicious MBR containing the file infector routine (stored at sector 32).
Image 1 & 2: Overwriting original MBR, Part 1 (top) and Part 2 (bottom)
<img width="748" height="108" border="1" src="http://www.f-secure.com/weblog/archives/Figure1_overwriting_original_mbr.png" alt="1: Overwriting original MBR" />
<img width="749" height="219" border="1" src="http://www.f-secure.com/weblog/archives/Figure2_overwriting_original_mbr.png" alt="2: Overwriting original MBR" />
Why an MBR File System Infector? Probably because it can bypass Windows File Protection (WFP). As WFP is running in protected mode, any WFP-protected file will be restored immediately if the file is replaced.
The original MBR is stored at sector 5, while the infector payload starts at sector 39 with size A00H. This payload will be overwritten to the Windows critical system file, userinit.exe.
Image 3 & 4: Hex views of infected MBR (left) and original MBR (bottom)
<img width="551" height="495" border="1" src="http://www.f-secure.com/weblog/archives/Figure3_hex_view_infected_mbr.png" alt="3: Hex view of infected MBR" />
<img width="757" height="444" border="1" src="http://www.f-secure.com/weblog/archives/Figure4_hex_view_original_mbr.png" alt="4: Hex view of original MBR" />
Image 5: Hex View of MBR File System Infector Routine
<img width="756" height="491" border="1" src="http://www.f-secure.com/weblog/archives/Figure5_hex_view_mbr_infection.png" alt="5: Hex View MBR File System Infector Routine" />
Image 6: Hex View of Userinit Infector Payload
<img width="751" height="478" border="1" src="http://www.f-secure.com/weblog/archives/Figure6_hex_view_userinit_payload.png" alt="6: Hex View Userinit Infector Payload" />
Why Userinit? Possibly because it is one of the processes launched automatically when the system starts, allowing the malware to execute automatically when the system starts.
Smitnyl infects Userinit from the first stage of the boot sequence. When the MBR is loaded to 0x7C00, it determines the active partition from the partition table and also the starting offset of boot sector.
It then checks the machines file system type:
Image 7: Determine Boot Sector Type
<img width="534" height="623" border="1" src="http://www.f-secure.com/weblog/archives/Figure7_determine_bootsector_type.png" alt="7: Determine Boot Sector Type" />
If an NTFS file system is found, it parses the Master File Table (MFT) and reads the attributes of $ROOT (.) file record to locate the $INDEX_ALLOCATION attribute, in order to determine the raw data of Userinit in the disk (assuming the MFT is parsed correctly). Smitnyl will check for the Windows path from $ROOT down to the System32 directory, where userinit.exe is located.
Image 8 & 9: Locate Userinit.exe, Part 1
<img width="547" height="640" border="1" src="http://www.f-secure.com/weblog/archives/Figure8_locate_userinit.png" alt="8: Locate Userinit.exe, Part 1" />
<img width="542" height="109" border="1" src="http://www.f-secure.com/weblog/archives/Figure9_locate_userinit.png" alt="9: Locate Userinit.exe, Part 1" />
The malware uses the get_userinit_data_content_addr routine to find the userinit.exe file, which then uses the Extended Write Function (with function number ah = 43H) to offset and write the infector payload at sector 39. During the userinit.exe infection routine, the malware also checks for the presence of an infection marker at offset 0x28 (more on that later).
Image 10 & 11: Locate Userinit.exe, Part 2
<img width="698" height="312" border="1" src="http://www.f-secure.com/weblog/archives/infect_userinit_exe.png" alt="10: Locate Userinit.exe, Part 2" />
<img width="698" height="315" border="1" src="http://www.f-secure.com/weblog/archives/infect_userinit_exe_part2.png" alt="11: Locate Userinit.exe, Part 2" />
After the machine is successfully booted up with the infected MBR, userinit.exe should be infected and launched automatically. One way to identify the infected userinit.exe is by checking the file properties.
Image 12 & 13: userinit.exe Properties, original & infected
<img width="365" height="500" border="1" src="http://www.f-secure.com/weblog/archives/Smitnyl_Original_Userinit.exe.png" alt="userinit.exe Properties, original" /> <img width="363" height="502" border="1" src="http://www.f-secure.com/weblog/archives/Smitnyl_Infected_Userinit.exe.png" alt="userinit.exe Properties, infected" />
Fortunately, the difference is pretty obvious.
Let see the infected file in hex view:
Image 14: Infected Userinit
<img width="645" height="998" border="1" src="http://www.f-secure.com/weblog/archives/Figure10_infected_userinit.png" alt="14: Infected Userinit" />
Remember we mentioned the infector routine will check the infection marker 0x55AA before infecting? So what is it trying to do when it is executed? Its major payload is to launch an encoded executable, located at sector 45:
Image 15: Encoded Executable File at Sector 45
<img width="751" height="431" border="1" src="http://www.f-secure.com/weblog/archives/Figure11_encoded_executable_sector_45.png" alt="15: Encoded Executable File at Sector 45" />
It has some preliminaries to do before it starts decoding and launching the final payload:
• Check for the presence of 360safe antivirus. If found, 360safe IE browser protection is disabled.
Image 16: 360safe IE Protection Registry Key Checking
<img width="696" height="636" border="1" src="http://www.f-secure.com/weblog/archives/Figure12_ie_browser_protection_checking.png" alt="16: 360safe IE Protection Registry Key Checking" />
• Create a fake explorer.exe in a temporary folder — this is the decoded executable.
Image 17: Fake Explorer with Decoded Executable
<img width="448" height="652" border="1" src="http://www.f-secure.com/weblog/archives/Figure13_1_fake_explorer.png" alt="17: Fake Explorer with Decoded Executable" />
Image 18: Fake Explorer with Decoded Executable
<img width="501" height="665" border="1" src="http://www.f-secure.com/weblog/archives/Figure13_2_fake_explorer.png" alt="18: Fake Explorer with Decoded Executable" />
• After decoding, it launches %temp%\explorer.exe using ShellExecute — this serves as a decoy to hide the infection. At the same time, it will execute the real explorer.exe using Winexec.
Image 19: Execute fake explorer.exe and launch original explorer.exe
<img width="446" height="637" border="1" src="http://www.f-secure.com/weblog/archives/Figure14_execute_fake_launch_original.png" alt="19: Execute fake explorer.exe and launch original explorer.exe" />
Once the preliminaries are done, the payload is launched.
Image 20: Final Downloader Payload
<img width="648" height="991" border="1" src="http://www.f-secure.com/weblog/archives/Figure15_final_downloader_payload.png" alt="20: Final Downloader Payload" />
Fortunately, there is nothing special about the final payload — it is merely a downloader. The infected userinit.exe disables 360safe's IE browser protection so that the downloader can retrieve files from the remote server http://[...].perfectexe.com/.
Response Post by — Low Chin Yick On 17/02/11 At 04:48 AM
Lien : http://www.f-secure.com/weblog/archives/00002101.html