Share:

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.

Figure 1

Figure 1. Dridex

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.

Figure 2

Figure 2. Letting the user know that the exploit was successful

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.

Figure 3

Figure 3. Sandworm reference

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

Figure 4

Figure 4. Extra information at the end of the RTF file

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.

Figure 5

Figure 5. File sizes 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.

Figure 6

Figure 6. Patterns in the file

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:

Figure 7

Figure 7. XOR script

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.

Figure 8

Figure 8. Word artifacts

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.

Figure 9

Figure 9. Dropped word document

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

Figure 10

Figure 10. Import table for our binary

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

Figure 11

Figure 11. No “This program”

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.

Figure 12

Figure 12. Value XORed with single-byte XOR of 0x20

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.