Analysis of Drixed samples

From an incident response standpoint Drixed is a pretty standard case. The threat actor sends a weaponized Word document to your end user. The document functions as a dropper, this means it downloads an executable and this executable is a Trojan horse. If you want to reduce the odds of getting infected it is thus of utmost importance to train your users to report you the messages for analysis.

Koen Van Impe pointed out to me that the naming is actually confusing. My samples were Trojan droppers and named Drixed where there is also a banking Trojan called Dridex.

The documents I analyzed contained 2 modules with VBA code and one method that is triggered by the autoopen functionality. The code itself was obfuscated and depending on the document the obfuscation was different.

The autoopen is the instruction what the word document should do when opened automatically. What it basically did was to create an Microsoft.XMLHTTP object to fetch the file as binary data and then write it as an executable to disk in the TEMP folder. The Microsoft.XMLHTTP object was created to allow interaction with web servers (sending XML over HTTP) and thus also the download of a file.

The methodologies I observed for the retrieval were different, some were actually done in the VBA others were done by writing some vbs-script and then executing the script.

The tool I would recommend to extract is oledump.py by Didier Stevens. This helps you extract the VBA code without actually opening the document in a Word and thus accidentally starting the malware. Oledump.py requires the installation of the python olefile library to do its magic.

$ python oledump.py file.doc

Is your starting point but all the info you need can be found on Didier Stevens' website. Basically you select your stream and dump the stream out (don't forget -v for decompression). The data I was interested in was in stream 7 (the macro module) so it looked like

$ python oledump.py -s 7 -v file.doc

From a IR standpoint it was interesting to see that the download was using the IP addresses. The IP addresses were hacked websites. The fact that the threat actor can use the IP means that the whole sever is under his/her control. When you run the IP through Virustotal's database after +48 hours we see already another malware sample (it has a different hash) that was submitted using the same IP address. This tells you that the threat actor still has control of the server.

Another thing that was interesting is to see how they actually "hide". They downloaded in each case I saw an image from that IP address. Closer inspection actually revealed that the image extension was actually just a renamed Windows executable. The executable is your Trojan horse.

To get your sample the only thing you thus need to do is decipher the obfuscation (was not really hard in the cases I saw) and then go and get the image and rename it to exe. Then the next phase can start: tickle the malware for more info about its master ;).

Analysis of the Trojan Horse is not for this post, I just wanted to keep it on how you can get the samples being send to your organization. I ask you to share your samples or analysis/IOCs with your trusted people within other CERTs so that we don't reanalyze the same sample over and over again.

Maybe one last important thing to explain when discussing incidents like this. Although Drixed might be known by your AV-vendor, the Trojan might not be and since both can evolve (or change their obfuscation) you really got to be born under a lucky star to have a 100% match and totally protected at the time that first e-mail comes in.