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

These are some of the headers and the message body:
 

Date:   Wed, 13 Aug 2014 12:55:56 -0400
From:   "Yulia" <negligentjsd185@dialectologic.in>
Subject: My new  photo

Hi it is Yulia fuck me ass at night. Look at my sweet ass on a photo I wait for you

 
I don't want to duplicate the information already published about this loader, so you can check the post published in July by StopMalvertising and what my colleague Michael Sandee said about it in 2012. Since then, SmokeLoader (known as Dofoil too) has modified the encryption to communicate with the C&C, added some extra plugins, etc.

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).
• Checks if the modules “sbiedll” (Sandboxie) and “dbghelp” are loaded.
• Checks the disk enum key (System\CurrentControlSet\Services\Disk\Enum) looking for:
  • qemu
  • virtual
  • vmware
  • xen
• Checks if AutoItv3, CCleaner and WIC are installed looking in the registry (Software\Microsoft\Windows\CurrentVersion\Uninstall). It seems that this is a fingerprint for Joe Sandbox.

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

mov     ax, gs
test    ax, ax
jz      short loc_2934D0
inc     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:
 

cmd=getload&login=$BOTID&sel=jopa1&ver=5.1&bits=0&admin=1&hash=&r=$GARBAGE

• cmd: Command sent to the panel.
• login: botid with format %08X%08X%08X%08X%08X.
• 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.
  

 
After decoding the response we obtain something like this:
 

Smk0|:|socks_rules=127.0.0.1|:||:|hosts_rules=127.0.0.1 localhost|:||:|plugin_size=60500

 
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:
 

• AVInfo.dll: It is a Delphi plugin which uses the Windows Management Instrumentation (WMI) to obtain the installed Antivirus and Firewall products. If the Antivirus product is not detected that way, it checks the running processes to find Antivirus processes:
  • avp.exe  (Kaspersky)
  • ccsvchst.exe  (Norton)
  • dwservice.exe  (DrWeb)
  • dwengine.exe  (DrWeb)
  • avgnt.exe  (Avira)
  • avguard.exe  (Avira)
  • malwaredefender.exe (Malware Defender)

• 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:
  • pop3://%s:%s@%s:%d
  • ftp://%s:%s@%s:%d
  • imap://%s:%s@%s:%d
  • smtp://%s:%s@%s:%d

• 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.
  

 
These are some of the samples used to write this blog post:  
 

4fe5f69ca1ab813e829479004f262ccd
db3745ec149818567de5d2dfc3477d25
a4b7e8bf966ee5c6e2c731e9047968d4
e1ee0990ffd0da3df13c1206a6bb9a4b
86ca12376ab5e27534029d23b2952a28

 
The C&C URLs related to these binaries are:  
 

hxxp://joppwer.in/
hxxp://offnamerty.ru/
hxxp://jtp888888.ru/