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 22.214.171.124 20070711 EXP/Office.D
There are two common scenarios of attack involving Word documents:
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"
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
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 126.96.36.199 20070711 HEUR/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.
Dec 17th 2007
|Thread locked Subscribe||
Dec 17th 2007
1 decade ago