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:
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.)
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.
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.
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.
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).
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).
However, when you look at the other functions and modules in the macro, the attackers did a very good job obfuscating the code.
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.
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.
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!
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).
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.
In short, the attackers will attempt to download a file from 85.143.166190, 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.
Interestingly enough, the malware comes down as an .exe file (Figure 18), MZ headers and all.
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.12133 where it POSTs information.
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.
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.12133 and 87.236.215105.
The malware samples can be found here:
.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:
And Figure 22 shows what the output of a successful break looks like:
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:
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:
This code modification should be the final nail in the coffin. Download the Python script here.
The malware sample can be found here:
