Malicious Document delivering Dridex — analysis and emulation (part 2)
One of the check list items from part 1 has continued to give me trouble. As a result, I haven’t been able to produce a fully automated builder. You can, however, build a realistic Dridex-style maldoc in just a few minutes with what has been added to the Adaptive Doc Builder.
First, what I can’t get to work — adding a Text Box control to a VBA form using the Python win32com.client. If I can figure out how to create the Text Box, rename it, and set it to Multiline, then the whole document build process can be automated. Until then, we’re stuck with some manual steps .
VBA Building Blocks
When writing a builder, I create building block functions to keep the final VBA code creation easy to follow. I generally stick to two main function type: “generate_*” and “get_*” functions.
Generate functions are used for random generation of something. A random variable name is a prime example. The generate function is not safe from collisions though, and it’s not intended to be.
Get functions can also generate random values, but generally only if there’s no need to have the random values being generated accessible to other functions, or by themselves when building VBA . The main difference with Get functions is that they add to the necessary lists / sets used to keep track of variables so that there won’t be any collisions. This lets you use get functions freely when building VBA without worrying about generating invalid VBA on occasion when a random variable name collision would occur.
Get functions are frequently nested to create common code patterns, especially when generating VBA filler that isn’t used to deliver or execute a payload.
This separation of Get and Generate functions has saved me a lot of rework when an adversary group changes a small thing about their builder — like their variable name format.
Example: get_filler(min, max)
get_filler emulates what we see in the Dridex VBA:
- A variable definition, a new line, then the variable being set to an appropriately typed value
- Most of the time, a comment containing 0–5 English words, with the first letter of the first word capitalized
- An occasional newline
The (min, max) is to let the VBA vary a little bit from build-to-build. VBA built like this is generally not a skeleton template with variables filled-in at build time. Each build will vary — and a common way they vary is in the volume of filler code.
When there are 4 sets of filler text in the real Dridex document, I introduce a little variety — generally +/- 1 for a number < 7, +/- 2 for a number between 7 and 14, and so on.
For example, there were four sets of filler a few times in a row in Module 4. I set both to generate between 3 and 5 filler blocks.
Compare and Contrast
How does this code look compared to the real malicious file? At this stage, I generated three code blocks and compared them to the real Dridex code module I am emulating:
If you can glance at the lineup and tell which one is the original source material vs. the generated VBA, it’s time to rework some of the generation functions.
Another crucial step is to drop the VBA, one module at a time, into the VBA IDE. It’s not difficult to miss a quote or newline while building VBA like this, and the IDE will highlight your misstep.
A quick glance at the original Dridex maldoc
Here’s a quick tour of the Dridex maldoc, since we’re going to be building by hand after the VBA and XSL payload are generated for us.
Take note of the VB module layout:
Payload storage in the Text Box control, in the VBA Form:
Time to build!
At the time of publication, you will need to check out this branch (dridex_20190709) to follow along with the video tutorial:
Adaptive Document Builder A framework for generating simulated malicious office documents.
And here’s a video tutorial showing how to take the VBA and insert it into a document. Steps are also shown to encrypt the document with password “123”, which is typically sent in the body of the email to the target so that they know how to open the file.