A few weeks ago, we posted an article about how Dridex is experimenting with different families of malware and techniques. When one threat actor starts shifting TTP’s, it’s usually a big deal. Attackers get comfy in their infrastructure, some survive sinkholes, and they continue spamming or stealing money. One shift takes time, effort, and money on the attackers part. The part that people often forget is that attackers need people to maintain backends, code the malware, code panels, and patch exploits as researchers find them, or else they are going to be exploited by said researchers.

In the case of Dridex, our attackers have invested a good bit of time into developing and testing new techniques, such as delivery techniques. Over the last few weeks, we have seen them experiment with:

Word documents with Macros (typical Dridex)

Neutrino malware

Pony malware

Zip with .js deliveries

Straight .js files attached to the document

Word exploits (CVE-2012-0158)

CAB attached files

To put these changes into perspective, for all of 2015, Dridex can be broken down by the following percentages, courtesy of Phishing Intelligence. The attackers have used seven different attachment types…and it’s only February.

While the others are interesting, the most interesting of them all is the exploit for 2012-0158, an exploit for Word. When triggered on a vulnerable system, the document opens, quickly closes, and then opens a second document without user interaction. The dropped document is rather amusing.

This specific exploit was a favorite of APT actors for a long time, and was quickly adopted by attackers on the cyber crime side due to the reliable nature of the exploit.

The file used for this exploit is an RTF file, however straight .doc files can be used as well. When looking at the file statically, we can see references to “sandworm” in the file.

Looking further at the end of the RTF file, we can see that the RTF file ends, with extra information appended to the end.

By looking at our original file, the original attachment sits right at 510KB. When we cut off the part of the code for the RTF file, which gives us 176KB for the “RTF” portion of the document, and 334KB for our executable. Our EXE is actually 307KB, so we can be fairly certain that our exe is somewhere in the binary blob after the end of the RTF file.

The only down side is that when you do a ctrl + F to look for “This program”, an artifact of an exe…it’s not there. We also have 30KB or so of extra space, so randomly cutting and trying to find where the file is will be difficult. However if we look at the end of the file, we do have a clue of how the file may be encoded.

See the pattern? Working backward, it goes 8 to 7 to 6…all the way down to 0, then starts back at FF, or 255, then 254, and so on and so forth. This pattern repeats for several hundred bytes, which is an indication of an incremental XOR, where the attacker will XOR the data with 00, then 01, then 02, and so on until FF, then start back at 00. Since we have 255 possible values, we have a 1 in 255 chance of successfully guessing where the XOR starts from the top. However here at the end, we know that the last value is more than likely going to be an 8 based on the last byte.

For our script, we’ll need to swap the order of the bytes, begin a decrementing XOR now that our byte order has switched, and start at “08”, and work backwards. Here’s what our script will look like:

Once we XOR and swap the bytes back, we can see our NULL values (which we expected to see) as well as extra information, which appear to be artifacts of a word document.

We also know that this word document is dropped to the system post-exploit, as the binary data from Figure 1 is referenced as well.

Working backward, we can successfully identify the import table for a binary.

But when we ctrl + F to find “This program”, it’s no where to be seen. What the heck?

However by using XORsearch, we can see that “This program” is encoded with a single-byte XOR of 0x20, adding a second layer of obfuscation to the binary.

For the exploit, the final payload is Dridex. Here is a list of IP addresses associated with the malware, courtesy of Phishing Intelligence:

185.24.92.236

91.239.232.145

144.76.73.3

103.245.153.70

193.17.184.250

41.86.46.245

41.38.18.230

62.109.133.248

217.35.78.204

148.202.223.222

181.177.231.245

141.89.179.45

188.126.116.26

5.9.37.137

141.16.91.132

46.183.66.210

178.118.31.240

103.23.154.184

174.70.100.90

200.69.183.183

185.47.108.92

200.57.183.176

194.126.100.220

194.95.134.106

176.53.0.103

181.53.255.145

hxxps://45.127.92.175:8143/sudosev

Given the recent adjustments and tactic shifts with Dridex, this is something that we all will need to watch out for in the next coming months. With Dyre out of the picture, this may be an attempt by the Dridex operators to fill in the gaps where Dyre left off.