RTF Attack Takes Advantage of Multiple Exploits

This is a joint analysis by Haifei Li, Stanley Zhu, and Jun Xie of McAfee Labs

Recently, the rich text format has provoked new interest in the security industry due to a critical RTF zero-day (CVE-2014-1761) exploit found in the wild. McAfee Labs has investigated this threat. As usual, we suggest our customers apply our solutions right away if you haven’t already done so.

In this post, we want to share our analysis of another RTF exploit. This attack is particularly interesting because the single RTF sample tries to exploit two previous vulnerabilities. This multiexploitation technique is usually seen in HTML or JavaScript exploits but rarely for RTF or Office exploits.

Analyzing the exploit
As you can see in the following figure, the malicious RTF comes as an attachment to an email that appears to be a UPS delivery invoice.

We have analyzed the content of the RTF at a deep level. The content consists of several objects, which we will examine one by one.

The first object looks like the following:

The first object loads both first- and second-stage shellcode in memory. After successful exploitation, the first-stage shellcode searches the memory for the second-stage shellcode and executes it. We’ll explain this later.

The second object in the RTF file is some OLE data read via the program ID “Word.Document.12,” which suggests that it contains a Word 2007 OpenXML document.

We can simply “unzip” the .docx file and find something like this.

As shown above, the attack uses the same nonscriptable heap-spraying trick that we first identified in the Office TIFF zero-day attack, which we discovered in the wild last November. Previously we had seen the trick used only with OpenXML formats (.docx); this time the trick is used with RTF.

The third object aims to exploit a years-old but still popular Office vulnerability. This vulnerability, CVE-2010-3333, is a stack-based overflow in MSCOMCTL.OCX. The vulnerability is easy to exploit, which makes popular in many exploit kits.

After successfully exploiting CVE-2010-3333, shellcode will execute; it’s a very smooth attack. However, CVE-2010-3333 is an old vulnerability that was patched more than three years ago. To maximize the chance of hacking into victims’ systems, the attacker has made some innovations.

The third object also tries to trigger the CVE-2013-3906 TIFF paring vulnerability through a “\pict” control word, with the object stream actually a crafted TIFF file.

CVE-2013-3906 is an integer overflow vulnerability in OGL.DLL. By exploiting the vulnerability, an attacker can control the program flow to heap memory around 0x0A0AXXXX. At this point, the heap memory has already been sprayed there via the second object, so the first-stage shellcode will be correctly executed in the heap. The shellcode uses 0x3F (AAS) as the NOP instruction.

After that, the first-stage shellcode in the second object searches for and executes the second-stage shellcode.

Analyzing the dropped malware
After a successful start, the exploit downloads the malware from http://track.invoice-accounts.org/WebTracking/updateoffice.exe and executes it. See following piece of shellcode:

The dropped updateoffice.exe is a variant of the Win32/Trojan.zbot family. Now let’s look at a behavior analysis of the malware, consisting of three steps.

Step 1
The malware copies itself to the %temp% directory and renames itself laruo.exe (with perhaps some random characters), and executes. The full path may look like this:
C:\Documents and Settings\%user%\Local Settings\Temp\Owma\laruo.exe.

Step 2
Laruo.exe releases its driver file (2ad5a3) to the %system32\drivers directory and loads it into the kernel (C:\WINDOWS\system32\drivers\2ad5a3.sys). The malicious driver replaces a kernel-mode driver, and also hooks NtOpenProcess and NtOpenThread in the SSDT kernel. The driver code is encrypted. The malicious driver is a variant of the W32.Rootkit.Necurs family.

Step 3
Laruo.exe is injected into the explorer.exe process, and adds itself to AutoRun by editing the following register key:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run Value: “C:\Documents and Settings\sh1t0u\Local Settings\Temp\Owma\laruo.exe.

Laruo.exe disables the Windows firewall by modifiying the value of the register key
HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile.

It also does some self-deleting using the following command line:
C:\WINDOWS\system32\cmd.exe” /c “C:\DOCUME~1\%user%\LOCALS~1\Temp\OLDFF57.bat.

With the malware injected into explorer.exe, the injection code connects to the malicious domain aulbbiwslxpvvphxnjij.biz (50.116.4.71) for DNS requests. The string is contained in the malware file itself, as shown next:

The address 115.126.143.176 is the active control server as we write this:

Conclusion
To simplify, the process of the RTF exploit takes four steps:

1. Load the second-stage shellcode for future execution (preparing for Step 4)
2. Spray the heap using the method we first saw in the CVE-2013-3906 .docx exploit (preparing for Step 4)
3. Exploit CVE-2010-3333
   A. If successful, the malware executes (shutting down the Word process). => Game over
   B. If failing, nothing happen except go to Step 4.
4. Exploit CVE-2013-3906 with the sprayed heap and second-stage shellcode prepared in Step 1 and 2. => Game over

In this post we have showcased a real-world multiexploitation RTF attack that we recently detected in the wild. Even though the RTF is not a scriptable file format, this RTF-specific trick is able to exploit multiple vulnerabilities in one single RTF attack. This trick helps bad guys maximize their chances of success.

From this analysis we now know how flexible the RTF file format can be: It could perhaps embed any Office exploit. From a defense point of view, the complexity of the RTF format poses a challenge for accurate detection via signature-based methods. We have seen quite a lot of RTF exploits that lack detections, but we are glad to see that our sandboxing solutions–such as McAfee Advanced Threat Defense and the Advanced Exploit Detection System project–are filling the gap.

We would like to thank Bing Sun, Xiaoning Li (McAfee Labs,) and Chong Xu for their help with this analysis.

Introducing McAfee+

Identity theft protection and privacy for your digital life

Download McAfee+ Now