In mid-August I started receiving some emails from Yulia. She wanted me to take a look at her sweet ass:

I was not sure about it, but after receiving some more emails like this I took a look (I received the last one on the 10th of September). Then I found out that this was the beginning of a SmokeLoader campaign, I was really disappointed :( Out of spite, I started analyzing it ;p

After executing the binary you can easily spot that something is happening in your computer because you can see some strange POST requests to some known URLs. These URLs are extracted from the registry, opening the key Software\Microsoft\Windows\CurrentVersion\Uninstall and looking at the values of HelpLink and URLInfoAbout for the installed programs.

Really, first you see a GET request to http://www.msn.com/, then a “random” number of POST requests with encoded data sent to familiar sites for you, the malware communication and, finally, a “random” number of POST requests again. I guess this is just to hide the real communication but sending strange POST requests is not really a good way to hide it...

It is possible that you don't see any request. If this is the case then you have been detected by our friend ;) The binary includes an anti-analysis function and you will end up in an endless loop if you are not able to pass all the checks.

SmokeLoader performs the following checks (some of them are mentioned here):

Checks if the module filename contains “sample”.

Checks if the C: volume serial number is 0xCD1A40 (ThreatExpert) or 0x70144646 (Malwr).

In order to know if it is being running in a 64-bits operating system it checks the segment register GS:

mov ax, gstest ax, axjz short loc_2934D0inc ds:is64Bits

Depending on that it will use a different way to inject in explorer.exe and then to create an additional svchost.exe process. This is well explained in the third step of this AVG blog post talking about ZeuS (one of these techniques uses the functions FindWindow, GetWindowLongA and SetWindowLongA). It seems that this part of the code was copy/pasted too...

After these steps, the malware is initialized, setting up the User-Agent (by default, Mozilla/4.0), sending the GET request to MSN, creating the botid, the mutex, etc. Then is when the fun starts, sending these fake POST requests and finally communicating with the C&C.

The server URLs are hardcoded in the binary, using some basic XOR operations to encode the data. There are at least two blocks with the following format:

[XOR_BYTE_KEY][BYTE2][BYTE3][BYTE3][SIZE][DATA]

One block could be the main URL and the other the backup URL, but in the samples that I have analyzed both blocks contain the same URLs. Every 10 minutes a POST request is sent to the SmokeLoader C&C, looking for new tasks. The request data has this format:

sel: seller id. It is hardcoded in the binary and identifies the user related to the campaign.

ver: OS version.

bits: If the OS is 64-bits or not.

admin: If the malware is running with Admin privileges or not.

hash: Disk binary hash (in the case it is a persistent version).

r: Just garbage data. This is the only parameter included in the fake requests mentioned above.

This data is encrypted with a modified version of RC4, resulting in a block like this:

[SIZE][KEY][ENCRYPTED_DATA]

Then a 404 response is received, but containing interesting data. This data is divided in a first block of digits, terminated with a null byte, and an encrypted block. The block of digits can be easily decoded taking 3-digits groups and converting them to their corresponding bytes (“214”=0xD6). The first resultant byte is the XOR key to be used with the rest.

Depending on the character located in the 4th position (“0” in this case) the loader will perform a different action, asking for additional binaries to be installed, updating itself, removing itself from the system, etc. The second block received in the 404 response contains some plugins encrypted with the same modified RC4 algorithm. There is a 21-byte header and then another 21-byte header per plugin. The plugin header has the following format:

[PLUGIN_SIZE(4)][PLUGIN_TYPE(1)][KEY(16)]

Besides being encrypted, the plugins are also compressed with UPX and all of them are exporting the function "Work". These are the plugins that I have seen so far:

After gathering this information, it is reported to the control panel using this format: “cmd=avinfo&login=%s&info=%s777%s”. The Antivirus and Firewall product names are separated by “777”.

FTPGrab.dll: This module injects code in every process in execution, decoding another plugin called Grabber.dll. This new plugin will hook the functions “send” and “WSASend” to collect users/passwords for the FTP, POP3, SMTP and IMAP protocols. Then it will include this information in the request “cmd=ftpgrab&login=%s&grab=” and adding the following lines:

shell.dll: If the server response includes the “shell_rules” parameter, then the command specified is executed and the result is sent to the panel, encoded with Base64. The request used for this will be “cmd=getshell&login=%s&shell=$RESULT&run=ok”.

These plugins are stored on disk encrypted with the same modified RC4 algorithm, using the botid as key. Besides these, there is another plugin, called Rootkit.dll, used to hook the functions ZwQuerySystemInformation, ZwQueryDirectoryFile and ZwEnumerateValueKey to try to hide the malware process, files and registry keys.