Recently, my MMPC research colleague Michael Johnson blogged about an interesting social engineering technique that results in a malicious JavaScript being run on the unsuspecting recipient's computer when they follow the instructions provided in a .PNG image file. Unsurprisingly, we recently found that malware authors are using this PNG-to-BMP conversion process as a means of obfuscating their malicious code, without any user interaction.

Trojan:Win32/Sirefef.M belongs to a family of malware that is highly obfuscated, using multiple layers of encryption and a number of anti-debugging and anti-emulation techniques to avoid detection. If we step through a particular sample we found recently, downloaded by Win32/Oficla, we find a .PNG file underneath one layer of its encryption, as shown below:

If we view the .PNG in an image-viewer, we can see the image displays nothing of value, as seen in the screenshot below:

Win32/Sirefef.M proceeds to convert this image into a bitmap, which decompresses the image, producing more executable code for the trojan to execute, which is partially shown below stored by the trojan in a buffer:

 

Further analysis of this code reveals additional layers of encryption, before the malware's true payload is finally reached.

What is the malware's payload, you may ask? Previous variants of this family include functionality such as re-directing the user's Internet search results and generating pop-up ads. But this variant differs, revealing another interesting aspect of this particular piece of malware.

As part of its payload, Win32/Sirefef.M downloads a portable executable (PE) file from a specific IP address through port 8082. The PE, however, is simply a resource-only DLL, detected as Rogue:Win32/Sirefef, containing resources such as image files, JavaScripts and HTML files. If we look at one of the resources, we can see exactly what we are dealing with here:

Using all of these resources, Win32/Sirefef.M reveals its true colors, displaying the following fake scanning interface and exhibiting typical rogue behavior, calling itself "Antivirus 2010 Security Centre":

This method demonstrates a not-too-common approach by the rogue authors, where instead of packing all of the rogue's functionality and interfaces into the one executable, they store them in a remote location. They do this in a resource file, which can be easily updated with new interfaces, logos, buttons, scripts, etc; this can allow them to change the look of the rogue without having to make many code modifications to the downloader that loads it.

Thank you to Scott Molenkamp and Michael Johnson for their help in the analysis of this threat.

- Amir Fouda

MMPC Melbourne

Note: files analyzed include:
Sirefef.M, SHA1: 31827147766a65b9415345c71303274e256a2272
Rogue:Win32/Sirefef, SHA1: 67d85964352c45a649563fa139e8915537f58d78