Malware Headliners: Dridex

Updated: Jan 16

For this blog post, we're taking a dive into the initial stages of a prevalent banking trojan known as Dridex. Developed by Maksim Yakubets and leveraged by advanced e-crime threat groups such as TA505 and Indrik Spider, this malware is commonly delivered in a Microsoft Office document as part of phishing campaigns.

The sample we're analyzing was downloaded from MalwareBazaar and submitted recently. Although the file being analyzed is a Microsoft Excel file, the analysis will take place in REMnux. All the tools I use will have their documentation/websites referenced at the bottom of the post.

DISCLAIMER: Some of the IOCs identified in this sample are vulgar. This is a real malware sample identified in "the wild" and as such offers a good representation of what analysts may come across in their day-to-day. I've added this disclaimer to mention, for those that may not understand, that the vulgar terminology did not originate from my work and is the work of the malware developer.


A quick analysis with TrID, developed by Marco Pontello, shows us that the file is likely in extensible markup language (XML) format.

USING ZIPDUMP AND XMLDUMP is one of the many tools developed by Didier Stevens. It is useful in this instance because files in XML format are technically zip files. Running the command displayed in the screenshot below lists the underlying streams.

To get started, I chose stream 4 since it's listed as the workbook. Piping the output to (also developed by Didier Stevens) with the 'pretty' parameter gives us a more readable result.

In the result we see 2 references under the "sheets" tag: one to Macro1, and another to Sheet1. We also see that for each of the entries there's an "r:id." Looking up these ID numbers in the rels stream will tell us what these sheets are pointing to.

First we'll take a look at "rId1," which is associated with Macro1. This points to the stream "macrosheets/sheet1.xml.' "rId2," associated with Sheet1, points to "worksheets/sheet1.xml." Going back to the original output, we see that "macrosheets/sheet1.xml" is stream 13, so we select it for review and pipe it to xmldump for a cleaner output.

A more condensed output can be achieved in this circumstance by using "celltext" instead of "pretty" for the xmldump parameter:

On the left of the output you can see the cell in the sheet where the text to its right is found. We can kind of figure out what some of the data here is, but we can use xlmdeobfuscator (developed by Malwrologist) to get a clearer glimpse.


The tool will ask for an entry point that includes the sheet name and the cell to start on. I passed it the name of the sheet (Macro1) followed by the first cell listed as having data in the zipdump output we saw above (F14) .

We now have some initial IOCs to make a note of, particularly the following file path:



If we look at the entry for cell F39, we see that it references Sheet1. If you recall, Sheet1 is the other sheet listed in the workbook stream and we know has some relevance to function of the file so far. If we run the following command grabbing the celltext from the stream where xl/worksheets/sheet1 resides, we get a ton of entries that look like this:

Here we see the cell column and row, a set of quotes, and a number. My inference is that each cell contains a character, and this is charcode. Using sed and tr, we clean up the char code to get just the numbers and remove the new line characters:

Copying everything except the "Reference, Formula, Value" at the beginning of the text, and putting it into a tool that can convert this from charcode to ASCII (CyberChef works great, there are other resources online), we get the following:

This now looks a lot more like a VBA script. There's still some residual characters that need swapped over to ASCII, and a lot of the ampersands and quotes can be removed to make this more human readable. The objective in my analysis is not to arrive at code that can still run, but rather code that I can easily read and therefore deduce what functionality it has. Snapshots from some of that cleanup are below:

Ampersands and quotes removed:

The last thing I did was start converting the "gibberish" seeming variable and function names to something that made sense. For example, I renamed the variable "EMHPXpkoyrz" to "UserDomainString" because that's the data it contains. Aside from variable declarations and function definitions, the code below is the actual "meat and potatoes" functionality of this script.

In layman's terms, the code checks and sees if the ".bin" file exists. If it does not, then for each URL in the array at line 50, it will initiate a GET request for the ".bin" files identified in the URLs. The InternetFunction(MSXMLServerCreation) value of 1 comes from the function starting at line 33. If the GET request responds with a status code 200, meaning "OK," then it will save the ".bin" file as identified in line 39. Jumping back down to line 55, with a value of 1, the code will then execute several Wmic Process Calls for regsvr32 and rundll32 to execute the ".bin" file downloaded and therefore execute the next stage of the malware.


File type: OOXML

File hash: 77ea99933030294970a8d11a20f0fab4e540133931e91358d2dde3b97d6a521d

Files it writes/renames downloaded files:


Files it downloads:




Domain file downloads from:







Indrik Spider (ThaiCERT)


Big Game Hunting: The Evolution of INDRIK SPIDER From Dridex Wire Fraud to BitPaymer Targeted Ransomware (CrowdStrike)

Dridex - 2021 Threat Detection Report - Red Canary (Red Canary)

Recent Posts

See All