From Targeted PDF Attack to Backdoor in Five Stages

As reported by Adobe in July, a Flash vulnerability is being actively exploited by targeted attacks against Adobe Reader. Yes, embedding Flash movies in PDF documents is supported in Adobe Acrobat 9. The idea of allowing Flash movies to be displayed within PDFs isn’t bad if you like your documents spiced up with a bit of interactivity or training videos. From a security perspective, however, this poses yet another attack vector for criminals to take control of vulnerable systems. As history has shown, complexity and feature richness go hand in hand with remotely exploitable vulnerabilities. It is unfortunately no different with this latest PDF feature.

The exploitation of this vulnerability continues. Below are screenshots from one such malicious PDF document, discovered in a targeted attack this week. The attack contains several compressed streams and at least two embedded Flash movies. The first embedded Flash movie is clean, the second 6exploits CVE-ID 2009-1862, which causes a memory corruption and allows an attacker’s code to execute. Underneath the compression layer, JavaScript code is embedded in the PDF document. This code fills heap memory with the attacker’s shellcode. Apart from the PDF acting as an additional obfuscation layer around the exploit, the JavaScript code, once unpacked, contains another function that attempts to evade detection.

The FileInsight screenshot above shows the JavaScript function “lololo(),” which deobfuscates a string holding the actual malicious payload at run time. The function simply replaces any occurrence of the substring “XX” found in “payLoadCode” with the substring “%u,” converting the previously obfuscated string into one that can be “unescaped” to x86 shellcode. Its purpose is to prevent security products from detecting escaped strings that might be an indicator for an exploit. To find out about the payload’s final purpose, we load the final unescaped string into a disassembler:

This shellcode decodes a certain area found within the PDF document, using XOR operation and key 0xF4, writes every piece of decoded data to a file, and finally executes it by calling the WinExec() API function. The resulting file is a UPX-packed executable with an additional layer of a custom packer on top, complicating static analysis of the binary (proactively blocked as “BehavesLike.Win32.ModifiedUPX.J” by McAfee Gateway Anti-Malware). In order to analyze the executable, it first needs to be freed from its packer layers. What we see then is the executable’s ability to drop the DLL mscvr.dll to disk, with file attributes set to “hidden,” so it can’t be seen in Windows Explorer with default settings enabled. And before the malware injects this DLL into memory of the running explorer.exe process, it infects the network diagnostic utility netstat.exe on disk, so the utility will load msvcr.dll each time it runs. The DLL contains a configuration file embedded as a resource, telling the netstat utility to not display certain Chinese hostnames that the DLL is about to phone home to.

The DLL component is aware of several desktop security products. It attempts to terminate them before it collects private data–such as information about the operating system, CPU speed and type, the list of available drives, the logged-in user’s account name, and credentials for several programs (such as MSN Messenger). What is really bad about this piece of malware is its backdoor component. The sneaky code is capable of connecting to its creators, and waiting for instructions telling it what to do next. Next to common backdoor functionality like uploading, downloading, and moving files–which allow data theft and modification–the backdoor also contains a command to instruct the malware to spread to removable drives (as a worm does). This behavior can infect a corporate network, as we all know from the Conficker incident. McAfee Gateway Anti-Malware protects against this targeted attack, proactively blocking the malicious PDF document as “BehavesLike.PDF.CodeExec.EPEO.”