Didier Stevens

Monday 30 October 2017

Update: pdfid.py Version 0.2.2

Filed under: My Software,PDF,Update — Didier Stevens @ 0:00

I regularly get ideas to improve my tools when I give (private) training, and last week was not different.

This new version of pdfid.py adds a /URI counter, to help identify PDF documents with embedded URLs, used for phishing or social-engineering users into clicking on links.

I did not hardcode this new counter into the source code of pdfid.py, but it is listed in a new config file: pdfid.ini. You too can add your own identifiers to this configuration file.

pdfid_v0_2_2.zip (https)
MD5: 20614B44D97D48813D867AA8F1C87D4E
SHA256: FBF668779A946C70E6C303417AFA91B1F8A672C0293F855EF85B0E347D3F3259

Sunday 29 October 2017

Update: pdf-parser.py Version 0.6.8

Filed under: My Software,PDF,Update — Didier Stevens @ 15:32

This is a bugfix version.

pdf-parser_V0_6_8.zip (https)
MD5: 7702EEA1C6173CB2E91AB88C5013FAF1
SHA256: 3424E6939E79CB597D32F405E2D75B2E42EF7629750D5DFB39927D5C132446EF

Monday 24 April 2017

Bash Bunny PDF Dropper

Filed under: Hardware,My Software,PDF — Didier Stevens @ 0:00

More than 5 years ago, I worked out a technique to drop any file on a machine which has removable storage disabled. The technique used a Teensy to simulate a keyboard and type out a pure ASCII PDF to notepad. The PDF, containing an embedded executable, can then be saved and opened with a PDF reader to extract the embedded file.

I recently re-visited this technique with my Bash Bunny (it can also be done with a Rubber Ducky):

First I create a pure ASCII PDF file with an embedded executable using my make-pdf-embedded.py tool:

make-pdf-embedded.py -f fi80 -t -n Dialog42.exe.txt Dialog42.exe Dialog42.pdf

Option -f select the filters to use: f to deflate (zlib compress) and i80 to use hexadecimal lines of 80 characters to encode the compressed executable file in pure ASCII.

Option -t for pure text.

Option -n to choose the name used in the PDF document for the embedded file (files with extension .exe can not be extracted with Adobe Reader).

And then I create a Ducky Script script from the PDF with my python-per-line.py tool:

python-per-line.py "Duckify({})" -o payload.duck Dialog42.pdf

The payload.duck file can then be installed on my Bash Bunny, referenced from a payload.txt bash script like this:




QUACK STRING notepad.exe

QUACK switch1/payload.duck

Here is a video showing my Bash Bunny dropping this PDF file:

Thursday 20 April 2017

Malicious Documents: The Matryoshka Edition

Filed under: maldoc,Malware,PDF — Didier Stevens @ 0:02

I must admit that I was (patiently) waiting for the type of malicious document I’m about to describe now. First I’m going to analyze this document with my tools, and after that I’m going to show you some of the mitigations put in place by Adobe and Microsoft.

Malicious document 123-148752488-reg-invoice.pdf is a PDF with an embedded file and JavaScript. Here is pdfid’s report:

As we can notice from this report, the PDF document contains /JavaScript and an /OpenAction to launch this JavaScript upon opening of the PDF file, and also an /EmbeddedFile.

pdf-parser.py searching for JavaScript (option -s javascript) reveals that the JavaScript is in object 5:

Object 5 contains JavaScript (option -o 5 to select object 5, and option -f to decompress the stream with JavaScript):

This script (this.exportDataObject) will save the embedded file (996502.docm) to a temporary file and launch the associated application (if MS Office is installed, Word will be launched). A .docm file is a Word document with macros.

So let’s search for this embedded file:

The embedded file is stored in object 3, as a compressed stream (/FlateDecode).

So let’s decompress and extract the file with pdf-parser: option -f to filter (decompress) and option -d to dump the content. Since I expect the embedded file to be a Word document with macros, I’m going to analyze it with oledump. So in stead of writing the embedded file to disk, I’m going to extract it to stdout (-d -) and pipe it into oledump:

oledump‘s report confirms that it is a Word document with macros. I’m not going to spend much time on the analysis of the VBA code, because the intent of the code becomes clear when we extract all the strings found in the VBA code. First we select and extract all VBA code (options -s a -v) and then we pipe this into re-search to produce a list of unique strings (enclosed in double quotes) with these options: -n str -u

One of the extracted strings contains 3 URLs separated by character V. The macros will download an XOR encoded EXE file from these sites, decode it and execute it.


The first mitigation is in Adobe Reader: the embedded .docm file will not be extracted and launched without user interaction. First the user is presented a dialog box:

Only when clicking OK (the default option), will the .docm file be extracted and launched. Remark that the maldoc authors use some weak social engineering to entice the user to click OK: see in 996502.

When opened in Word, macros will be disabled:

This next mitigation is put into place by Microsoft Word: macros are detected, and by default, they are not executed. Here we see a better attempt at social engineering the user into executing the macros.

You might have expected that this document would be opened in Protected View first. After all, the PDF document was e-mailed to the victims, and Outlook will mark the PDF with a mark-of-web when it is saved to disk:

But Adobe Reader will not propagate that mark-of-web of the PDF document to the extracted Word document (at least the version I tested, version XI). Without mark-of-web, Word will open the document without Protected View.

Another simple mitigation for this type of malicious document that you can put into place but that is not enabled by default, is to disable JavaScript in Adobe Reader.

Remark that these documents do not contain exploits: they just use scripting.

Wednesday 28 December 2016

Update: pdf-parser Version 0.6.7

Filed under: My Software,PDF,Update — Didier Stevens @ 12:03

I added option -k to search for keys in dictionaries. A usage example can be found in blog post “PDF Analysis: Back To Basics“.

pdf-parser_V0_6_7.zip (https)
MD5: D04D7DA42F3263139BC2C7E7B2621C91
SHA256: ED863DE952A5096FF4BE0825110D2726BA1BE75A7A6717AF0E6A153B843E3B78

Saturday 30 July 2016

Bugfix: pdf-parser Version 0.6.5

Filed under: My Software,PDF,Update — Didier Stevens @ 16:19

This is a bugfix for pdf-parser. Streams were not properly extracted when they started with whitespace after the normal whitespace following the stream keyword.

pdf-parser_V0_6_5.zip (https)
MD5: 7F0880EB8A954979CA0ADAB2087E1C55
SHA256: E7D2CCA12CC43D626C53873CFF0BC0CE2875330FD5DBC8FB23B07396382DCC85

Tuesday 7 June 2016

Recovering A Ransomed PDF

Filed under: PDF — Didier Stevens @ 0:00

I was contacted to help with a PDF file encrypted by ransomware. Just like another case I helped with, the file was not completely encrypted. The file had parts with low entropy, as byte-stats.py shows:


Searching for endobj, I noticed the file contained PDF objects:


So I stripped the beginning of the file that was encrypted:


This file can be parsed by pdf-parser. Now I’m going to try to rebuild this PDF. First I check if it contains an object referencing all pages:


As you can see, it doesn’t. So I will add the missing objects:


Object 2 (the missing /Pages object) needs to reference all pages still present in the document (/Kids list). I make a list of all /Page objects with the following command:


And then I update object 2 /Pages with the 87 /Page objects I found (dictionary entries /Kids and /Count):


When I open this PDF with a PDF reader, I get 87 pages. All of them are blank, except the last one:


The pages are blank because of missing fonts definitions:


I add some generic font definitions:


This gives me the following PDF:


AS you can see, not all text is readable, that’s because I did not select the right font. Some trial and error with different fonts would allow me to further recover the document.

This method can also help you with corrupt PDF documents. Of course, this is not a complete recovery. We miss the first pages that were encrypted.

Monday 21 September 2015

PDF + DOC + VBAs Videos

Filed under: Malware,PDF — Didier Stevens @ 10:46

I produced videos showing how I created my “Test File: PDF With Embedded DOC Dropping EICAR” and how to change the settings in Adobe Reader to mitigate this.

Friday 28 August 2015

Test File: PDF With Embedded DOC Dropping EICAR

Filed under: PDF — Didier Stevens @ 9:30

Over at the SANS ISC diary I wrote a diary entry on the analysis of a PDF file that contains a malicious DOC file.

For testing purposes, I created a PDF file that contains a DOC file that drops the EICAR test file.

The PDF file contains JavaScript that extracts and opens the DOC file (with user approval). The DOC file contains a VBA script that executes upon opening of the file, and writes the EICAR test file to a temporary file in the %TEMP% folder.


You can download the PDF file here. It is in a password protected ZIP file. The password is eicardropper, with eicar written in uppercase: EICAR.

This will generate an anti-virus alert. Use at your own risk, with approval.
pdf-doc-vba-eicar-dropper.zip (https)
MD5: 65928D03CDF37FEDD7C99C33240CD196
SHA256: 48258AEC3786CB9BA032CD09DB09DC66E0EC8AA19677C299678A473895E79369

Thursday 13 August 2015

Update: pdf-parser Version 0.6.4

Filed under: Malware,My Software,PDF,Update — Didier Stevens @ 0:00

In this new version of pdf-parser, option -H will now also calculate the MD5 hashes of the unfiltered and filtered stream of selected objects, and also dump the first 16 bytes. I needed this to analyze a malicious PDF that embeds a .docm file.


As you can see in this screenshot, the embedded file is a ZIP file (PK). .docm files are actually ZIP files.

pdf-parser_V0_6_4.zip (https)
MD5: 47A4C70AA281E1E80A816371249DCBD6
SHA256: EC8E64E3A74FCCDB7828B8ECC07A2C33B701052D52C43C549115DDCD6F0F02FE

Next Page »

Blog at WordPress.com.