Malware analysis

Asprox / Kuluoz Botnet Analysis

Introduction

Kuluoz, aka Asprox, is a spam botnet that emerged in 2007. It has been known for sending mass of phishing emails used in conjunction with social engineering lures (e.g. booking confirmations, postal-themed spam, etc.)

This article presents a view on the malware and its capabilities, how it communicates with the CnC, encryption schemes used, as well as different protection mechanisms to make the malware analyst job harder.

Another point also to take into consideration that Asprox issues commands that instruct compromised computers to download and execute additional payloads provided by a pay-per-install (PPI) affiliate, from which botnet operators earn revenue.

Tools

• OllyDBG / IDA Pro.
• Kuluoz sample (MD5 = 23DE74A6122A8AB3B02EFD3B2C481978, password = infected)
• unpacked DLL + DLL Loader ( password = infected)

Infection vector

This botnet arrives as attachments to spammed messages disguised as notifications from postal companies as well as airline booking confirmations. Some of the known companies it spoofs are the U.S. Postal Service (USPS), FedEx, DHL, Delta, American Airlines, the IRS, and, PayPal. To lure users into thinking that it is legitimate, Kuluoz often comes in the guise of files like .PDF and .DOC.

If you are interested in learning more about the method of delivery, here are some interesting links that explain it better:

• http://rebsnippets.blogspot.ca/2013/05/phishing-malware-as-service-this-blog.html
• http://www.malware-traffic-analysis.net/2014/11/12/index.html

Packer analysis

All the Asprox binaries that I have analyzed have a Microsoft Word icon, and upon the execution of the Trojan, a message box window appears in the desktop that tells the user that an unknown error has happened. This is used to trick the user into assuming the attachment was an error and nothing malicious has occurred. Besides that, Asprox binaries are packed in what appears to be a custom packer. Unpacking is fairly an easy task, just break point on APIs for memory allocation like WriteProcessMemory or equivalents to see the injected buffer or you can just do it like me, breakpoint on GetProcAddress or LdrGetProcedureAddress to see which APIs are actually used for code injection because most malware that resolves APIs dynamically use this trick.

First thing, I noticed CreateProcessA API with svchost.exe, so that means that Asprox creates a hollowed copy of svchost.exe then injects its code there. If you carry on pressing F9, you will see that this API is being used. This remembers me the duqu injection style that is documented her: http://blog.w4kfu.com/tag/duqu.

What is interesting about this technique is it doesn't use SetThreadContext for updating EIP before resuming thread execution.

After the first call of ZwMapViewOfSection, locate the instruction: MOV BYTE PTR DS:[EDX], AL which writes a byte to memory, and put a BP. The first byte that is copied is a 0x55 (push EBP) which is potentially the entry point of the injected code.

Because OllyDBG could not see the suspended processes (svchost.exe) so you cannot now just attach to it and see the injection occurs. However you could just modify the first byte to a 0xCC and make OllyDBG a JIT debugger (Option->Just in time debugging->Make OllyDBG just in time debugger) and now you can run the malware. A new OllyDBG instance will start and BP on our INT3 BP.

Restore back the first byte to 0x55. Them, look at the dump window (TEXT display) you will see a small stub that actually do the API resolution dynamically (using LoadLibrary / GetProcAddress ) and the other part is a PE file (DLL file), you could see the MZ magic.

After you step through the code that resolves APIs, Kuluoz look at a specific function at the export addressee table of the DLL called 'Work' inside the loaded DLL and call it. Using your preferred PE editor tools, dump the DLL and load it in IDA Pro.

Asprox DLL analysis

It starts with resolving some string manipulation APIs and code injection APIs then it retrieves the account name, SID of the account name and the OS install date, then it calculates the MD5 hash from this variables:

md5( binary_SID + os_install_date + account_name_string), and saves the 8 first bytes of this hash. After that, it creates a new mutex under the name of ('aa' + account name), call GetTickCount which returns for me (0x11F0ABA).

Next, it enumerates all registry keys in HKEY_CURRENT_USER/Software, then for each key, it calls RegEnumValue and makes a certain condition, if the condition matches increments EAX and prints "you fag." In my case, under the registry key "Licenses".

Then, it generates a random value of 8 letters (lowercase) and appends ".exe" to it then appends that to %LOCALAPPDATA% directory to the random string. Following, it creates a new thread, which will display the fake message box: "Windows cannot open the file. The Windows might not support the file type…" This string could also be useful for making the Yara signature for this malware.

Anti-analysis tricks:

Kuluoz check for some process names, Windows names, and some registry keys for VM detection. If any of the analysis environment tools is detected, this information is later reported back to the C&C in the <debug> element.

CnC communication:

Kuluoz is using XML as an exchange format between the victims and the C&C server. Here is what the XML content looks like:

Let's detail each parameter of the XML content:

• id: is the botnet identifier which we have talked about previously.
• group: is apparently an id which identifies a set of bots to separate victims in the same botnet.
• src: reports of any malware analysis tool is found.
• transport: reports if Asprox is running from an USB drive. This may hint at a possible worm version in the future.
• time: is a negative timestamp.
• version: is the version of the botnet, this is a nice parameter which can help on tracking newer version of the bot.
• status: is the status of last command.
• debug: is the environment information such as OS version, 64/32bit, firewall, antivirus.

After it serialize the xml content, it compresses it using Bzip2 compression, then it encrypt the compressed buffer with RC4 algorithm using a 16 bytes random key generated dynamically. The RC4 key is then encrypted using RSA algorithm.

Following the same pattern as described above, the response that is received from the CnC thatcontains an RSA signed hash of the response data to verify if the response is coming from the botnet owner servers or from a sinkholed server. The actual payload which is compressed with bzip2 algorithm and encrypted with the same RC4 key that was sent previously to the CnC.

Examining the response we can see the first 4 bytes of the response body represent the length of the RSA signed hash of the data (little endian) 0x00000080. This is followed by the RSA signed hash. The RSA signed hash is followed by another 4 bytes that represent the length of the RC4 encrypted data 0x00000069. These 4 bytes are then followed by the RC4 encrypted data.

Conclusion:

While spam botnets are well known for sending out unwanted ads, especially for "rogue" pharmaceutical companies, they are also an integral component of malware distribution. The Asprox botnet not only sends out spam but also malware-riddled spam that allows it to grow and use compromised computers to perform tasks that keep it operational. In addition, its operators monetize their operation by instructing compromised computers to download additional malware provided by PPI partners, including FAKEAV malware.

Although the Asprox botnet was scrutinized by the security community in its first three years of operation, it has largely flown under the radar because its spamming component has been incorporated as a "second-stage" plug-in. In addition, Asprox continued its use of scanning for and exploiting vulnerabilities to increase its presence and even incorporated password-stealing functionality so it can compromise legitimate email accounts for use in sending out spam.

Asprox's continued operation proves that spam botnets remain a crucial component of the malware ecosystem and cybercriminals are always looking for new ways to adopt in response to defenses.