Malicious Document delivering Dridex — analysis and emulation (part 1)

Notes about this campaign as it was seen on 2019–07–09 from http://malware-traffic-analysis.net/2019/07/09/index.html:

1. Delivered as email attachments
2. Documents are .docm (Word 2007+) format
3. Documents are encrypted and password protected (generally the password is 123). Password is provided in email.

The VBA performs two actions with only a few lines of code, with substantial filler code and comments. The first action is to read the .xlt file from an OLE Form’s text property and write it to a file. The second action is to create a wmic process to read and run the .xlt file.

The retrieval and writing of the .xlt file is done with a little jumping around, but the process is fairly straightforward. Note in the screenshot below that the .xlt file is in OLE storage without any obfuscation, as is the .xlt file path in the VBA. With the document encrypted, it’s less likely that security products will have access to this information when analyzing the file, decreasing the incentive to obfuscate.

Retrieving the .xlt payload from OLE Form text and writing it to disk:

Payload execution is a Shell call with this argument:

wmic os get /format:"C:\Windows\Temp\aXwZvnt48.xsl"

Again, not much effort to obfuscate what’s going on here. Typically, using Shell with variable concatenation on the same line will increase the likelihood that the VBA will be flagged as malicious. This is another example of the benefits of encrypting the document.

Reassembly of command to execute xsl payload

Now that we know what the VBA is actually doing, let’s now look at the filler. If we were satisfied with reversing the VBA behavior, this would not be necessary. To emulate this, we want to understand how the filler is being generated and if there are any patterns to it we should adhere to.

First thing, the variable names appear to be randomly generated. Here’s a sample:

First 20 variable names

The first character of each variable is the letter ‘a’, which is an easy way to avoid your random variable ending up with an invalid number at the first character spot, resulting in broken VBA. Characters at index 1+ are a-z, A-Z, 0–9.

Here’s a distribution of variable sizes. It appears they are using between 5 and 9 character variables with a relatively even distribution:

Variable name lengths

Looking at the pattern of filler variables:

Variable names and types, along with their assignment

Types of variables being created:

Variable type distribution

Next we’ll print out the values the unused variables are being set to sequentially. This will give us an idea as to how the builder is determining the values.

Checking the Integers being set. They are out-of-order, and range from -30,410 to 30,942:

Integer values being set

Checking the Longs being set. They are out-of-order, and range from -31,202 to 30,840:

Long values being set

Checking the setting of Booleans. They alternate in a way indicating a random function is determining what to set:

Boolean values being set

Comments are also being littered throughout the VBA. There are 89 comments, generated from an English word list. They start with a single capital letter, and contain 1–5 words, space delimited:

Comments

There are a few remaining details to take note of before we are ready to emulate this VBA. One detail is the overall code flow and distribution of the random elements.

From the information we’ve collected above, we can write a regex to highlight the filler code and comments.

Dim \S+ as (Boolean|Long|Integer|String)|^’ .*|^a[a-zA-Z0–9]{4,8} = \S+$

Document map showing filler code

VSCode will let us use this regex and using the document map, we can roughly see where the real code is sprinkled throughout the document. The yellow highlight is the filler code.

The left-most column is all filler highlighted. The middle column shows variables and assignment. The right column shows comments.

Once the filler is highlighted we can easily jump around and look at the meaningful code.

Legitimate code between the filler

More notes for emulation:

1. Comments appear after roughly 80% of the filler variable create/set statements
2. Functions are spread across four VBA modules: ThisDocument + 3 with the random variable name format starting with an ‘a’.
3. The embedded ‘image1.png’ is the splash screen used to lure victims into clicking “Enable Content”

Splash page embedded in the document

Now we have the information we need to craft an emulated Dridex maldoc.

Here’s the list of objectives when creating the builder:

1. Create document template file with the splash page from real Dridex (screenshot of the Splash page to avoid weak detection on the original image hash)
2. Password protected document (password: 123)
3. Saved in .docm (Word 2007+) format
4. Create function to generate a random variable names starting with ‘a’ and containing 4–8 additional randomly selected [0–9a-zA-Z]
5. Create function to select an Integer between -32,000 and 32,000
6. Create a function to select True or False randomly
7. Create a function to create a comment with 1–5 English words, with the first character being capitalized
8. Create a template of the .xlt XML file to randomize the variable names and update the payload download domain
9. Create three VBA modules and one VBA form. Correctly place VBA code into the modules, and the .xlt payload into the form text

Some of this functionality is present in the Adaptive Document Builder ( https://github.com/haroldogden/adb), and some will need to be added to build this type of document.

In part 2, I will detail the additions to ADB and show the comparable output document built using the analysis performed here.

Part 2 >> https://medium.com/@haroldogden/malicious-document-delivering-dridex-analysis-and-emulation-part-2-eb33fb6e3582