MMD-0041-2015 - Reversing PE Mail-Grabber Spambot & its C99 WebShell Gate

I don't know about the origin of the infection, but when I talked with Mr. Christopher Lowson while examining the CNC of the threat, I guessed a PC was infected with this malware and the callback is why me and Mr. Lawson talked. Beforehand, thank's to the Emerging Threat to allow me to write this up, I will start this report from the malware analysis to its CNC gates, in as secure manner as possible.

The unknown SFX RAR .Net PE malware (sounds lame enough?)

The sample is a PE (6222e15ed2c71429c472e5f0fa40d727) and it was reported a week ago (2015-08-27 15:10:48 UTC). A grep info in pescanner will show you:

File:    ./Release.exe
Size: 263514 bytes
Type: PE32 executable (GUI) Intel 80386, for MS Windows
MD5: 6222e15ed2c71429c472e5f0fa40d727
SHA1: a9316503ad6dd9e10fa8506fe69cc5aa7cc4eafe
Date: 0x54E0521F [Sun Feb 15 08:00:31 2015 UTC]
EP: 0x41d7cb .text 0/4
CRC: Claimed: 0x0, Actual: 0x4a8a2 [SUSPICIOUS]

The CRC differences is showing packed/archives or both, I tend to check further the insides for sure with my beloved UNIX shell reversing tool, the almighty radare:

..this is showing overlay of SFX Rar file. A test (t command) in unrar shows the contents safely:

Testing     MAPIEx.dll                            OK
Testing NetMAPI.dll OK
Testing aa.exe OK
Oh, it seems there are two run time dll to run the aa.exe, Let's check again what is the aa.exe:
MD5 (aa.exe) = fa056e635791f18b21898bc0ff6a9978
aa.exe: PE32 (GUI) Intel 80386 Mono/".Net assembly", for MS Windows

The above result is a self explanatory. The point is: Always do static analysis beforehand, it is very important to recognize which binary we are dealing and how is the best way to deal with before we start firing some disassemblers to check its bits or opcodes.

Okay, since now we know how it's developed, let's decompile it in the same way it was built. You'll find these loaded resources:

OutlookContactsViewer.Form1.resources (Embedded, Public)
OutlookContactsViewer.Properties.Resources.resources (Embedded, Public)

The above resources is having the code to execute the malware, so the rest of this reversing is just depending on our skill to read that code.. I will cover the important parts only to PoC the badness of this binary and won't share the full code for the security purpose, as follows..

Peeling the malcode :-)

This is how the malcode was started... by initiation some variables and starting the main function to call to its loading-form:

And the loaded form has the main code of main functions for overall malcode operation:

As you can see it has two commands of "extract" and "spread". Between the "===" delimeter string, the data/text will be filled by email addresses grabbed from functions: GetMailsFromContacts(), GetMailsFromHeaders() and GetMailsFromMessages().

Functions called due to the "extract" command is the text formulation of the strings following by the POST command to send data to the web gates with URL defined in the initialization variable part.

Now we know the purpose of the runtime file is; NetMAPI library was used to perform email-grabbing act i.e. as per snipped below code in GetMailsFromContacts()

..and it is added with the regex to grep the email addresses in GetMailsFromHeaders() and GetMailsFromMessages() parts:

The same library also being used to spread spam via "spread" command (below), is a PoC that we also have a kind of spambot too here. Noted that the subject, body message and the attachment variables hard coded in the initiation part was stored here:

I snip some significant codes (only) that's utilizing HTTP protocol for uploading grabbed emails to the gate as per below, to understand and to figure ways to mitigate the threat further:

To be noted this malware reads the multipart encoded part of an email too:

A sample traffic captured for the uploads is here:

So we have the good idea what the malware is doing, yes? It sends spam, it grabs email address and uploaded them to the remote gate.

The gate

The gate is a hacked sites, I spotted the c99shell by the first time I see it. I spent much time studying c99shell before, the link is here-->[link]. This one looks injected to the compromised web site via PHP vulnerability that allows remote file uploading.

It is the latest standard version noticing this command list:

This is the up.php gate's code:

So this is how the up.php works in receiving the request, using GeoIP (by Maxmind) API to check the location of POSTed IP, making directory of that country code (if not exist) and writing files with the list of grabbed emails in it (if succeeded), it explains many directories with country code names. It also make logs of access and has the ban access function too, the details for that is written in the included func.php.. Please noted the "Nothing to do.." decoy.

It's not being used but below is snipped for the logging and banning codes, I "secured" it a bit:-)

This is what files were injected and created in that panel, if you see the same files in your servers please delete or secure them all + fix the PHP flaw that caused the file upload.

The email data of the victims that has been grabbed was plenty.. thanks to Mr. Lowson to clean this threat's gate to stop this badness. Below is the snip per 4 lines each data in the CO (randomly picked) directory..

Unknown threat with zero detection

I don't think we had any PE detection signature for this malware (in VT check): [Release.exe] [aa.exe]

A saying in my country says: "What we don't know, even small mater, may hurt us badly" ..I guess this is the case. Don't say about VirusTotal result can not represent detection in this case since several AV products installed in PC was letting infection happened without having detection either.

See this case well, even a simple .NET malware using a straight new DLL abuse vector calls for malicious purpose, if it is unknown, it's just lethal enough to damage us. So firstly please rely more on our own security common sense than just letting automation made by industries 100% control the way we must think and act, WHAT IF things went wrong? The risk is always be in our hands as users/victims < the moral of this story.

Just another saying: "One who admit the FAILURE has the chance to IMPROVE. One who just making EXCUSES will NEVER improve.."