We've written about sextortion emails several times. Reader Jason submitted another variant: password protected PDFs with a sextortion message (including QR code for the BTC address).

This gives me the opportunity to discuss some interesting aspects of encrypted PDFs.

PDFs can be encrypted for 2 main purposes: confidentiality and "Digital Rights Management" (DRM).

When a PDF is encrypted for confidentiality, the user has to provide a password upon opening of the PDF. This is known as the user password.

While opening a DRM PDF does not require the user to provide a password. The user can just read the content of the PDF without a password, but the user might be restricted as to what can be done with the PDF. For example, printing or copying text might be disabled. To change these DRM settings, the user needs an owner password.

An unusual property of encrypted PDFs, is that their internal structure remains unencrypted. When a PDF file is encrypted (for confidentialy or DRM), the whole content of the PDF file is not encrypted. Contrary with other file formats, like Word documents. The internal structure, like objects and names, is not encrypted. What is encrypted, are strings and streams.

So for example, when a PDF document contains a JavaScript script, there will be an object with name /JavaScript in its dictionary (we exclude stream objects /ObjStm in this example). And the script itself will be contained inside a string as a dictionary value (again, in this example).

When this PDF is encrypted, the object with its dictionary keys (like /JavaScript) will remain in cleartext, while the string with the script will be encrypted.

Let's analyze a sample submitted by Jason with pdfid.py. Here is the result:

First of all, the counter for name (keyword) /Encrypt is not zero: this tells us that the PDF is encrypted.

Second, the counter for name /ObjStm is zero: this tells us that the PDF does not contain stream objects (/ObjStm). This is important to check when dealing with encrypted PDFs, as stream objects are objects that contain other objects inside their stream. And since streams are encrypted, the objects contained inside a stream object are completely encrypted, and thus totally opaque to us unless we decrypt the document.

All the other names have counters equal to zero: although this is no guarantee that the PDF is not malicious, it is often a strong indication that this PDF does not contain malicious code, unless this is not your common malware attack (like a targeted attack or a pure binary exploit for a zero-day).

So the next step to take, is to look at the content of this PDF. For this, we need the password (4534 for this sample, it was included in the email message) to open the document. While you can open this document with any PDF reader (best done inside a VM), I'm going to view the content with pdftotext, a free utility that comes with the open source software Poppler.

The user password 4534 is provided via option -upw.

It's clear that this is a sextortion message. It was delivered via an encrypted PDF in an attempt to evade detection.

Encrypted PDFs often pose a problem for anti-spam and anti-virus solutions, when they are not able to decrypt the content. My pdf tools have no decryption capabilities: I first use QPDF to decrypt PDFs for further analysis with my tools.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com