2012 Tenth Annual International Conference on Privacy, Security and Trust

PDF S CRUTINIZER: Detecting JavaScript-based

Attacks in PDF Documents
Florian Schmitt¹, Jan Gassen² and Elmar Gerhards-Padilla²
¹ University of Bonn - Institute of Computer Science 4
Friedrich-Ebert-Allee 144, 53113 Bonn, Germany
² Fraunhofer FKIE
Friedrich-Ebert-Allee 144, 53113 Bonn, Germany
{schmittf, gassen, padilla}@cs.uni-bonn.de

Abstract—For a long time PDF documents have arrived in the
everyday life of the average computer user, corporate businesses
and critical structures, as authorities and military. Due to its
wide spread in general, and because out-of-date versions of PDF
readers are quite common, using PDF documents has become a
popular malware distribution strategy. In this context, malicious
documents have useful features: they are trustworthy, attacks
can be camouflaged by inconspicuous document content, but
still, they can often download and install malware undetected by
firewall and anti-virus software. In this paper we present PDF
Scrutinizer, a malicious PDF detection and analysis tool. We use
static, as well as, dynamic techniques to detect malicious behavior
in an emulated environment. We evaluate the quality and the
performance of the tool with PDF documents from the wild,
and show that PDF Scrutinizer reliably detects current malicious
documents, while keeping a low false-positive rate and reasonable
runtime performance.
Keywords—PDF, document malware, client-side exploits, ma-
licious PDF
I. I NTRODUCTION
Nowadays malicious software is a major issue of infor-
mation technology. Since attacks using remote exploits have
become rather difficult, client-side exploits are commonly used
for carrying out cyber attacks. In particular, attacks using
malicious PDF (Portable Document Format) documents are
increasingly popular with malware writers and operators. As
PDF documents became widespread in the population and the
general acceptance of the format has grown, malware authors
realized the potential of PDF for malware distribution [1].
PDF is an electronic document format maintained by Adobe
Systems Inc., which allows the filing and exchange of docu-
ments, regardless of the operating system. Dynamic content is
enabled with the ability to embed JavaScript code in PDF
documents. Although the format simplifies the handling of
documents using computers, it also opens possibilities for
client-side attacks. Thus, PDF documents are used for targeted
and non-targeted attacks on private persons, business organi-
zations and government agencies.
In July 2011, a malicious PDF document was found, whose
content was a call for papers for ”2012 AIAA Strategic
and Tactical Missile Systems Conference” [2]. The included
malware installs a backdoor, in order to take access to the
victims network. It must be assumed, that this was a targeted
attack against defense contractors or military authorities [3].
Non-targeted malicious PDF documents are often mass-
mailed to web users via email [1]. With the help of social
engineering tricks, the user is encouraged to open a malicious
attachment. In [4], an example is given for a spam-based
campaign using attached malicious PDF documents. The email
messages contain for instance spoofed orders or invoices, in
order to induce the recipient to open the attached document.
Another realized method, although not targeting a single
person or institution, will apparently mostly affect enterprises:
The email body is primed to trick the victim into thinking,
that the present email is from a copier machine, which sends
scanned documents, converted into PDF documents, automat-
ically via email [5]. There is a good chance, that users, which
are accustomed to such a system, will open the attachment.
Although several PDF readers exist, it is likely, that Adobe
Reader is the most widespread PDF document viewer, which
is why attackers mostly focus on its vulnerabilities. In July
2011, a report was published, stating that 60 % of the users of
Adobe Reader are using vulnerable versions of the program
[6]. Similarly, in [7] it is reported, that although Adobe Reader
is installed on 83 % of companies machines, 56 % of those
installations are out of date and thus vulnerable. With such a
huge amount of potential victims, this is a great incentive for
criminals to increase the usage of PDF documents as malware
distribution strategy.
Although governments do not necessarily reveal internally
used software, authorities often publish documents or forms on
their websites, for which reason it can be presumed, that they
do use PDF creation and reading software internally. “There’s
not a federal agency that does not use PDF. Acrobat software
and Adobe PDF are key technologies in some capacity at all
branches and levels of government, the military and virtually
every agency.”, said Greg Pisocky, Business Development
Manager at Adobe Systems Inc. [8].
These examples show, that the use of PDF is both, a relief
and a threat for governments, companies and private users. At-
tacks can be executed, without the victim becoming suspicious,
by masquerading malicious documents as relevant information.
Additionally, since the client initiates the attack, by opening a

978-1-4673-2326-0/12/$31.00 ©2012 IEEE 104

malicious document, security solutions as firewalls generally
do not prevent the assault. Once the control over the PDF
reader’s process is taken, malware can be downloaded and
installed onto the clients system.
In this paper we present PDF Scrutinizer, an analyzer, using
static and dynamic detecting approaches in order to classify
PDF documents. Common existing approaches often rely on
signature-based detection techniques, where embedded code
is scanned for known exploits, which is a fast way to detect
malicious PDF documents. This approach, however, suffers
from sophisticated obfuscation methods, which are used within
malicious PDF documents. Hence, with PDF Scrutinizer, in
addition to using signature-based techniques, embedded code
is executed in a controlled analysis environment. With our
technique, on the one hand, vulnerable objects are emulated
to detect known attacks. On the other hand, dynamic heuristics
are used to examine the operations of the interpreter during
evaluation, with the aim to detect malicious behavior.
In our evaluation, we will show that PDF Scrutinizer is able
to detect current malicious PDF documents while maintaining
a low false-positive rate. Furthermore we will show, that
PDF Scrutinizer is able to process large amounts of PDF
documents with reasonable runtime.
Today, PDF Scrutinizer focuses on JavaScript-based at-
tacks. Still, it is possible to integrate detection-modules for
non-JavaScript-based exploits. With our evaluation, two mod-
ules for common non-JavaScript-based exploits were used.
II. P RINCIPLES
The Portable Document Format (PDF) is a format repre-
senting electronic documents, published by Adobe Systems
in 1993. The occasion of its development was the request
for a document format, with which it is possible to create,
view, print and exchange documents reliable and environment-
independent [9]. Today, PDF is virtually the standard elec-
tronic document format for printable documents. JavaScript-
support was introduced with PDF version 1.3 and allows for
example the usage of interactive forms, database communica-
tion or dynamic document content.
PDF is virtually a text format consisting of human-readable
identifiers, but it also contains binary data e.g., in terms
of images, embedded files or encrypted data. The format
is organized by referencing objects, described by an object
number and a generation number. PDF documents allow
incremental updates, whereas objects are superseded by newer
generations. Each object instances one of eight data types. One
considerable object type is called name, a unique identifier,
which starts with a slash.
A JavaScript action is an object holding either a string
or a reference to a string or stream object, containing
JavaScript code. The PDF specification allows the evaluation
of JavaScript actions at several points in time during the
lifetime of a document within a PDF reader. For example,
when a document is loaded, a special object, the document
catalog, is examined. JavaScript actions, referenced by the
/OpenAction or /Names keys of the document catalog,
105
are executed. Despite, triggering actions after the document
is loaded is also possible, for example, when the user prints
or closes the document, or even only after a certain page
is displayed. This can be done by connecting the additional
action name /AA of a page with a JavaScript action.
The capabilities of JavaScript code used in PDF documents
is not limited to the core JavaScript features, but enhanced by a
diverse JavaScript for Acrobat API. Important objects offered
by the API are the static app class, which encapsulates the
reader application and the doc object, which represents the
currently opened document.
Malicious Techniques used in PDF Documents
The PDF format enables attackers to utilize various tech-
niques allowing them to perform stealthy and effective attacks
against the victims PDF reader. One commonly used technique
to prevent attacks from being detected is called obfuscation,
which is explained below. Subsequently, the general procedure
of exploiting vulnerabilities is explained in section II-B and
the method heap spraying, which is widely used in JavaScript-
based attacks, is introduced in section II-C. Additionally, the
malicious usage of embedded files is illustrated in section II-D.
A. Obfuscation
Obfuscation is a technique used to disguise the real content
of an information, or the real functionality of source code.
A PDF document itself can be obfuscated to hide several
properties of the document. In contrast, JavaScript code can
be obfuscated to reduce the readability. In both cases, the
motivation for obfuscation can be legitimate, for example to
protect ones intellectual achievements, or can be malicious,
for example to complicate static analysis of the document or
code.
A basic code obfuscation method is the reduction of read-
ability. Thereby, for instance, the code is split up where
possible and veined with useless multi line comments. Another
often used technique is the scrambling of identifiers, at which
variable names and function names are replaced by long,
semantically equivalent sequences, which are difficult to read
for humans. Dead code, which never gets executed, is often
introduced to distract the analyst.
JavaScript allows evaluation of code during runtime, which
enables the usage of more complex obfuscation techniques.
For instance, code can be stored encrypted in a string, called
payload, and only during runtime it is deciphered and ex-
ecuted. With the use of the Acrobat API it is furthermore
unnecessary to include the payload in the script, because it can
be distributed to locations within the document. For example
meta data fields of the document and even the words of the
document can and will be used to store the payload.
B. Exploitation of Vulnerabilities
When exploiting vulnerabilities in PDF readers, the attack-
ers goal is to execute shellcode with the privileges of the
readers process. PDF exploits can be categorized into two
kinds: JavaScript-based and non-JavaScript-based [1].
 JavaScript-based exploits attack methods of the JavaScript
for Acrobat API, whose implementations contain security
flaws. To trigger an exploit, a vulnerable method is called
with primed arguments. The aim is to overwrite the methods
return address, hence the control flow is changed. In order
for shellcode to be executed, the process memory of the PDF
reader is prepared by a technique called heap spraying.
With non-JavaScript-based exploits, either, for example,
embedded Flash files are used to conduct heap-spraying and
afterwards a vulnerability unrelated to the JavaScript-engine
is exploited. Or even vulnerabilities are known, where heap
spraying is unnecessary, but rather the control flow can be
directly redirected to shellcode embedded in one of the docu-
ments objects.
C. Heap Spraying
To place shellcode in the PDF readers process memory, it
can be allocated as a unicode string either to a variable or as an
array value. In both cases, the shellcode is stored in the heap
area. Since the exact location of the shellcode in the memory
is unknown, with heap spraying, the heap space is filled with
multiple blocks, consisting of nop-sled and shellcode. When
an exploit takes place, and a return address is overwritten with
an address that points approximately into the sprayed memory
region, the chance is high, that the program counter is set to
an address, which is located in one of the nop-sleds, leading
to shellcode execution [10].
D. Malicious Embedded Files
The PDF format allows embedding of arbitrary files into
documents. This feature is also used by malware operators to
disguise malicious content and exploiting additional vulnera-
bilities. For instance, the Adobe Reader can display embedded
Flash programs directly. This allows exploitation, not only
of the PDF reader program, but also of the integrated Flash
Player, as shown in [11] and [12].
Another particularly interesting technique, named nested
PDF, is given by embedding a malicious PDF document
into a benign document [13]. The top-level document can
be constructed in a way that the embed document is loaded
instantaneously, even multi-layered constructions are possible.
With this approach, the malicious content is encapsulated in a
single PDF object.
III. R ELATED W ORK
There are a number of existent malicious PDF analysis tools.
In the following we present three dynamic and one pure static
analysis tool, and compare each one with PDF Scrutinizer.
Wepawet is a web service for analysis and detection of
web-based malware [14] [15]. It lists found exploits, evaluated
JavaScript code, potentially detected shellcode and found mal-
ware. Wepawet uses anomaly detection and machine learning
approaches to classify PDF documents. As PDF Scrutinizer,
Wepawet uses an emulated environment to execute extracted
JavaScript code. During the execution, dynamic information
106
are logged and features are extracted. With Wepawet, they pre-
sented ten features, which include for instance, the number of
bytes allocated through string operations, the number of likely
shellcode strings and the values of attributes and parameters in
method calls [15]. Using a known-good dataset they learned
anomaly thresholds, which are used to classify newly analyzed
documents. Since the internals of the analysis environment are
non-public, it is unknown how much and which parts of the
Acrobat API are currently emulated in Wepawet. Compared
to Wepawet, PDF Scrutinizer does not use a machine learning
approach, where general information about the execution are
collected and tested against learned thresholds. Instead, the
occurrence of a small number of events, which likely represent
malicious operations, induce a malicious classification in PDF
Scrutinizer.
In [16], a standalone PDF document analyzer called MD-
Scan is presented. For execution of extracted JavaScript code,
they modified the Java-Script-engine Spidermonkey, for which
they emulated parts of the Acrobat for JavaScript API. For
detection of malicious documents, MDScan dynamically an-
alyzes used string variables for the presence of shellcode.
Because this approach does not rely on previously known
vulnerabilities, they claim to be able to detect malicious
documents, which exploit unknown vulnerabilities in PDF
readers. But on the other hand, concrete, known vulnerabilities
cannot be identified, so details about the attack, as CVE-IDs,
are not given. In addition, they rely solely on detection of
shellcode. Even if most PDF documents contain shellcode,
with this approach, the detection rate depends exclusively
on the quality of the used shellcode detector. Furthermore,
shellcode is not necessarily stored in a string variable, but can
also be wrapped in an array, or can consist of multiple arrays.
PDF Scrutinizer uses multiple heuristics, to be able to detect
a broader range of malicious operations. In addition, to enable
the identification of concrete vulnerabilities, known vulnerable
methods are emulated.
One solely static approach using machine learning is imple-
mented with PJScan [17]. Here, JavaScript code is extracted
and used for a lexical analysis to determine features. After-
wards, classifications are made by comparing new samples
with previously learned thresholds. Since the code is not ex-
ecuted, dynamically constructed and evaluated scripts are not
available and only top-level code can be considered. Compared
to the beforehand presented tools and PDF Scrutinizer, PJScan
can be distinguished by a significantly higher performance,
because of the fact that no code has to be executed. In contrast,
drawbacks of this approach are that no information and no
identification of concrete attacks can be given. Additionally,
it has a high false-positive rate of about 16 %, when testing
benign PDF documents including JavaScript code.
IV. I MPLEMENTATION
A. Overview
Because of the widespread use of PDF, a huge amount
of PDF documents are in circulation. The major demand for
automated malware processing software is a preferably reliable

PDF document
PDF Scrutinizer
JavaScript detected found triggered embedded
code shellcode exploits heuristics files
Fig. 1. Functionality of PDF Scrutinizer
classification, with that a manual analysis becomes obsolete.
Thus, the classifications malicious, suspicious and benign were
chosen. As a result, the amount of documents, that need to be
manually examined is reduced to the documents which are
classified as suspicious.
The main functionality of PDF Scrutinizer is the classi-
fication of PDF documents into these three categories. To
support the analyst during the process of examining suspicious
PDF documents, PDF Scrutinizer does not only display the
resulting classification, but also furnishes further information
on the reasons of the classification. For example, if any known
exploits were used in the document, its CVE-ID is given and if
any heuristics were triggered, they are indicated. All occurring
JavaScript code is saved, as well as any found shellcode.
Additionally, all embedded files are extracted and saved for
later analysis. To overcome the nested PDF technique, any
embedded PDF documents are saved and afterwards analysed
separately by PDF Scrutinizer. Figure 1 illustrates the main
functionality of the tool. In the following, the main activities
of PDF Scrutinizer are described.
1) Parsing: At first the document is loaded and parsed.
All PDF objects are analyzed and saved in memory, so that
following steps can access them. Because of the fact that
malicious PDF documents are often malformed and corrupt,
the parsing must not be limited to the PDF specification.
Instead, the parsing component should try to extract PDF
objects at all cost. In PDF Scrutinizer, we focused on sim-
ulating the way Adobe Reader parses documents, because of
the fact that it is the most widespread reader with the most
known vulnerabilities. Because of ambiguities in the PDF
specification and the amount of different readers, which are
running on different platforms, including mobile devices and
browser-integrated PDF readers, this approach is not sufficient
to be able to gain an optimal detection rate. It would thus
be conceivable in the future, to implement multiple instances
which emulate different readers. But certainly, this approach
would increase the analysis time significantly.
2) Extraction of actions: The next step is the extraction of
JavaScript actions. PDF Scrutinizer first tries to find actions
the same way, as any PDF reader does. The document catalog
dictionary is examined, if an /OpenAction is registered.
Furthermore, the documents catalog can store a reference
to the /Names array. This array is scanned for included
JavaScript actions. Since, for example any page or annotation
extract execute
malicious parsing
JavaScript JavaScript
suspicious
benign create
access
parsed
dynamic
document API heuristics
access emulation
PDFBox Rhino libemu
PDF Scrutinizer
Fig. 2. Architecture of PDF Scrutinizer
can store an additional action referencing a JavaScript action,
every PDF object which contains the additional action name
(/AA) is analyzed. JavaScript execution can also be initiated
using AcroForms, wherefore the document is searched for the
existence of those. If any AcroForms are found, the encapsu-
lated JavaScript code is extracted. All encountered JavaScript
code is collected, saved for later analysis and processed in the
next step.
3) Execution of actions: The extracted JavaScript code is
executed in a modified JavaScript-engine, where parts of the
Acrobat for JavaScript API are emulated. To provide certain
API methods, it is necessary, that their implementations access
the loaded PDF document. Only in this way, they are able
to return the correct values, which are needed for code to
continue error-free execution and expose the real, malicious
functionality. The API emulation is illustrated in more detail
in section IV-C. To detect malicious behavior, the modified
interpreter keeps track on operations and variable values
during evaluation of code. So, several dynamic heuristics
were developed, which monitor the control flow for malicious
operations, they are explained individually in section IV-E.
B. Architecture
PDF Scrutinizer is a Java library, which extends and con-
nects existing components. Apache PDFBox [18] is used as
interface to the loaded PDF document, every interaction with
the document is performed through the library. PDFBox was
selected, because a large part of the PDF specification has
been implemented, and because the included PDF parser works
well, even with malformed documents. However, PDFBox was
modified in several ways, to emulate the parsing methodology
of Adobe Reader and to improve the processing of malicious
documents.
To execute JavaScript code, which was extracted from
the PDF document, Mozilla Rhino [19] is utilized. Rhino
only supports the main features of JavaScript and does not
include the Acrobat for JavaScript API. In order to be able
to execute Acrobat JavaScript nevertheless, parts of the API
were emulated and details in the behavior of the interpreter
were modified. For this reason, Rhino allows adding custom
objects into the context of the interpreter. Thus, it is possible
to emulate API methods, by implementing their functionality,
and if required, accessing the document through PDFBox.
Malicious PDF documents commonly rely on shellcode
107
in order to execute malicious commands within the readers
process. Thus, recognition of shellcode can be used to detect
potential attacks within the examined document. This can be
achieved, by using libemu [20], which is a shellcode detection
and analysis library. It tries to detect shellcode by searching
for GetPC code, which is used in lot of shellcodes to find
the actual value of the program counter. In PDF Scrutinizer,
libemu is used to analyze variable values for the presence of
shellcode during execution.
The architecture and the interaction of the components in
PDF Scrutinizer is sketched in figure 2.
C. API Emulation
To successfully execute JavaScript actions, which were
extracted from PDF documents, the Acrobat for JavaScript API
has to be emulated. Malicious JavaScript, using the Acrobat
API, commonly only uses a subset of all available methods.
Since the entire Acrobat API is rather complex, just the most
frequently used methods, based on observation of the present
samples, were emulated in PDF Scrutinizer. The possibility
to extend the emulated API easily is provided.
Essential parts of the emulated API correspond to the
JavaScript for Acrobat API, thus provides compliant results.
Hence, for instance, the methods doc.getAnnots and
doc.getPageNthWord where implemented according to
the specification. With these methods, early stage JavaScript
code extracts shellcode or JavaScript code, that is for example
located in the documents annotations or text. It is important
to note, that this part contributes significantly to the success
of the further detection methods. If the emulation lacks in this
early loading phase, further malicious code is not correctly
constructed and never gets executed, thus the heuristics would
not be able to detect the attack. Since encrypted JavaScript
code or shellcode can also be stored in the documents meta-
data, it is important to make their actual values available to the
engine. In our emulation, corresponding to the JavaScript for
Acrobat API, these properties are encapsulated in an object
accessable thru doc.info.
Apart from methods which are API-conform, known to
be vulnerable methods are additionally emulated, in order to
detect the usage of known exploits. Known vulnerable methods
are prone, for example to buffer-overflow or use-after-free
attacks in the emulated reader version. In PDF Scrutinizer,
these methods are certainly not actually vulnerable, but they
analyze the used parameters for primed values, known to cause
exploits. This way, it is feasible to detect specific known
vulnerabilities a malicious document is trying to exploit. We
included the methods which are vulnerable to our knowledge.
In Addition, stub methods, without any functionality, are
needed, so that the engine does not abort if any JavaScript code
invokes them. If such a method is not expected to deliver a
return value, the omission is simple. In the case, a return object
is needed, we supply a mock object, which contains at least the
correct data structure and default values. We further provided
the ability to modify the JavaScript engine directly, in a way
that it acts more tolerant and not throws exceptions, if invoked
108
methods are non-existent. Although this modification enabled
certain scripts to execute thoroughly, even if methods were
called that were not covered in the context, there were negative
side effects. We encountered malicious PDF documents, which
use exception handling constructs to detect simulated environ-
ments. For example, a non-existed method is called purposely
and the malicious behavior is only exposed within the error-
handler. With the proposed modification activated, the error-
handler would not be called and thus the malicious code would
not be executed. Therefore, we disabled this extension during
evaluation.
The Acrobat for JavaScript API provides means to execute
scripts asynchronously. Given scripts are executed either one
time after a given period elapsed or periodically. In malicious
documents asynchronous methods are for instance used, to
delay malicious operations until the document is rendered.
This is done, because a victim could become suspicious after
loading a document, when a reader is not responding and is
not showing the content.
Asynchronous methods can also be utilized to detect em-
ulated environments, which are for simplicity not delaying
the script execution, but are executing given scripts instanta-
neously. Hence, asynchronous API methods were implemented
in PDF Scrutinizer. For example, a script, which changes
a variable, can be delayed, and following code can easily
determine, by checking the value of the variable, whether the
script was instantly executed or is still being delayed. With
this technique, the script can expose an emulated environment
and avoid execution of malicious code to remain undetected.
This is a general issue of the emulation approach: Since
only a subset of the available API methods are available,
a document could detect being in a analysis environment
by invoking not commonly used API methods and check
the return value for plausibility. With this information, a
malicious document could disguise its malicious behaviour
to bypass detection or it could go into an endless loop. In
order to identify the latter, a basic endless loop detection has
been developed, in which case the document is marked as
suspicious.
D. Static Heuristics
Static heuristics treat source code as string and analyse
it using string analysis, with the goal to discover malicious
or suspicious elements in the code. Although this approach
can be outsmartet using obfuscation or dynamic evaluation of
code, it can provide a fast option, to test for signatures or to
detect suspicious strings. In PDF Scrutinizer, the developed
static heuristics process all extracted JavaScript actions, as
well as any code which is send to the eval method of
the interpreter. Additionally, any code, that is executed by
asynchronous methods, is forwarded to the static heuristics. In
the following, the developed static heuristics are introduced.
RegexMalicious includes a list of signatures, which are based
on regular expressions. The code is checked for occur-
rences of the signatures. If any signatures are found,
the document is marked as malicious. Unfortunately,
 no source of signatures, tailored to malicious Acrobat
JavaScript, is publicly available. Thus, a new list, contain-
ing vulnerable method calls including parameters, which
are often used by exploits, was created, based on a set of
malicious PDF documents containing known attacks.
RegexSuspicious is similar to the first static heuristic, but in
contrast, it marks the document as suspicious when a
match occurs. Currently, the set of regular expressions
consists of words which are used in some malicious
JavaScript code as variable names, i.e. ”exploit”, ”shell-
code” or ”heapspray”.
VulnerableMethodCalls uses a list of known vulnerable API
methods, and examines how many of them are found
in the code. If the code string contains any vulnerable
method calls, it is marked as suspicious.
E. Dynamic Heuristics
To be able to detect malicious documents even if they
use unknown vulnerabilities, dynamic heuristics were imple-
mented. In PDF Scrutinizer, the JavaScript interpreter was
modified in order to monitor certain variable values and to
intercept certain bytecode instructions. This way, the relevant
information are forwarded to heuristics, during execution.
1) StringLengthTester: Usually, long strings in malicious
JavaScript code occur, when constructing NOP-sleds later
utilized in heap spraying. Therefore, the StringLengthTester
heuristic tests used variables for an excessive number of
characters. If the length of a used string exceeds a configurable
threshold, the document is marked as malicious. Evaluation
indicates that 100,000 characters is a suitable amount used as
default threshold.
Strings are only examined at one point in Rhino’s inter-
preter: the assignment of variables. It must be mentioned that
this point is not only reached at the first assignment of a
variable. As in JavaScript every string change leads to an
assignment of a new string, this point is reached whenever
a string modification takes place.
2) HeapSprayDetector: Heap spraying is an essential tech-
nique used in most JavaScript-based attacks in PDF documents
and overcomes the trouble of getting to know the exact
location of shellcode in memory. Hence, when exploiting a
vulnerability, the overwritten return address only needs to
be roughly in the right memory region. Usually, with heap
spraying, strings consisting of nop-sled and shellcode are
added to an array, effectively inflating the heap segment with
large amounts of data.
When executing code, which utilizes heap spraying, in
a JavaScript engine, the memory is filled with such large
blocks of nop-sled and shellcode, leading to a bad runtime
performance. The ambition to prevent heap spraying from
happening, led to the development of a feature, which can
detect heap spraying and at the same time stop inflation of the
heap segment. With this feature, heap spraying is detected and
avoided which reduces the analysis time significantly.
The HeapSprayDetector feature hooks into the operation
of the interpreter where elements are added to arrays. It is
109
analyzed whether the code tries to add multiple identical, large
data blocks into an array, which is a strong sign for heap
spraying. If so, the strings are not added to the array, which
is why the blocks are not written into memory, leading to a
better runtime performance. At the same time, the heuristic is
triggered and the document is marked as malicious.
3) ShellcodeTester: Shellcode commonly downloads and
installs malware, or, in the case a malware binary is included
or appended to the PDF document, constructs an executable
and installs it. Since installing malware is usually the attackers
goal, shellcode is included in virtually every malicious PDF
document. Shellcode, used within malicious JavaScript, can
either be stored in variables declared in source code or it can be
build at runtime. Both ways, the shellcode is eventually stored
in a string or array variable. Thus, with the ShellcodeTester
heuristic, used variables are observed and tested with the
shellcode detection and analysis library libemu. Shellcode
instructions are commonly encoded using percent-encoding,
whereby, for instance, opcodes 0x90 and 0x90 are given
by the string "%u9090". The unescape method decodes
the percent-encoding string and returns a string only with
the encoded bytes. That is why, the result of the method
unescape is additionally processed by the heuristic.
Since shellcode detection is rather slow, several techniques
were utilized to reduce the amount of strings which need
to be tested. For instance, only strings with length between
reasonable lower and upper bound are tested. In addition,
strings which frequently contain the sequence "%u", are most
likely percent-encoded shellcode instructions, which will be
unescaped later, so these strings are not processed by libemu.
If shellcode is detected in the remaining strings, the doc-
ument is marked as malicious, the shellcode binary is stored
and the libemu profile, which gives the shellcodes API calls,
is saved. With the help of some modifications to libemu,
potentially included malware executables are automatically
saved during the analysis.
V. E VALUATION
To measure the performance of PDF Scrutinizer, especially,
the false positive and false negative rates, sets of malicious
and benign samples were analyzed. The used sets [21] contain
6,054 benign and 11,278 malicious samples, collected from
email attachments and web sites.
For the evaluation, both sets were successively processed by
PDF Scrutinizer, and the results were analyzed. The benign
sample set was mainly utilized, to acquire the false positive
rate, which is an important metric for an automated analysis
tool. Additionally, the performance of PDF Scrutinizer, when
analyzing benign samples was evaluated, which is a crucial
factor for the practial suitability of the tool. When using as a
honeyclient in connection with a web crawler, large amounts
of PDF documents need to be processed, from which likely
most are benign in practise. Thus, the performance, when
analyzing benign PDF documents, has a large impact on the
overall performance. Using the malicious sample set, the false
negative rate of PDF Scrutinizer was evaluated.
 Count Percentage Benign Malicious
Overall samples 6054 100.00 % Amount of Samples 6054 11278
Processed without error 6039 99.75 % Analysis Time 5 min 33 sec 14 hours 2 min
Contained JavaScript actions 229 3.78 % Average Time per Sample 0.06 sec 4.48 sec
Analysis result Average Samples per Minute 1100.73 13.39
Malicious 0 0.00 % Average Throughput 310 MB/min 0,33 MB/min
Suspicious 3 0.05 % TABLE III
Benign 6036 99.70 % A NALYSIS PERFORMANCE
Error 15 0.25 %
TABLE I
A NALYSIS RESULT OF BENIGN SAMPLES

documents could on the one hand be documents which use

Count Percentage
Overall samples 11278 100.00 %
Processed without error 11196 99.27 %
Contained JavaScript actions 10650 97.57 %
Analysis result
Malicious 10125 89.78 % documents, where falsely no code could be extracted. Another
Suspicious 628 5.57 % possibility is that some documents were malformed in a way,
Benign 443 3.93 %
Error 82 0.73 %
TABLE II
A NALYSIS RESULT OF MALICIOUS SAMPLES
In table I the analysis result of the benign sample set is
given. The false-positive rate is zero, which is an optimal
result. Three documents are falsely classified as suspicious,
because they use the vulnerable method doc.getAnnots
in a legitimate manner. Fifteen documents exited with an
error, which equals 0.25 % of the set. These errors are the
result of missing mock objects and the use of the XML Forms
Architecture (XFA), which is currently not emulated in PDF
Scrutinizer. In both cases, the embed JavaScript cannot be
completely executed without errors. JavaScript actions were
found in 3.78 % of the documents. This corresponds to the
observation that harmless documents rarely use JavaScript.
The analysis result of the malicious sample set is shown
in table II. A total of 97.57 % of the malicious documents
contained JavaScript code, which shows that most present ma-
licious PDF documents are utilizing JavaScript-based attacks.
99.27 % of the malicious documents were processed error-
free using PDF Scrutinizer. When processing the malicious
data set, 89.78 % of the containing documents are correctly
classified as malicious. It shows, that the different detection
methods together achieve a high detection rate with the used
samples. From the malicious data set, 628 documents, which
corresponds to 5.57 % of the set, are categorized as suspicious.
The reasons why these documents were not classified as mali-
cious, may be diverse. For example, the contained code could
use mechanisms to detect the emulated analysis environment
and disguise their malicious behavior. It is also conceivable,
that documents use parts of the PDF specification, which are
not correctly emulated. Lastly, errors during the execution
of JavaScript code can lead to a premature ending of the
execution and thus merely to a suspicious classification. The
remaining 3.93 % of the set are classified as benign. These
non-JavaScript-based vulnerabilities, which are at present not
detected by PDF Scrutinizer, and therefore are not correctly
classified. Currently, PDF Scrutinizer has only rudimentary
detection mechanisms for non-JavaScript-based attacks. On the
other hand, false-negative detection results could occur from
that they could not be successfully parsed using PDFBox. It
can not be excluded that the documents were damaged through
a data transfer, as the original source is unknown. Finally, there
is no certainty, that the remaining documents are malicious at
all, until they were examined by hand.
The achieved performance during the evaluation of the two
sets is shown in table III. With the benign sample set, the
average time needed to process one document is 0.06 sec,
which corresponds to about 1100 analyzed documents per
minute. The relative low analysis time comes from the fact
that many benign documents do not contain JavaScript code
that has to be executed, which is a time consuming task. So,
when used within a client honeypot, crawling the web for
malicious PDF document, PDF Scrutinizer can be used to
process large amounts of PDF documents per day. During the
evaluation of the malicious sample set, an average analysis
time of 4.48 sec per sample was observed. From the fact,
that most malicious documents use JavaScript, this shows,
that the need of executing code increases the runtime substan-
tially. Furthermore, malicious documents are often performing
computationally expensive operations as decryption, and the
dynamic heuristics are observing the engine while execution,
which as well lowers the performance. Additionally, shellcode
detection is a time consuming task: about 17 % of the analysis
time was consumed by libemu.
Heuristics
This section provides an evaluation on the implemented
heuristics. It was investigated how often which heuristics were
triggered during the analysis of the documents, which were
classified as malicious. The results are shown in table IV.
The RegexMalicious heuristic, which uses signatures of vul-
nerable methods and parameters, achieved a rate of 82.24 %.
Since obfuscation techniques are commonly used and the
set of regular expressions only contained the amount of six
signatures at the time of analysis, this can be considered a
promising result. By improving the amount and the quality of
the signatures the rate could be further enhanced.

110
 Count Percentage
Malicious classified samples 10125 100.00 %
Heuristic triggered
RegexMalicious 8327 82.24 %
StringLengthTester 8756 86.48 % are high, that PDF Scrutinizer still detects the attack using
HeapSprayDetector 9868 97.46 % dynamic heuristics. This is particularly interesting for using the
ShellcodeTester 7482 73.90 % tool with a client honeypot, because this way, novel exploits
TABLE IV
T RIGGERING FREQUENCY OF THE HEURISTICS
The highest rate is achieved by the HeapSprayDetector
heuristic. This heuristic was triggered by 97.46 % of the
malicious documents, which shows that heap spraying is used
by the major part of malicious PDF documents and that it
can be reliably detected using this heuristic. Excessively long
strings were detected in 86.48 % of the documents, using the
StringLengthTester heuristic. Again, this is a indicator for the
presence of malicious code. In 73.90 % of the documents
in the malicious data set, shellcode was found using the
ShellcodeTester heuristic. The result depends on the quality
of the used shellcode detector and can vary. As shellcode
is included in virtually every malicious document, that uses
JavaScript-based attacks, this rate should be improvable.
In summary it can be said, that the heuristics achieve a high
detection rate within the samples with malicious classification.
This is an indicator, that novel documents, which use yet
unknown vulnerabilities should be reliably detectable using
PDF Scrutinizer, as long as they use the characteristics, which
are observed by these heuristics. Noteworthy is additionally
the low false positive rate and the considerable performance,
that was observed during the evaluation of the benign sample
set.
VI. F UTURE W ORK
A limitation of the emulated approach is, that the analysis
is complicated as soon as malicious document writers start to
use a larger proportion of the JavaScript for Acrobat API. As
emulated environments always differ in some way from the
original, malicious PDF document authors can and will use
such differences to detect simulated systems. Thus, enhancing
the emulation quality is an ongoing process, with the aim to
improve the flawless execution of Acrobat JavaScript and with
that the detection rate of malicious documents.
VII. C ONCLUSION
In this paper, we presented PDF Scrutinizer, a PDF docu-
ment analysis tool, which uses static and dynamic detection
mechanisms to recognise malicious PDF documents. The
attempt to emulate PDF reader’s behavior has proven to
be promising. PDF Scrutinizer showed a detection rate of
about 90 %, whereas false-positive classifications did not occur
during our evaluation.
Since code contained in PDF documents is executed, obfus-
cation techniques, which hinder a reliable static detection, are
overcome. During the execution, details about the behavior are
collected, which make a manual analysis often unnecessary.
111
If a known attack is performed, PDF Scrutinizer can often
recognize the CVE-IDs of the used vulnerabilities. Even if a
document tries to exploit an unknown vulnerability, chances
could be identified at an early stage.
R EFERENCES
[1] K. Selvaraj and N. F. Gutierrez, “The Rise of PDF Malware,” 2010.
[Online]. Available: http://www.symantec.com/content/en/us/enterprise/
media/security response/whitepapers/the rise of pdf malware.pdf
[2] M. Hypponen, “Military Targets,” 2011. [Online]. Available: http:
//www.f-secure.com/weblog/archives/00002203.html
[3] The H security, “Targeted attacks on arms manufacturers continue,”
2011. [Online]. Available: http://www.h-online.com/security/news/item/
Targeted-attacks-on-arms-manufacturers-continue-1283425.html
[4] P. O. Baccas, “Who ordered spam? New trick in PDF malware
uncovered,” 2011. [Online]. Available: http://nakedsecurity.sophos.com/
2011/04/18/orders-spam-new-trick-in-pdf-malware/
[5] E. Balunsat, “How PDF files hide malware Example PDF scan from
Xerox,” 2011. [Online]. Available: http://blog.commtouch.com/cafe/
malware/how-pdf-files-hide-malware-example-pdf-scan-from-xerox/
[6] Avast Software, “Six out of every ten users run vulnerable versions of
Adobe Reader,” 2011. [Online]. Available: http://public.avast.com/mkt/
20110713 6 out of 10 with vulnerable PDF.pdf
[7] M. Sutton, J. Sobrier, M. Geide, P. Kulkarni, and U. Wanve, “State of
the Web - Quarter 2, 2011 Report,” 2011. [Online]. Available: http:
//www.zscaler.com/pdf/Zscaler-Labs-State-of-the-Web-2011Q2.pdf
[8] D. Johnson, “PDF in Government,” 2007. [Online]. Available:
http://www.appligent.com/2007-02-02
[9] Adobe Systems Incorporated, “ISO 32000-1:200. document management
– portable document format – part 1: PDF 1.7,” Tech. Rep., Jul.
2008. [Online]. Available: http://www.adobe.com/devnet/acrobat/pdfs/
PDF32000 2008.pdf
[10] A. Sotirov, “Heap Feng Shui in JavaScript,” 2007.
[Online]. Available: http://www.blackhat.com/presentations/bh-europe-
07/Sotirov/Whitepaper/bh-eu-07-sotirov-WP.pdf
[11] L. Zeltser, “How to Extract Flash Objects from Malicious PDF Files,”
2011. [Online]. Available: http://computer-forensics.sans.org/blog/2011/
05/04/extract-flash-from-malicious-pdf-files
[12] S. Porst, “A brief analysis of a malicious PDF file
which exploits this weeks Flash 0-day,” 2010. [On-
line]. Available: http://blog.zynamics.com/2010/06/09/analyzing-the-
currently-exploited-0-day-for-adobe-reader-and-adobe-flash
[13] G. Delugré, “An approach to PDF shielding,” 2010. [Online].
Available: http://esec-lab.sogeti.com/post/2010/09/01/An-approach-to-
PDF-shielding
[14] University of Californica, Santa Barbara, “Wepawet.” [Online].
Available: http://wepawet.cs.ucsb.edu/
[15] M. Cova, C. Kruegel, and G. Vigna, “Detection and analysis of
drive-by-download attacks and malicious JavaScript code,” 2010.
[Online]. Available: http://www.cs.ucsb.edu/∼vigna/publications/2010
cova kruegel vigna Wepawet.pdf
[16] Z. Tzermias, G. Sykiotakis, M. Polychronakis, and E. P. Markatos,
“Combining static and dynamic analysis for the detection of
malicious documents,” 2011. [Online]. Available: http://www.syssec-
project.eu/media/page-media/3/mdscan-eurosec11.pdf
[17] P. Laskov and N. Šrndić, “Static detection of malicious JavaScript-
bearing PDF documents,” 2011. [Online]. Available: http://doi.acm.org/
10.1145/2076732.2076785
[18] T. A. S. Foundation, “Apache PDFBox - Java PDF Library,” http://
pdfbox.apache.org/.
[19] Mozilla Foundation, “Rhino: JavaScript for Java.” [Online]. Available:
http://www.mozilla.org/rhino/
[20] P. Baecher and M. Koetter, “libemu - x86 Shellcode Emulation.”
[Online]. Available: http://libemu.carnivore.it/
[21] M. Parkour, “Version 4 April 2011 - 11,355+ Malicious
documents - archive for signature testing and research,”
2011. [Online]. Available: http://contagiodump.blogspot.com/2010/08/
malicious-documents-archive-for.html