Whenever attackers make a shift in tactics, techniques, and protocol (TTP), we like to make note of it to help both customers and the rest of the Internet community. We recently analyzed a sample that started out appearing to be Dridex, but quickly turned into a headache leading to Dyre that featured some notable differences to past Dyre samples. One PhishMe user was targeted to their personal account, and here’s a copy of the phishing email:
Once opened, we’re presented with the very familiar story of “please enable this macro so you can get infected”. This time, they do give a few more instructions to the user, saying that the data is “encoded” and macros need to be enabled to read the text.
Hitting alt + F11 to look at the macro presents the same familiar password-protected macro file (Figure 3). Up until this point, this is similar to every other Dridex sample we’ve looked at in the last few months.
However, running the brute forcer tool on the macro file presents an error message. This typically comes up when there is a file size mismatch (Figure 4). Looking at the code however, shows that something went wrong (Figure 5).
There should be a few extra 0’s in there, but not that many. Looking at the original file shows some trickery the attackers used in order to break our python script (Figure 6). By having the extra data inside of these variables, we couldn’t clear it cleanly, but the office document is still rendered / decoded without any issues. Time for plan B.
For plan B, I chose to use OleVBA to extract the macros. It’s better to keep the code inside of Office if possible, as you can use the built-in debugger to modify the code to print decoded data as needed. Luckily for us, the domains are in the clear. One of the really cool things with OleVBA is that the script does some analysis as well, printing out possibly malicious URL’s inside of the file.
To confirm that these are not just gibberish domains, I checked to ensure that the file was expecting to download something from the following pages:
By using unmaskcontent.com to remotely pull the contents, we can see that a file is meant to be downloaded.
Once the macro executes live on the system, a lot of nastiness runs on the computer. Winword.exe should have very few processes spawned from it, if any (Figure 10). We can also see a randomly named executable running at the bottom, which exits pretty quickly.
After a second look at the file, the malware does a check to see how many CPU’s the user has on their system. If it’s only 1, it assumes it’s being executed inside of a VM and exits. By modifying the VM to have more CPU’s, you can get the malware to execute successfully. This has been in the Dyre strain of malware for the last few weeks.
Looking at the running pcap, we can see the initial calls from the dropper as well as the download of the .exe (red), a second call for a .tar file (blue) which is a possible sign for Upatre, then the calls for i2p nodes (yellow) that we’re familiar with in Dyre.
By doing a grep and splitting on the values, we can see that this matches up with Dyre.
A list can be downloaded from here, but please do a once-over on these as it contains things like .b32.i2p and 188.8.131.52.
This is also part of the “man1” campaign for Dyre.
Looking back at malware samples, PhishMe saw these mangled .doc samples as early as April 16th. Here’s a phishing email that they spoofed the date on, but which we saw on the 16th:
As it stands, macro-based attacks are still a problem. With many groups adopting the technique, it’s likely here to stay.