Sunday, August 30, 2015

Dridex Downloader

Recently we have been hearing of the rise of VB macro based downloaders and other kind of malware as the first stage of the multi stage attack. FireEye in the blog post mentioned use of macro based documents as IIV (Initial Infection Vector) for banking trojans like Dridex.

I came across one such doc file:

The screenshots are mostly self-explanatory:

This time the malicious document file is of extension .doc and not .docm (the compressed newer version of Word files with embedded macros).  Instead of using docm, doc extension is used most probably to get through file filters on email security gateway, whereby macro extensions might be blocked. 

The file does not contain any text and a lot of unused code is found in the VBA macro, which is both irrelevant and most probably placed in there for the purpose of anti-analysis. The actual malicious code which is used as a downloader is obfuscated.

Similar techniques are deployed and Object used to download in temp folder and run the malicious binary.


Microsoft.XMLHTTP object is used to send a GET request to the malicious website for downloading the second stage binary.

This the de-obfuscated GET request and we can see the URL to the second stage binary.

The second stage binary is copied to the temp folder named as ruebfo.exe

The second stage binary was downloaded and its MD5 hash is found to be: e476dc4261c3848a06cc2cc62195dd55

Scanning the file with McAfee didn’t yield any detections, but Malwarebytes was able to detect the binary as Backdoor.Bot

The binary seemed to be packed

Running the file through VirusTotal showed that it is identified as a Trojan, Backdoor, ESET and Malwarebytes identifies the binary as Dridex the banking trojan. We know from Trend Micro report that Dridex is using Macros for infection: Reference: From VirusTotal output we can see that many AV vendors do not identify the binary as malicious. Most probably because it could be a variant of the known Trojan Dridex.
Strangely McAfee also detects the file as a generic packed but when we scanned the binary by Mcafee AV it was not able to detect anything.

 The file is shown as not packed by Exeinfo. However we are not able to find any useful strings when we try to extract strings out of the file.

 A dynamic behavior analysis of the binary shows some interesting strings and behavior. The process hacker utility can be used to extract strings from the running binary (from memory) and some interesting strings can be seen below.

We can see the IP address and port of the C2 Server which is used to establish a TCP conn. We can also see the HTTP POST request method, which could be used for range of things ranging from providing the result of C2 commands to the C2 server, to data exfiltration. We could also see the cryptnet.dll, indicating that main part of the code could be encrypted.

The C2 server is, which seems to be a gaming website. WHOIS shows that the site is hosted in Ukriane.

Running the exe and analyzing the traffic we can see attempting TCP handshakes with C2 server on the port 8448, which we can also see in the decrypted strings in the memory.

Thursday, August 20, 2015

Macros based Downloaders on the Rise

Recently I have come across email with infected macro attachments, bypassing security mechanisms in place by obfuscating the vb code. One such example was a downloader which was discovered .

The macro is triggered the autoopen() function which in turns seems to call a randomly generated function xbxGk5Ux3irM4d. Such function names are indicative of a code generator which generates the code automatically.

Secondly some anti analysis techniques were observed again with obfuscated function calls.

After the function call, some other anti analysis techniques were observed where the characters were obfuscated using ASCII values. As it can be seen that further obfuscation is done by putting in between backslashes in the URL, which is removed by subsequent Replace function.

The downloader seem to be downloading a binary bbw.exe
(Hash:  da8a659d8ac0a75e0c6936b31331796b) Virustotal did not give any result

Microsoft.XMLHTTP is being used by the dropper and Wscript.Shell() is used to execute the malicious binary:

The binary is copied to the the Appdata/Tmp folder with another name "mikapolne.exe":

In the next blog post I will be sharing the analysis of the second stage of the attack by analyzing the downloaded binary.