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)
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)
Image 5: Hex View of MBR File System Infector Routine
Image 6: Hex View of 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 machine�s file system type:
Image 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
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
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
Fortunately, the difference is pretty obvious.
Let see the infected file in hex view:
Image 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
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.
• Create a fake explorer.exe in a temporary folder — this is the decoded executable.
Image 17: Fake Explorer with Decoded Executable
Image 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
Once the preliminaries are done, the payload is launched.
Image 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/.
