Dridex Code Breaking – Modify the Malware to Bypass the VM Bypass

Post Updated on March 25

The arrival of spring brings many good things, but it’s also prime season for tax-themed phishing emails. A partner of ours recently reported an email with the subject “Your Tax rebate” that contained an attachment with Dridex and password-protected macros to hinder analysis. If you read this blog, this story should sound familiar, but this particular strain took new precautions, such as adding a longer password and using VM detection inside of the code.

Here’s the screenshot of the phishing email:

Figure 1 - tax rebate

Figure 1 — Tax rebate-themed email

Once opened, the malware attempts to run macros. This is nothing new for Dridex, and we’re presented with the normal option to enable macros.

As with the previous Dridex sample, I hit alt + F11 to bring up the macro for investigation, and the attackers have password protected their macros.

By using the same technique from the previous Dridex blog, I generated an empty excel document in order to spoof the password with something that I knew. I had to change the length several times, but the password that finally worked was a 19-character password.

After modifying the characters and re-opening the excel file, hitting alt + F11 brings up the following macro page, now letting us see what’s inside. (Figure 2.)

Figure 2 -- beginning of macro code

Figure 2 — Beginning of macro code

By expanding the modules and classes (Figure 3), we can see that there are many other modules and classes included. The attackers put forth extra effort in order to obfuscate their code.

Figure 3 -- List of classes

Figure 3 — List of classes and modules

By looking at “load” under modules, we can see some interesting subroutines, one of which mentions debugging techniques (Figure 4) and possible sandbox evasion tactics.

Figure 4 -- Possible anti-debugging

Figure 4 — Possible anti-debugging

By poking around in the other modules, we can see that module “dfsdf” contains the code for IsVirtualPCPresent(), which is referenced in “load.” As macro code goes, the collective total of VM detection / sandbox evasion techniques (Figure 5) is rather impressive for this sample.

Figure 5 -- VMware

Figure 5 — Anti-VM detection inside of the macro

Conducting OSINT revealed  that this code has been around since at least 2008,and  seems to have originated on a Spanish hacker forum.

The attackers are even looking for Sandboxie (Figure 6) and Anubis sandbox (Figure 7).

Figure 6 -- Check for Snadboxie

Figure 6 — Check for Sandboxie

Figure 7 -- Check for Anibus

Figure 7 — Check for Anubis sandbox


Now that we know where the code lies (Figure 8), we need to look at how to get there to see the next stage of the attack. There is one problem: the data that we want to see is gibberish (Figure 9).

Figure 8 -- encoded data

Figure 8 — Encoded data… it has to be important

However, when you look at the other functions and modules in the macro, the attackers did a very good job obfuscating the code.

Figure 9 -- gibberish

Figure 9 — Some gibberish function

While it’s difficult to figure out what is going on with these  functions, we can see a sub routine that has information about VM detection (Figure 10), then the call to our encoded data (Figure 11). With most malware samples, malware will first make a check to see if it’s “okay” to run, and if everything checks out, then the malware will decode the important functions. Keeping this in mind, this is where we are going to “attack” the malware.

Figure 10 -- Suspicious VM code

Figure 10 — Suspicious VM code

By modifying the function that contains the VM detection code, we can nullify their checks to bypass the security mechanisms. We can also set a breakpoint at our data of interest to see if, when the code is executed, we land where we want to be.

Figure 11 -- Modified macro and set breakpoint at interesting data

Figure 11 — Modified macro

After saving the weaponized .xls file and re-executing it, we will want to enable macros as well. If we go into our file and run the macro, we can see in Figure 12 that the code stops on our breakpoint, successfully bypassing all of the attackers anti VM / anti debugging / anti everything routines!

Figure 12 -- successful bypass

Figure 12 — Successfully bypassing their checks

After a successful bypass, let’s look at our encoded data, saved into the variable oPOJidsf. It’s good that we landed here, however there’s no way for us to (currently) see it. If we add a message box (Figure 13) to the code one line down and set another breakpoint, we can see what the attackers are trying to write out to this variable (Figure 14).

Figure 13 -- Modifying code

Figure 13 — Modifying the attacker’s code to print their data

Figure 14 -- Decoded data

Figure 14 — The attackers’ decoded data

Since it’s very difficult to copy / paste from a message box (Figure 15), we can write the data out to a cell in our Excel file to make copy / paste work better (Figure 16), since we now control code execution and flow.

Figure 15 -- VBA code

Figure 15 — VBA code to write our variable to the “a1” cell

Figure 16 -- Malicious Script

Figure 16 — Malicious script, now copy/pasteable

In short, the attackers will attempt to download a file from 85.143.166[d]190, save it as a CAB file, expand the CAB file to an .exe file in the %temp% directory, then start it.

We can now make a GET request for our file (Figure 17), which is still up on the server.

Figure 17 -- GET request

Figure 17 — GET request for the malware

Interestingly enough, the malware comes down as an .exe file (Figure 18), MZ headers and all.

Figure 18 -- .exe file

Figure 18 — .exe file

While the script expects a cab file to be downloaded, the “expand” still works on a non-cab file such as an .exe. This could be a slip up by the attackers or simply another way to not use the “copy” command.

Once the malware connects, it makes beacons (Figure 19) to 95.163.121[d]33 where it POSTs information.

Figure 19 -- Malware Beacon

Figure 19 — Malware beacon

From a malware perspective, this specimen is not very pretty on the wire and should stick out like a sore thumb. From top to bottom, the first suspicious indicator is the POST requests to the root directory. While this could be legitimate, this would be a good early-warning indicator for suspicious traffic.

The second area of interest is the content type. Again, why is this data being posted? This doesn’t look like a video/mpeg to me.

The third area of interest is the referrer field from https://google.com. When you’re doing searches and click a link, most of the information would be GET requests to a page, not a POST. This just doesn’t make sense in the context of this pcap.

The fourth and final section (and frankly, my favorite) is the Host: field. This field typically has the domain name for the request, but in this example, it doesn’t have a true domain (Figure 20). Most logs are still parsed as such, even by WireShark.

Figure 20 -- Forged hostnames

Figure 20 — Forged hostnames from the malware

But if you check the original domain…there’s no period. This is actually a space (hex 0x20), so you could look for host fields with a space in them. And no period. IDS / IOC gold right here.

The malware also communicates with the following IP addresses: 95.163.121[d]33 and 87.236.215[d]105.

The malware samples can be found here:

.xls file: https://www.virustotal.com/en/file/9afa90370cfd217ae1ec36e752a393537878a2f3b5f9159f61690e7790904b0d/analysis/

.exe file:


Pwning Dridex Excel Files

For all of this analysis to take place, it depends on one thing: breaking the Dridex password for the macro. With these files, it’s easy to do trial and error with a benign xls file in order to guess the length of the password. To make this easier, I wrote a script that will attempt to break the macro password on up to a 20-character password. Figure 21 provides a screenshot of the code:

Figure 21 -- Pwning

Figure 21 — Pwning Dridex macros

And Figure 22 shows what the output of a successful break looks like:

Figure 22 -- Output

Figure 22 — Output

For this code, you can download the python script here. Keep on the look out for more like this, and happy hunting and code breaking!

Updated March 25

There is a new version of Dridex going around, and it seems my old python script no longer works on this sample. Here’s an updated phishing email:


Figure 23 — Phishing email with updated version of Dridex

As pointed out by one user on Reddit , there are more methods in order to bypass the password on the macro file. I modified my script so that if no matches are found, it will cycle back through in order to append “0”s to fill in the space to break the macro. Once opened, I modified the macro code yet again to print out the encoded data:

more encoded data

Figure 24 — Encoded Data

This code modification should be the final nail in the coffin. Download the Python script here.

The malware sample can be found here:


The Return of NJRat
Decoding ZeuS Disguised as an .RTF File

Related Articles