Analysis of a Targeted Attack on a Critical-Infrastructure Company Using CVE-2010-3333

By Gal Badishi | November 28, 2012

Earlier this year, one of our clients, a critical-infrastructure company, was the subject of a targeted attack. Following some information gathering emails, 2 emails containing a different malicious RTF file were sent to the company’s CEO and to one of the company’s leading executives. The emails were supposedly about corruption in the company, and their contents included specific names and titles of the company’s executives. The RTF files contained an exploit for CVE-2010-3333, tailored for the recipient’s computer system. Unfortunately, no anti-virus detected the files as having malicious content, partly because they were obfuscated. Luckily, Cyvera TRAPS was installed on the executives’ computers and stopped the exploit from succeeding (as TRAPS is not signature-based), while alerting the local CISO. As it is now allowed to publish the attack and its details, we hereby present the obfuscation and exploitation techniques used in the attack.

One of the RTF files targeted Word 2010 on Windows 7. As detailed in our analysis of CVE-2010-3333, the ROP payload needs some time before it can be used, as it can only use msgr3en.dll, and it takes time for Word to load it. Consequently, the malicious RTF file contained nothing but than hundreds of blank pages with the exploit code on the last page, to allow Word 2010 to have ample time to load msgr3en.dll.

Let’s take a look at some of the exploitation code, just before the ROP payload, and then dissect it (compare with our vulnerability analysis):

We see that the exploit starts with some obfuscations, meant to thwart signature-based analyses who look for the \shp construct:

Now the real \shp used in the attack appears, but again, with some obfuscations, both to hide the \shp itself, and to hide the fact that it’s going to be followed by the pFragments property:

Following that is the \sp construct, which, for the exploitation to work, should be followed by a “{\sn pFragments}” property. Notice how the attacker again tries to evade parsers that use regular expressions to detect an exploit:

And the same thing is true for the \sv construct, which must come after the pFragments property, and should hold the array used to perform the exploit:

And as if that wasn’t enough, the data array itself is obfuscated (as much as it can be), by placing a string of pound signs in it. This string just gets discarded by the RTF array decoder, so we get that the array (pre-ROP payload) looks like this:

This is the exact same exploitation scheme used in our analysis of the vulnerability. We can see the zeros at the end, allowing for a fast return to the overwritten instruction pointer, which holds the address 0x3f208017 – a ROP-NOP in msgr3en.dll. As we have already described, what follows is the ROP payload. Let’s take a look at it now:

We can definitely see at the end a bunch of NOPs (they’re followed by more NOPS and the shellcode), so we can expect a VirtualProtect/jmp esp combo. Here’s the ROP payload in action:

We can see that even the ROP payload is manually-crafted and obfuscated. It does use VirtualProtect to set execution permissions on the stack, and then runs the shellcode. The shellcode itself downloads a self-extracting RAR named ctfmon.exe, which has a WinWord icon. The RAR file contains 2 executable files, smsse.exe and jre.exe, which are digitally signed, with a valid certificate chain rooted at VeriSign. The malware contains an infostealer and a client that connects to a remote C&C server.

This targeted attack was not detected at that time by any anti-virus in VirusTotal’s list. Partly because of the obfuscation mechanisms used, and partly because they just miss this exploit (see remarks at the end of our CVE-2010-3333 analysis). Although the company’s executives had an anti-virus with up-to-date signatures installed on their computers as part of the company’s security policy, it was not able to protect them from this exploit. On the other hand, Cvera TRAPS prevented the exploitation attempt by blocking the critical paths the attacker had to use in order to successfully exploit the vulnerability.

Lesson learned.