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.
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.
Starting out, I attempted to detonate the attachment in a VM and was presented with the following 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.
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.
At the end of this section, however, we have a trailing “FF D9” which is the ending two bytes for a .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.)
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.)
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.
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.
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?
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.
2,000 or so lines later we can find yet another function, this time switching the casing.
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.
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.
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.)
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.
Now that we have the link, we can test and see if the malware link is live. Sure enough, it is! (Figure 22.)
Once executed, persistence is created as a run key in the registry.
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.)
We can also see other Ladycoll configurations from the memory dump:
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.