Decoding ZeuS Disguised as an .RTF File

While going through emails that were reported by our internal users using Reporter, I came across a particularly nasty looking phishing email that had a .doc attachment. At first when I detonated the sample in my VM, it seemed that the attackers weaponized the attachment incorrectly. After extracting and decoding the shellcode, I discovered a familiar piece of malware that has been used for some time.

Figure 1

Figure 1 — Phishing email

In the headers (Figure 2) we can see that the originating IP address is 212.154.192[d]150. The reply-to field is also interesting, as this is the address of a long-time 419 scammer. In Figure 3, an interesting side step presented as malware was attached to the email.

Figure 2 — Email headers

Figure 3

Figure 3 — 419 scam from 2012. Email can be found here

Starting out, I attempted to detonate the attachment in a VM and was presented with the following error message:

Figure 4 — Office error message

The system tested has 45GB+ free as well as 2 GB of RAM so insufficient disk space wasn’t a problem. For testing, I bumped the RAM up to 8 GB, and the same error persisted. I decided to take a look from a static analysis perspective.

I opened the file in notepad++, as usual, to get a feel for what I was  analyzing. Once opened, I could see that it was an .rtf file dressed as a .doc file. While this is legitimate and perfectly fine, it’s relatively easy to run obfuscated in the .rtf format.

Figure 5 — RTF file in Notepad++

Inside of an .rtf file,  big chunks of data that represent hex code can contain clues about what the document is trying to do. The .rtf file format gives the attackers a lot of freedom to hide and encode data in these sections, see Figure 6.

Figure 6 — Suspicious data

At the end of this section, however, we have a trailing “FF D9” which is the ending two bytes for a .gif file.

Figure 7 — Ending bytes for the .gif file

To decode blobs of data like this, I prefer to use notepad++. Once you copy / paste this section to a new tab, you can do a CTRL + F to replace “r” with nothing and “n” with nothing (Figure 8). By doing this, you will get the ascii-represented hex on one line. Select everything, and go to Plugins, Converter, and Hex -> Ascii. (Figure 9.)

Figure 8 — Search/replace for Notepad++

Figure 9 — Decoding the data

Once converted, you’ll start seeing strings that look like an image. (JFIF and Photoshop strings, Figure 10) By saving this as something.gif, you can open this file in Paint or another program to see the image. (Figure 11.)

Figure 10

Figure 10 — Decoded image

Figure 11

Figure 11 — Image from the .rtf file

Continuing down this path of manually decoding each section, we come to another section that is larger than our first. This is a picture of our same house, however, the file size is much larger at 3 MB (Figure 12), as opposed to our 79 KB for the first image.

Figure 12

Figure 12 — Larger file


By doing a Google image search for this image, we can find out that this is actually the exterior for a 3D designed house. This also doesn’t play very well into the theme of the original email.

To make things even more suspicious, there is an embedded .docx file. (Figure 13) When I tried to open this file, it errored out and there was nothing of interest in the XML of the file.

Figure 13

Figure 13 — Embedded .docx file


50,000 lines or so into the file, we can see the magic bytes for a 97-2004 office document (Figure 14). Again, why does the .rtf file contain both new and old doc formats?

Figure 14

Figure 14 — Ascii representation of .doc magic bytes


A few thousand line breaks later, we get our first sign that there’s something interesting coming up. Camel case / changing the casing of things is one way to help bypass AV or other signature detection.

FIgure 15

Figure 15 — Different casing for the call

2,000 or so lines later we can find yet another function, this time switching the casing.

Figure 16

Figure 16 — Case switching

By removing double line breaks (rr and nn), we can condense the code to get an idea of what’s going on and see code that shouldn’t typically be found inside of an .rtf file.

Figure 17

Figure 17 — Code that shouldn’t be inside of an .rtf file


In the red of Figure 18, there is some hex code that shouldn’t exist inside of the .rtf file. Further down (blue box) we can also see “AAAA” which may indicate an “inc ecx” in assembly.

Figure 18

Figure 18 — Suspicious alignment in .rtf file


However in Figure 19, we find a small snippet that is about the size of what shellcode would be. By decoding this section, we can find a reference to an executable at the end, making this the section we have been searching for! (Figure 20.)

Figure 19

Figure 19 — Is this the shellcode we’re looking for?

Figure 20

Figure 20 — This is the shellcode we’re looking for. Malicious URL: http://aspks[d]nl/components/kom/ks.exe


Once we open this binary file in IDA, we can see that this is actually a snippet of code. The assembly instructions fit with what we would expect to see. Based off of the shellcode and other artifacts of the code, this is associated with CVE-2012-0158 – an older but very reliable exploit.

Figure 21

Figure 21 — Near entry point for shellcode

Now that we have the link, we can test and see if the malware link is live. Sure enough, it is! (Figure 22.)

Figure 22

Figure 22 — Malware download


Once executed, persistence is created as a run key in the registry.

Figure 23

Figure 23 — Persistence install for the malware


The malware installs to the following directory: C:Users<username> AppDataRoamingRitesequapq.exe. From a forensics perspective, searching for exe files in this directory or the Roaming directory are golden, as this shouldn’t happen.

For the malware on the network side of things, it makes many requests to “file.php” and “gate.php”. (Figure 24.) The IP address of 116.193.77[d]118 is also listed on ZeuS tracker. (Figure 25.)

Figure 24

Figure 24 — HTTP requests out


Figure 25

Figure 25 — ZeuS tracker for IP addresses. Link here

We can also see other Ladycoll configurations from the memory dump:

Figure 26

Figure 26 — Memory dump from the malware


In closing, even though CVE-2012-0158 is three years old, attackers are still using it to this day. Even once they obfuscate these documents, it’s still possible to get back to their true intentions.

Malware hashes:

Dridex Code Breaking – Modify the Malware to Bypass the VM Bypass
Wired: Can Gamification Help Catch Phishing Scams?