Through the contagiodump.blogspot.com report, in this post will be analyzed a PDF with characteristics different from those in previous posts. The document it’s collected through a mail attachment as well shown in the contagiodump blog:
In particular, as the first step, the file it’s been opened with an editor (Notepad++). As always there are some tags that require decoding Inflate to get the code in the clear. But a note of interest it’s been discovered: (since I’m not a PDF specs guru) in the following statement
In the screen shot above there is a red note that it’s easily confirmed following this Google query:
The /DL token it’s explained in the PDF Specs at following link: http://www.adobe.com/devnet/pdf/pdf_reference.html
In addition the red note is confirmed by analyzing the Metasploit module for generating exploitable PDF files as shown in the following screen shot:
IMHO this code contains a “not so bad” methods for a good low detection technique.
The shellcode (variable name “sc”) it’s obtained, function urpl at line 1, replacing the “Z” char with “u” obtaining the following UCS2 stream:
Using Malzilla it’s been obtained the following hex stream ready to been posted at http://sandsprite.com/shellcode_2_exe.php
Trying to analyze the shellcode the first step it’s bypass an anti debugging technique. For this goal it’s been pressed the “F7” step by step debugging mode option of IDA Pro. Don’t use “F8”. (many thanks to http://whsbehind.blogspot.com/ for the hints). In this mode it’s possible decrypt (XOR with 0xBCD3DBE7 in EDX) the first piece of runtime code and following in the subsequent steps:
And the following screen shot it’s a step before the setting and jump to the new value of EIP:
The assembly code now it seem interpretable by IDA:
For the shell code, it’s possible analyze the runtime code until a certain point. After it must continue with the static analysis of code and in some cases this approach may be not a good approach. The best approach is run Adobe Reader under debugger, open the malicious PDF file, and identify pieces of code involved in the exploiting and execution of shell code. By way of example on the next screen it’s shown a file size checking conducted by the standalone shell code. In the following picture the shell code it’s executed out from Adobe Reader context, or if you prefer in “standalone mode”. In this condition there aren’t open PDF file handles. Then ,as in this case, running standalone shell code leads to a condition of infinite loop. So, in conclusion, it’s necessary loading the malicious PDF in the an Adobe Reader context and tracking the behavior with an application debugger.
The 127728 bytes is the size of the PDF file:
Trying to analyse the shell code under the Adobe Reader context its been detected the following code from which start to a better analysis:
It’s shown the Multimedia.API plugin code zone where it’s handled the method that trigger the issue. The screen shot above potentially contains info that may be used as starting point for writing “third part” patch.
For other behaviors like network traffic, dropped file, and system activities please check http://contagiodump.blogspot.com/2009/12/dec-29-cve-2009-4324-adobe-0-day.html.