We’ve all had situations in which our organization received a malicious binary, and we needed to understand rapidly what it did. Application level exploits are more difficult to investigate, as they have much greater dependence on their environment than the average Windows binary. In July of this year, we received one such targeted attack sample, with limited AV coverage at the time:

AntiVir 7.4.0.39 20070711 EXP/Office.D
Avast 4.7.997.0 20070711 MW97:CVE-2006-2492.Gen
AVG 7.5.0.476 20070711 Exploit.Oledata
BitDefender 7.2 20070711 Exploit.MSWord.Ginwui.Gen
DrWeb 4.33 20070711 Exploit.Wordbo
F-Prot 4.3.2.48 20070710 CVE-2006-2492
Ikarus T3.1.1.8 20070711 Trojan-Dropper.MSWord.1Table.bd
Microsoft 1.2704 20070711 Exploit:Win32/Wordjmp.gen
Symantec 10 20070711 Bloodhound.Exploit.86
VBA32 3.12.0.2 20070710 suspected of Exploit.Signature

There are two common scenarios of attack involving Word documents:

• Documents that are in themselves not malicious but contain a malicious “embedded object”. This attack methodology is commonly used in the IRS/BBB/DOJ Trojans that have been reported throughout 2007. From an investigation point of view, Trojan binaries are easy to extract. Open the document in Wordpad (preferably in a Virtual Machine), and copy paste the object into another directory;
• Documents crafted to exploit a file-parsing vulnerability in the application software. In this case, the document contains a crafted component which exploits a specific vulnerability, followed by shellcode which takes further action. It generally either downloads an external, second-stage payload, or executes an embedded Trojan binary. These attacks are sparingly used “in public”, but are very common in closely targeted attacks.

In the second scenario, it’s rather difficult to investigate the embedded Trojan. One way of approaching this is by installing a post-mortem debugger on a vulnerable system, and having a look at what happens upon opening the malicious file. However, you may not always have an accurate combination of both application and Operating System available.

In some cases there is an easier way. As the resulting shellcode and binary Trojan are completely independent from the Word document, they are often plainly visible and can relatively easily be identified using a HEX editor.

When reviewing our Word document in such a tool, I focused on the “MZ” magic string identifying a Windows binary. PE binaries are prefixed by a stub MS DOS executable. This executable was introduced for compatibility reasons and is ignored by Windows loaders. It merely displays “This program cannot be run in MS-DOS mode”, after which it returns control to the operating system. As such, grepping a file for “DOS mode” can quickly reveal embedded binaries.

This file however, didn’t contain such string. Exploit developers often use encoding to make the resulting document difficult to analyze, and to hide the actual shellcode and any embedded files from plain sight. A very common way of doing this is by XOR’ing each byte of the code with a specific key.

Didier Stevens, a Belgian researcher wrote a great tool called XORsearch, which allows you to search for a specific string in a XOR encoded file. As there are a number of strings we know we can search for, this tool can save us a lot of hassle:

qetesh:~$ xorsearch -s malcode3.doc "http"
qetesh:~$ xorsearch -s malcode3.doc "DOS mode"
Found XOR FF position 1246C: DOS mode....$
qetesh:~$

In this case, I searched for “http” to see whether any download URL was present. This is common in exploit samples where the initial code connects to a remote server to download a second stage payload. The search however was unsuccessful. Searching for “DOS mode” though, reveals a Windows executable around position 1246C, XORed with key 255. The parameter “-s” requests xorsearch to dump the complete Word document, XORed with this key, to disk..

If we’re lucky, and the file is encoded with a single key, it now becomes trivial to extract it from the image xorsearch has dumped. We can either copy the PE headers into a hex editor and calculate the full file length (HEX editors with PE templates – like HEX Workshop or 010 Editor are useful for this). Alternatively we can use a forensic file carver such as “foremost” to extract it in a more automated fashion:

qetesh:~$ foremost -i malcode3.doc.XOR.FF
Processing: malcode3.doc.XOR.FF
|*|
qetesh:~$ ls -la output/exe/
total 72
drwxr-xr--  2 user user  4096 Dec 15 20:27 .
drwxr-xr--  4 user user  4096 Dec 15 20:27 ..
-rw-r--r--  1 user user 59392 Dec 15 20:27 00000146.exe
qetesh:~$

Now we can use our standard malware analysis techniques on the  binary. It turns out anti virus was only flagging this file heuristically as the binary, through packing, applied entry point obfuscation and other anti-debugging tricks:

AntiVir 7.4.0.39 20070711 HEUR/Malware
CAT-QuickHeal 9.00 20070711 (Suspicious) - DNAScan
Sunbelt 2.2.907.0 20070711 VIPRE.Suspicious
Webwasher-Gateway 6.0.1 20070711 Heuristic.Malware

After unpacking and analysis, it became clear the Trojan gathered credentials for e-mail accounts and web mail providers, shipping these off to an HTTPS server in Hong Kong. Simultaneously, it opened a reverse backdoor to a second server located in Taiwan.

This approach to dealing with application exploits isn’t complete at all – there are plenty of opportunities for the attacker to render it useless, or even trick the analyst in believing a component is important, while it really isn’t. On the other hand, it does offer us as incident handlers a quicker way of assessing the situation.

--
Maarten Van Horenbeeck