MMD-0041-2015 - Reversing PE Mail-Grabber Spambot & its C99 WebShell Gate03 Sep 2015 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:
Size: 263514 bytes
Type: PE32 executable (GUI) Intel 80386, for MS Windows
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 OKOh, it seems there are two run time dll to run the aa.exe, Let's check again what is the aa.exe:
Testing NetMAPI.dll OK
Testing aa.exe OK
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().
The same library also being used to spread spam via "spread" command (below), yes..it 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:
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 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.
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.
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
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.."