Background - Dridex Malware

The Members

Check Point (2020) wrote that their "Global Threat Index for March 2020 shows the well-known banking trojan Dridex, which first appeared in 2011, has entered the top ten malware list for the first time, as the third most prevalent malware in March."
Similar to ZBot and its many variants, Dridex has historically been a banking trojan. CrowdStrike associates Dridex primarily with Evil Corp, led by Maksim Yakubets (Максим Якубец), who is known for showing off his lavish lifestyle on social media (i.e. Instagram).

As a 90's kid myself, I noticed that he bears a striking resemblance to the late and great Jimmy Neutron.
Here is picture that more people are familiar with depicting another member of Evil Corp, Andrey Plotniskiy holding a stack of cash earned from ransomware campaigns.

The members are known for driving different expensive luxury vehicles like Lamborghinis, Audi R8s, Skyline GT-Rs, and Mercedes G-Wagons. Additionally, they are known to use custom vanity plates with the characters вор. In Russian, вор translates to thief.

The above images are courtesy of Curtis from riskint.blog .
In my ZBot analysis, I mentioned Evgeniy Bogachev, the author of the Zeus banking trojan. As it turns out, he is close friends with Maksim's crew. Russians of a feather tend to flock together.

Since at least 2017, Yakubets has been actively working in coordination with the Russian FSB and as of 2018, he was in the process of "obtaining a license [security clearance] to work with Russian classified information from the FSB." (source: treasury.gov)

Technical Details

Unsurprisingly, Dridex is known to be delivered via phishing email containing a fake invoice with an attached .xlsm downloader which launches a macro that uses URLDownloadToFileA to download the stage 2 (primary) payload.
From there, the infection kicks off and the specimen initiates C2 and data exfil.
Interestingly, the primary payload is known to use a technique where it registers a VEH handler which gets called when the CPU raises an exception in response to int3 (noop or no operation) instructions. This VEH handler gets registered via AddVectoredExceptionHandler.
int3 is not expressly used to trigger an exception, but rather, the author(s) are known to intentionally use _debugbreak() (a built-in command) that works exactly the same as using an int3 instruction.
Authors Oleg Boyarchuk, Jason Zhang, and Giovanni Vigna did a fantastic write-up on this where they explained that you can make the debugging process much easier by changing exception settings to not pause on int3 instructions.
Dridex v4 emerged in February 2017 and it used a new technique for code injection ("AtomBombing") according to HHS: '

Hands-On With a Dridex Dropper

We can immediately see some suspicious Powershell. Let's also check out streams 10 & 11.

The embedded Powershell from stream 9 references UserForm1 and ControlTipText. From what we can see here, it kind of looks like it's referencing UserForm in the context of CheckBox1.
The term ControlTipText is a property that can be used in UserForms (custom dialogue boxes) and ActiveX controls to display a tooltip when a user hovers over something.

It appears right here under stream 7 and it looks like a big base64 encoded blob. Let's decode it with CyberChef.
First, we'll have to extract it with base64dump.py.

Just like I thought. Look at the "Decoded" column - there is some Powershell in there. Next, we can use base64dump.py to extract that specific string and analyze it further.

The null terminators after every character probably indicates UTF-16 formatting. Unfortunately, this happens a lot when extracting Powershell scripts from specimens. However, it can easily be cleaned up.

The base64-decoded Powershell script has its own base64 encoded blob which is also gzip compressed. The script decodes, decompresses it, and then executes it.
So, naturally, the next step will be to decode and decompress this next base64 blob.
Here's what it looks like after base64 decoding:

The script above is a typical example of how Powershell can be used to execute malicious payloads. It uses in-memory execution, obfuscation, and process compatibility handling.
It starts by setting strict mode to version 2, which enforces certain rules and restrictions on how the script should be run. In strict mode, any attempt to use a variable that has not been initialized will throw an error. The same will happen when attempting to access properties, non-existent members, etc.
The base64 payload assigned to $var_code in the middle is likely shellcode. It gets base64-decoded on line 24 and then XOR decrypted with the key 0x35 on lines 26-27.
On line 30, the script resolves the address of kernel32.dll -> VirtualAlloc and then injects and then the script injects and executes the shellcode on lines 34-35.
So, we next need to base64 decode the shellcode and then XOR decrypt it just like the Powershell script would.
The decoded & decrypted shellcode, as expected, is not in human-readable format.

Floss returns 19 static strings, 1 stack string, and 1 decoded string.
It managed to pull out an HTTP user-agent and an IP address. That's a great start.

Doesn't look like a very friendly IP address. It's been spotted in relation to CobaltStrike and some other bad activity.

The next thing we can do is emulate the shellcode with a tool like scdbgc to assess its capabilities.
Here's a good find - we see an HTTPS request via InternetConnectA to 172.98.192[.]91 with a pre-specified user-agent.

This sample is a malicious word doc that contains embedded VBA macros that use Powershell to execute shellcode on the system.
The shellcode appears to contain basic dropper functionality, presumably downloading one or more payloads.