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, an 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 like 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 and 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 read 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: 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 0×28 (more on that later).

Image 9: 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:

Fortunately, the difference is pretty obvious.

Let see the infected file in hex view:

Image 10: 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 11: 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 12: 360safe IE Protection Registry Key Checking

  • Create a fake explorer.exe in a temporary folder – this is the decoded executable.

Image 13_1: Fake Explorer with Decoded Executable

Image 13_2: 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 real explorer.exe using Winexec.

Image 14: Execute fake explorer.exe and launch original explorer.exe

Once the preliminaries are done, the payload is launched.

Image 15: 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/.

- Analysis by Low Chin Yick

On 17/02/11 At 04:48 AM

• 3 Tools to Scan the File System With Custom Malware Signatures
  When analyzing malware discovered during a security incident, the investigator often formulates indicators of compromise (IOCs): the signs of infection that can help the enterprise determine what sys...
• File Infector Uses Domain Generation Technique Like DOWNAD/Conficker
  Trend Micro has received reports from users about a new, dangerous file infector. This threat, detected as PE_LICAT.A, uses a domain generation algorithm, a technique last seen in WORM_DOWNAD/Confick...
• Analysis of the CVE-2011-0611 Adobe Flash Player vulnerability exploitation
  About a month ago, we blogged about an Adobe Flash Player vulnerability (CVE-2011-0609) that was actively exploited in the wild. That exploit was hidden inside a Microsoft Excel document. Ov...
• Global Spam Botnet Tracking Report (first quarter 2011)
  The following data are the result of the monitoring and recording process made by spam sensors spread all around the world to provide the trend of security in terms of compromised systems. Spam sensor...
• Analysis of TR/Spy.SpyEye
  SpyEye is a malware family which we are monitoring for some time. Today we are analyzing a sample which is detected as TR/Spy.SpyEye.flh by Avira products. The Trojan is able to inject code in running...
• Are you using the right “System Tool”?
  Recently, we have been seeing a lot of the Winwebsec rogue branded as "System Tool". Winwebsec authors have been using this brand since last year, but lately these have been seen using more aggressiv...
• Fake System Optimizer with special messages
  When analyzing malware, we often look for strings within the malware samples. Those give some interesting insights about the malware, its creators or the targets, for example. While poking into a fake...
• Worm Poses as a Font File, Uses LNK Vulnerability to Propagate
  We recently encountered a malware posing as a legitimate font file. Detected as WORM_OTORUN.ASH, the worm is a .DLL file that uses .FON as extension name. To propagate, it drops copies of itself into ...
• A Technical Analysis on the CVE-2011-0609 Adobe Flash Player Vulnerability
  On March 14, Adobe released a security advisory (APSA11-01) warning of 0-day attacks affecting Adobe Flash Player (versions earlier than and including 10.2.152.33). These attacks were hidden inside Mi...
• Excel File Containing Adobe Zero-Day Exploit Found
  We got hold of an exploit targeting the vulnerability Adobe reported in its most recent security advisory. The exploit, detected as TROJ_ADOBFP.B (now detected as TROJ_ADOBFP.SM), takes advantage of t...