Sunday, February 21, 2010

Quickly Triage Adobe PDF Documents for Malware

If you get frequently getting asked to analyze suspicious Adobe PDF documents for potential malicious content or malware, this triage guide might be of help. Adobe PDF documents are complex things to analyze sometimes, but it is possible to get a quick answer whether or not a particular PDF merits deeper examination.

You should always conduct this type of examination on an isolated machine off of any production network. Air-gapped VMware and Deep Freeze based examination systems work fine.

The steps below DO NOT definitely determine that a particular PDF has malware or is malicious - they are just good practice to triage PDFs to see if further analysis is warranted. These triage steps should take just a few minutes to complete. Deeper analysis can take hours or days depending on the complexity of the PDF sample.

1). Submit sample to This is the most reliable multi-AV scanner site available right now.

2). Submit sample to Wepawet: (Wepawet has a good reputation, but does sometimes report malicious PDFs as harmless if an obfuscation technique is used that Wepawet doesn't detect).

3). Submit sample to (This site sometimes is a little buggy, but is worth a try).

4). Run Didier Stevens’ (For this you will need a suitable Python runtime environment installed. You can get that for Windows from

With, what you are looking for is:
- The /Page output tells you how many pages are in the PDF document. At present, most malicious PDF documents you will come across will have only one page.
- Non-zero counts for /JS and /JavaScript indicate that the PDF document contains JavaScript. Almost all malicious PDF documents that you will come across will contain Javascript. The presence of Javascript DOES NOT by itself mean that the PDF is malicious. To make that determination correctly, you must see what the Javascript does.
- Non-zero counts for triggers like /AA and /OpenAction indicate that an automatic action to be performed when the page or document is viewed. Almost all malicious PDF documents you will come across will have both JavaScript and an automatic action to launch the JavaScript without any user action required. If you see both an automatic action trigger and JavaScript, you need to do further analysis. The PDF is probably not clean.
- A non-zero value for /JBIG2Decode indicates that the PDF document uses JBIG2 compression. This is unusual and worthy of investigation given the JBIG2 vulnerability that cropped up in Adobe reader around January 2009. The existence of JBIG2 compressed content isn't necessarily proof of malicious content, but you must investigate further if you see this.
- Any number in parentheses for any counter represents the number of obfuscated occurrences of that object type that found. A normal PDFiD report looks like what is shown below. If for example the "/JavaScript 0" line instead read "/JavaScript 1(1)", that is a clear red flag that the PDF needs further analysis. Obfuscation isn't normal in the section definitions of a PDF document.

PDFiD 0.0.10 typical_clean.pdf
PDF Header: %PDF-1.4
obj 348
endobj 348
stream 40
endstream 40
xref 2
trailer 2
startxref 2
/Page 27
/Encrypt 0
/ObjStm 0
/JS 0
/JavaScript 0
/AA 0
/OpenAction 0
/AcroForm 0
/JBIG2Decode 0
/RichMedia 0
/Colors > 2^24 0

Hopefully this process will help you more quickly and accurately sift through more of your malicious Adobe PDF triage workload. If you need assistance with malicious PDF analysis, please ZIP up your PDF and sent it to david @ Normal triage for one PDF is around $100 USD, and deep dive analysis is normally around $500 USD. As always, if you aren't happy with the work we will refund 100% of what you paid.

Similarly contact sales @ for assistance with malware sample analysis, Windows RAM dump analysis for malware or incident response (XP/Vista/Windows 7/Server 2000/2003/2008), and any Windows or MSI software packaging, automation, or deployment needs you might have. All work is backed by our normal 100% money back satisfaction guarantee.

email: david @

Wednesday, February 17, 2010

Adobe Reader GDI Leak not Fixed in Latest Release of 8.x or 9.x

The Adobe Reader GDI object leak described that I described at isn't fixed in the Adobe Reader 9.3.1 release that Adobe published on 16 Feb 2010. And it ALSO affects the newly released Adobe Reader 8.2.1. So if you can't live with this bug you have no way to patch the latest Adobe Reader vulnerabilites since versions 7.x and below are formally off support.

There is still no ETA from Adobe for a fix.

email: david @

Out of band(?) Adobe Reader Security Update Released

Adobe has released Adobe Reader versions 9.3.1 and 8.2.1 to address new security vulnerabilities.

Whatever happened to Adobe's plan to have their Patch Tuesday be on Microsoft's Patch Tuesday but just once per quarter? Adobe Reader 9.3.0 and 8.2.0 were released on 12 Jan 2010 which was right on time, but what about 16 Feb 2010? That isn't one quarter away from 12 Jan and it wasn't on Microsoft's Patch Tuesday.

At any rate, as described here this was to be expected for the next year or two.

Adobe's security bulletin is here.

email: david @

Sunday, February 14, 2010

Vulnerability in F5 Products - Review Both Internal and External Units

A denial of service (DoS) vulnerability has been identified in some F5 products. The vulnerability is within the TCP/IP stack of the affected versions. If exploited, it could cause devices to become unresponsive creating a denial of service condition.

F5 recommends restricting access to the affected interfaces as mitigation for this issue.


email: david @

Upgrading to Adobe Flash Player

Time to patch all of your Adobe Flash player instances again. Please remember to remove all older versions of the Flash player as part of your upgrade to make sure systems vulnerability scans come back clean and don't complain about old Flash version binaries laying around. If you need help automating this process, please contact sales @

Adobe's bulletin follows:

APSB10-06 - Security update available for Flash Player

Originally posted: February 11, 2010

A critical vulnerability has been identified in Adobe Flash Player version and earlier. This vulnerability
(CVE-2010-0186) could subvert the domain sandbox and make unauthorized cross-domain requests.

Adobe recommends users of Adobe Flash Player and earlier versions update to Adobe Flash Player
Adobe recommends users of Adobe AIR version and earlier versions update to Adobe AIR

Adobe's bulletin:

email: david @

Easily Detecting VMware Instances Vulnerable to CVE-2009-3733

A tool called gueststealer was released at Shmoocon 2010. Gueststealer is a Perl script that can be used to grab arbitrary files from VMware instances vulnerable to CVE-2009-3733. VMware instances vulnerable to this can be exploited to pull things like a .vmem file or even the VMware container file with the entire file system of the virtualized machine. Once that is done sensitive data could then be extracted.

The author of this article has created a nmap script that can be used to search for VMware instances vulnerable to this directory traversal problem. The nmap script works well and you should consider using it to not only scan your potentially vulnerable Internet-facing machines, but also internal systems. Also at this URL is a link to the gueststealer Perl script.

VMware's bulletin describing the issue is available here.

So grab the nmap script, find your vulnerable machines, use the gueststealer Perl script as needed to convince anyone that needs convincing that the problem is real and requires action, and then patch.

email: david @

Saturday, February 13, 2010

Budget-wise Espionage

I recently learned about a law enforcement investigative technique used to listen to voice mail messages on other peoples' mobile phones using caller ID spoofing. This technique is a little old, but not widely known. What might be an effective investigative technique to some is a potential data leakage or corporate espionage issue to others. As a proof of concept, I set up an account with a caller ID spoofing company and was able to access voice mail messages for a variety of personal and corporate Blackberry, iPhone, and cell phone devices. The problem isn't with the devices themselves, it is with how the service providers handle spoofed caller ID numbers. For the affected providers, if they see the source phone number is the same as the called number, they think the call is coming from the owner's phone and the call gets dropped directly into voice mail playback if no password or PIN is set. This technique currently works with both AT&T and Verizon and possibly other US providers.

The procedure goes like this:
1). Gain technical ability to spoof called ID info. I created an account with My account cost $20 for 200 pay-as-you-go minutes.

2). Call spoofing company service phone number. Enter account credentials.

3). Through spoofing service provider phone interface, call target phone with spoofed caller ID number set to the same number as the target. For example you call target 202-555-1379 with the spoofed called ID also set to 202-555-1379.

4). If no PIN/password or other protection is in place for the target's account, you get dropped straight into listening to voice mail messages on the target phone. So that means as long as you have a good mobile phone number for a target, you might be able to listen to their voice mail messages without their knowledge. This capability directed at the right people could result in the loss of sensitive information since people generally consider their voice mail boxes unbreachable without a court order or subpoena.

email: david @

Sunday, February 7, 2010

GDI Object Leak in Adobe Reader 9.2 and 9.3

There is a GDI object leak in Adobe Reader versions 9.2 and 9.3 (the latest). The leak happens when any PDF is opened in a new IE window, and persists even if the new IE window gets closed. Initially you leak around 4 GDI objects per iteration, but that snowballs a few dozen iterations in until you hit the Windows default per process GDI object limit of 10,000. At that point, PDFs won't render any more, and Windows Explorer might fail due to resource exhaustion. The problem happens after opening and closing around 120-150 PDFs in new IE windows. If this bug is affecting you or any business process you have, you might want to consider downgrading the affected machines to the fully security patched Adobe Reader version 8.2 level. This bug has been reported to Adobe and has Adobe Bug Number 2551445. Adobe has provided no ETA for a fix yet.

If you need any assistance providing an automated upgrade package for Adobe Reader or anything else, please contact sales @

email: david @

Hello there!

Hello there! This is the blog associated with and This will be a place that I hope you find of value for information related to the entire universe of network and computer security including: incident response, forensics, malware analysis and reverse engineering, server and client RAM dump analysis, vulnerability management and patching, security assessments, policy and standards matters, industry trends, and so forth. Most topics will focus on the defensive side of computer and network security, but we reserve the right to deviate from that theme from time to time.

email: david @