O-checker: Detection of Malicious Documents through Deviation from File
Format Specifications
Yuhei Otsubo
National Police Agency, Japan
National center of Incident readiness and Strategy for Cybersecurity, Japan
Institute of Information Security, dgs157101@iisec.ac.jp
Hidehiko Tanaka
Institute of Information Security

Mamoru Mimura
JMSDF Command and Staff College
Institute of Information Security
AbstractdǇƉŝĐĂůƐƚƌƵĐƚƵƌĞŽĨĂŵĂůŝĐŝŽƵƐĚŽĐƵŵĞŶƚĨŝůĞdǇƉŝĐĂůĞǆĞĐƵƚŝŽŶƉƌŽĐĞƐƐ

Documents containing executable files are often used intargeted email attacks in Japan. We examine various document formats (Rich Text Format, Compound File Binary and Portable Document Format) for files used intargeted attacks from 2009 to 2012 in Japan. Almost all
the examined document files contain executable files that
ignore the document file format specifications. Therefore, we focus on deviations from file format specifications and examine stealth techniques for hiding executable files. We classify eight anomalous structuresand create a tool named “o-checker” to detect them. Ochecker detects 96.1% of the malicious files used in targeted email attacks in 2013 and 2014. There are far fewer
stealth techniques than vulnerabilities of document processors. Additionally, document file formats are morestable than document processors themselves. Accordingly, we assert that o-checker can continue detecting
malware with a high detection rate for long periods.

DĂůŝĐŝŽƵƐĚŽĐƵŵĞŶƚĨŝůĞKƉĞŶƚŚĞŵĂůŝĐŝŽƵƐĚŽĐƵŵĞŶƚĨŝůĞ1ǆƉůŽŝƚ ĐŽĚĞ^ŚĞůůĐŽĚĞǆƉůŽŝƚĐŽĚĞĞĐŽǇĚŽĐƵŵĞŶƚĨŝůĞ^ŚĞůůĐŽĚĞǆĞĐƵƚĂďůĞĨŝůĞǆĞĐƵƚĂďůĞĨŝůĞĞĐŽǇĚŽĐƵŵĞŶƚĨŝůĞ

Figure 1: Structure and execution process of a malicious
document file.
ture and execution process of a malicious document file.
The left-hand side of Fig. 1 shows a typical structure
for a malicious document file. A malicious document filemainly consists of four parts: exploit code, shell code, an
executable file, and a decoy document file. Exploit code
is a program designed to exploit a document processor
vulnerability. Shell code is a program designed to create an executable file and a decoy document file, and tolaunch the executable file.
The right-hand side of Fig. 1 shows a typical execution
process of a malicious document file. The exploit codeis executed when a malicious document file is opened,leading to execution of the shell code.
Generally, document processors process exploit code,
which targets vulnerabilities in the document processor
itself, but the executable file and decoy document file arerarely processed by document processors. If these files
are processed, the displayed content is garbled, or thesoftware leads to strange behavior. The executable fileis thus present in the stored content, but not displayed tothe user. This mismatch between displayed and storedcontent is the key detection method in o-checker.
O-checker is a tool for detecting malicious document
files. It does not analyze exploit code, shell code, executable files, or decoy documents. Instead, o-checker

Introduction

The threat of targeted email attacks has increased inJapan in recent years. Many Japanese organizations
have received targeted emails, some of which resulted inleaked confidential information. There were many such
incidents in 2015.
In a targeted email attack, an email requests that therecipient open an attached file or click on a hyperlink
in the email body. Over 60% of the attachment files intargeted email attacks occurring in 2014 were document
files [21]. When the attachment file is an executable file,
we can avoid malware by checking the file extension.
However, when the attachment file is a document file,
we cannot determine risk from the file extension alone.
Malicious document files used in targeted email attacks often contain an executable file embedded withina decoy document file. Figure 1 shows a typical struc1

Table 1: Summary of Specimens 1.
Type
Ext.
Num. Avg. Size (KB)
RTF
rtf
98
266.5
CFB
doc
36
252.2
xls
49
180.4
jtd/jtdc
17
268.5
PDF
pdf
164
351.2
Total
364
291.8

Table 3: Rate of each anomalous structure.
Anomalous structures
Num.
Rate
AS1
97 / 9899.0%
AS2
79 / 102 77.5%
AS3
92 / 102 90.2%
99 / 102 97.1%
AS4
AS5
98 / 102 96.1%
AS2, AS3, AS4, or AS5 100 / 102 98.0%
PDF
AS681 / 164 49.4%
AS7
72 / 164 43.9%
AS8104 / 164 63.4%
AS6, AS7, or AS8
163 / 164 99.4%

Type
RTF
CFB

Table 2: Vulnerabilities targeted in 2012 by Specimens 1.
Vulnerability
Num.
Rate
MS09-67
8 / 130
6.2%
MS10-087
31 / 130 23.4%
MS11-021
2 / 130
1.5%
MS12-027
51 / 130 39.2%
APSB09-04
2 / 130
1.5%
APSB10-02
1 / 130
0.8%
APSB10-07
3 / 130
2.3%
APSB10-21
8 / 130
6.2%
APSB11-07
2 / 130
1.5%
APSB11-08 10 / 130 7.7%
APSB11-30
1 / 130
0.8%
APSB12-03
1 / 130
0.8%
APSB12-18 10 / 130 7.7%
APSB12-22
5 / 130
3.8%
None
2 / 130
1.5%

Although there are various vulnerabilities of document
processors [7, 5, 6, 3, 4], the stealth techniques for hiding executable files were simple. In the case of RTF or
CFB files, almost all the positions of the contained executable files were the end of the file. In the case of PDF
files, almost all the positions were the end of the file orthe inside of a stream. On the other hand, the contained
executable files were usually encrypted to avoid detection based on pattern matching. Therefore, we examined
the specimens for deviations from file format specifications. The examination revealed eight anomalous structures (AS).
• RTF: AS1• CFB: AS2, AS3, AS4, and AS5

examines deviation from file format specifications. Ochecker runs quickly and detects malicious document
files containing executable files at a fairly high rate. This
paper describes the detection methods of o-checker andevaluates its effectiveness.

2• PDF: AS6, AS7, and AS8Table 3 shows that we could classify almost all the specimens according to the eight anomalous structures.
The following sections describe the eight anomalous
structures.

Structure of document files

2.1 RTF

We analyzed 364 document files gathered from various
Japanese organizations. These specimens were used intargeted email attacks from 2009 to 2012, and each contained an executable file. We call these 364 specimens
Specimens 1.
Table 1 shows a summary of Specimens 1. The specimens consist of three file formats: Rich Text Format(RTF; rtf files), Compound File Binary (CFB; doc, xls,
or jtd/jtdc files), and Portable Document Format (PDF;
pdf files).
Among Specimens 1, 130 document files were used in2012. Table 2 shows the vulnerabilities targeted by these130 files. The most frequently targeted vulnerability was
MS12-027. The total in the Rate column (rightmost column of Table 2) is more than 100% because some of thespecimens targeted multiple vulnerabilities.

2.1.1 StructureThis section describes an overview of the RTF specification.
RTF, which was developed by Microsoft, is a file format used to display documents [16]. A standard RTF fileconsists only of 7-bit ASCII characters. RTF consists ofcontrol words, control symbols, and groups.
Figure 2 shows an example of RTF code. Braces ({and }) define a group, and groups can be nested. A backslash starts a RTF control code. A valid RTF document
contains a group that starts with the \rtf control code.
The first character of RTF code is {. The end of filemarker (EOF) is }, corresponding to the first {. Document processors usually do not process data after theEOF.
2

{\rtfHello,\par{\b world}!\par}ZŽŽƚ^ƚŽƌĂŐĞ

^ƚŽƌĂŐĞϭ

Figure 2: Example of an RTF file.
2.1.2^ƚƌĞĂŵ^ƚƌĞĂŵ^ƚŽƌĂŐĞϯ

Figure 3: CFB hierarchy.
&ŝůĞůůŽĐĂƚŝŽŶdĂďůĞ

An EOF should be located at the end of the file. However, the RTF files in the specimens often had an EOF in
the middle of the file, after which an executable file wasembedded.

2.2.1^ƚƌĞĂŵ

Anomalous Structures

AS1:Attached data after EOF

2.2^ƚŽƌĂŐĞ Ϯ

CFB
StructureŝƌĞĐƚŽƌǇŶƚƌǇ,ĞĂĚĞƌ

^ƚƌĞĂŵEĂŵĞ͗Ă͘ƚǆƚ^ŝǌĞ͗ϭ͕Ϯϵϲ/ŶĚĞǆ͗ϮͲϮϬ&ŝůĞůůŽĐĂƚŝŽŶdĂďůĞ

ͲϮϭŝƌĞĐƚŽƌǇŶƚƌǇϯϮ^ƚƌĞĂŵϴϯ^ƚƌĞĂŵͲϭϰ&ƌĞĞ^ĞĐƚŽƌ

ϲϱ^ƚƌĞĂŵϳϲ^ƚƌĞĂŵͲϮϳϴ^ƚƌĞĂŵ^ƚƌĞĂŵͲϮThis section describes the CFB specification.
CFB, which was developed by Microsoft, is a structured storage compound file implementation [14], also
known as OLE (Object Linking and Embedding [15]) or
COM (Component Object Model [12]). DOC (used byMicrosoft Word), XLS (used by Microsoft Excel) andPPT (used by Microsoft PowerPoint) files have a CFB
file format. OOXML [10] (DOCX, XLSX, and PPTX)
files are usually zip containers that are encrypted following the CFB file format. JTD and JTDC files too follow
a CFB file format. These are used in the Japanese Word
Processor “Ichitaro,” which is developed by JustSystems.
“Ichitaro” is widely used in Japan, making it a common
target when a vulnerability is found.
A CFB file is a single file that contains a nested hierarchy of storages and streams. Figure 3 shows the CFB
file hierarchy, which is analogous to a file system hierarchy; storages are analogous to directories, and streams
are analogous to files.
Figure 4 shows a CFB structure. A CFB file is divided
into a 512-byte header and equal-length sectors. Subsequent sectors are identified by a 32-bit non-negative integer called the sector number. A stream is divided andstored into sectors.
A group of sectors can form a sector chain, a linked
list of sectors forming a logical byte array. In a sector
chain, a sector number is used to identify the next sector
in the chain. “−1” and “−2” are special sector numbers.
“−1” is used to represent free sectors, and “−2” is used
to represent chain termination. The left side of Fig. 4
shows two sector chains. A sector chain (blue) starts at
sector #2, and ends at sector #8. Another sector chain(red) starts at sector #5, and ends at sector #7.
Sector chains are defined in a FAT (File Allocation Table). DE (Directory Entry) manages the name, size, andWŚǇƐŝĐĂů^ƚƌƵĐƚƵƌĞ

^ĞĐƚŽƌ
EƵŵďĞƌ

^ƚƌĞĂŵEĂŵĞ͗ď͘ƚǆƚ^ŝǌĞ͗ϭ͕ϰϱϲ/ŶĚĞǆ͗ϱ^ƚŽƌĂŐĞEĂŵĞ͗ƌŽŽƚ^ŝǌĞ͗Ͳ /ŶĚĞǆ͗Ͳ^ĞĐƚŽƌ

Figure 4: CFB structure.
parent-child relation of each stream or storage. The position of the FAT and the DE are defined in the header.
2.2.2 Anomalous Structures
AS2: Anomalous file size
The file size should equal 512 (the header size) plus a
multiple of the sector size. We define Sizefile as the filesize and Sizesector as the sector size. The following equation should thus hold:(Sizefile − 512) mod Sizesector = 0.

(1)

In the CFB files in the specimens, the size of the embedded executable file rarely equals a multiple of the sector size, because the executable file is forcibly includedin the CFB file. Therefore, Eq. (1) is usually not established.
AS3: Data not referenced by the FAT
As we mentioned, sector numbers are 32-bit (4-byte)
non-negative integers. Therefore, one sector corresponding to the FAT can manage Sizesector ÷ 4 sectors. We
define CountFAT as the number of sectors corresponding
to the FAT and SizeFAT as the maximum size of sectors
managed by the FAT. The SizeFAT is obtained by the following equation:
SizeFAT = CountFAT × Sizesector ÷ 4.
3(2)

&dƐĞĐƚŽƌ
ĐŚĂŝŶ,ĞĂĚĞƌ

&ƌĞĞƐĞĐƚŽƌƐ

/&dƐĞĐƚŽƌ
ĐŚĂŝŶZŽŽƚƐƚŽƌĂŐĞĚŝƌĞĐƚŽƌǇ
ĞŶƚƌǇ

ŵŝŶŝ&dƐĞĐƚŽƌĐŚĂŝŶ

ŝƌĞĐƚŽƌǇĞŶƚƌŝĞƐ
ĨŽƌƐƚŽƌĂŐĞ

ŝƌĞĐƚŽƌǇƐĞĐƚŽƌĐŚĂŝŶ

ŝƌĞĐƚŽƌǇ
ĞŶƚƌǇĨŽƌƐƚƌĞĂŵ

ŽŵŵĞŶƚ;ŚĞĂĚĞƌͿ%PDF-1.1

ǆĞĐƵƚĂďůĞĨŝůĞ

1 0 objㄾ
5 0 obj^ĞĐƚŽƌĐŚĂŝŶƐĨŽƌƐŵĂůůƐƚƌĞĂŵ

…

endobj…

endobjƌŽƐƐͲƌĞĨĞƌĞŶĐĞƚĂďůĞ

xref
0 5
0000000000 65535 f
0000000012 00000 n
ㄾ
0000000632 00000 n
trailer<<statxref756^ĞĐƚŽƌĐŚĂŝŶƐ
ĨŽƌƐƚƌĞĂŵ

Figure 5: Example of a sector hierarchy.

%%EOF

ŽĚǇ

dƌĂŝůĞƌ
…

>>ŽŵŵĞŶƚ;ĞŶĚŽĨĨŝůĞͿ

Figure 6: Structure of a PDF file.
All sectors are managed by the FAT. Therefore, thedifference between the file size and 512 (the header size)
should be less than or equal to SizeFAT . The following
formula should thus hold:

2.3 PDF
2.3.1 Structure

Sizefile − 512 ≤ SizeFAT .

(3)This section provides an overview of the PDF specification.
PDF, which is developed by Adobe Systems, is a fileformat for document display. The PDF specification was
officially released as an open standard on July 1, 2008,
and is now published by the International Organizationfor Standardization as ISO 32000-1:2008 [9]. Adobe
Systems has extended the PDF specification as part ofits “Adobe Extensions” [1].
A conforming PDF file should be constructed of four
elements (Fig. 6):

In CFB files in the specimens, the executable file
is forcibly included into document files, ignoring FAT
rules, so the file size exceeds SizeFAT and Eq. (3) does
not hold.

AS4: Free sector in the last sector
Free sectors are not generally processed by document
processors, allowing use of free sectors to store hidden
data. Specific locations for free sectors are not defined.
We analyzed various CFB files not containing executable
files, and found no CFB files whose last sector is a freesector, which should be in the middle of a CFB file. In the
CFB files in the specimens, however, last sectors were
free sectors.

• Comments, which have no semantics (except for%PDF-n.m and %%EOF)• A body containing the objects that make up the document contained in the file
• A cross-reference table containing information
about indirect objects in the file
• A trailer giving the location of the cross-referencetable and of certain special objects within the filebodyAS5: Unaccounted-for sectors
A CFB file consists of six sector types, namely FAT, DIFAT (Double-Indirect FAT), miniFAT, DE, stream, andfree sector. The DIFAT manages sectors corresponding
to the FAT. MiniFAT sectors manage streams whose size
is less than a constant size, defined in the header.
A CFB file can be regarded as a hierarchy of sectors(Fig. 5), with the header as the hierarchy root. Generally,
all sectors are located within this sector hierarchy.
We can usually classify sectors according to their type,but in CFB files in the specimens, sectors containing theexecutable file appear outside the hierarchy.

The trailer of a PDF file enables a conforming reader
to quickly find the cross-reference table and certain special objects. The last line of the file should contain only
the end-of-file marker, %%EOF. The two preceding lines
should contain, once per line and in order, the keyword
startxref and the byte offset from the beginning of
the file to the beginning of the xref keyword in the lastcross-reference section. The startxref line should be
preceded by the trailer dictionary, consisting of the keyword trailer.
44 0 obj<</Length 24 /Filter /ASCIIHexDecode>>
stream48656C6C6F2C576F726C6421
endstream
endobjŽĐƵŵĞŶƚĐĂƚĂůŽŐ

ʁKďũĞĐƚ
ʁ>ŝŶŬKƵƚůŝŶĞŚŝĞƌĂƌĐŚǇ

WĂŐĞƚƌĞĞ

Figure 7: Example of an object.

WĂŐĞ

Table 4: Examples of standard filters.
Decodes data encoded in an ASCII baseASCII85
85 representation, reproducing the origiDecodenal binary data.
Decodes data encoded in an ASCII hexASCIIHex
adecimal representation, reproducing the
Decodeoriginal binary data.
Decompresses data encoded using a discrete cosine transform technique based
DCT
on the JPEG standard, reproducing imDecode
age sample data that approximates theoriginal data.
Decompresses data encoded using theFlatezlib/deflate compression method, reproDecodeducing the original text or binary data.
Decompresses data encoded using the
JBIG2
JBIG2 standard, reproducing the original
Decodemonochrome image data.

ŽŶƚĞŶƚƐƚƌĞĂŵ

ŶŶŽƚĂƚŝŽŶƐ

WĂŐĞŽŶƚĞŶƚƐƚƌĞĂŵ

dŚƵŵďŶĂŝůŝŵĂŐĞ

Figure 8: Structure of a PDF document.

ure 8 illustrates the structure of an object hierarchy. At
the root of the hierarchy is the document’s catalog dictionary. Generally, all objects are located within the hierarchy.
Encryption
PDF documents support encryption to protect their contents from unauthorized access. Encryption-related information is stored in a document’s encryption dictionary, which should be the value of the Encrypt entry
in the document’s trailer dictionary. Encryption applies
to most strings and streams in the document. Encryption is not applied to object types such as integers andBoolean values, which are used primarily to convey information about the document’s structure rather than its
content. Leaving these values unencrypted allows accessto the objects within a document.
However, an encrypted file containing object streams
denies access to objects within the object streams. An
object stream is a stream in which a sequence of indirect objects may be stored. The purpose of object
streams is to allow indirect objects other than streams
to be stored more compactly by using the facilities provided by stream compression filters. In an encrypted file(i.e., all object streams are encrypted), strings occurring
anywhere in an object stream should not be separately
encrypted. Therefore, an encrypted object stream denies
access to objects within it.

Objects
A PDF file has nine basic object types: Boolean values,
integer and real numbers, strings, names, arrays, dictionaries, streams, and null objects.
A stream object, like a string object, is a sequenceof bytes. A stream should consist of a dictionary followed by zero or more bytes bracketed between the keywords stream (followed by a newline) and endstream(Fig. 7). One option when reading stream data is to
decode it using a filter to reproduce the original nonencoded data. Whether to do so and which decoding filter or filters to use is specified in the stream dictionary.
The standard filters are summarized in Table 4.
Objects may be labeled so that other objects can referto them. A labeled object is called an indirect object. The
definition of an indirect object in a PDF file consists of
its object number and generation number (separated bywhite space), followed by the value of the object bracketed between the keywords obj and endobj (Fig. 7).

2.3.2 Anomalous Structures
AS6: Unaccounted-for sections

Document Structure

A basic conforming PDF file is constructed of four element types (comment, body, cross-reference table, andtrailer). However, PDF files in the specimens have

A PDF document can be regarded as a hierarchy of objects contained in the body section of the PDF file. Fig5

unaccounted-for sections that are not of any of these fourtypes.

&ŝůĞͲƚǇƉĞĚĞƚĞƌŵŝŶĂƚŝŽŶ
ĨƌŽŵƚŚĞŚĞĂĚĞƌ

Zd&͍

AS7: Unreferenced objects

EK
EK

z^

KƵƚƉƵƚ
͞DĂůŝĐŝŽƵƐ͊͟

&͍

EK

z^

^ϭ
ĚĞƚĞƌŵŝŶĂƚŝŽŶ

PDF documents can be regarded as a hierarchy of objects
contained in the body section of the PDF file. In PDF
files in the specimens, embedded executable files were
camouflaged as an object and forcibly included into the
PDF file, ignoring the hierarchy rules so that they appear
outside the hierarchy.

z^

^dZd

,ĂƐ^ĨĞĂƚƵƌĞƐ͍EKz^^ϮΕ^ϱĚĞƚĞƌŵŝŶĂƚŝŽŶ

z^

W&͍

^ϲΕ^ϴĚĞƚĞƌŵŝŶĂƚŝŽŶ

EKKƵƚƉƵƚ
͞EŽŶĞ͊͟

E

Figure 9: Flow of checking a document file with ochecker.

AS8: Camouflaged stream
Generally, we can decode encoded streams without problems. Additionally, the length of the data processed fordecoding should be equal to the length of the stream data.
In PDF files in the specimens, a stream contains an
executable file, and stream decoding was nonstandard.
The details are as follows.

3 O-checker
We created a tool, “o-checker,” to detect the eight anomalous structures described above. O-checker is a command line program written in Python that needs only one
argument, a target file path.
Figure 9 shows the flow of checking a document filewith o-checker. O-checker reads a file header, determines the file type, and examines each anomalous structure. The details of the detection are as follows.

AS8-1: Camouflaged filter
Filters corresponding to camouflaged streams are sometimes incorrect, causing stream decoding to fail. We suspect the following reason for why the filter was camouflaged by attackers.
Executable files are similar to compressed streams, inthat data entropy is high in both cases. Entropy is commonly associated with the amount of order or disorder.
As a measure of disorder, the higher the entropy is, thegreater the disorder is. A camouflaged stream is thus
hard to distinguish from a compressed stream in termsof entropy. Therefore, a camouflaged filter such as FlateDecode is widely used in Specimens 1.
Streams with a camouflaged filter are usually not processed by document processors. If the software processes the stream, the displayed content gets garbled or
the software runs incorrectly. Therefore, streams withcamouflaged filter often appear outside the PDF hierarchy (see AS7).

3.1 RTF
AS1 determination method
O-checker reads one byte at a time and checks whether
the character signifies an EOF. When there is data after
the EOF, o-checker determines that the document file has
an AS1 feature.

3.2 CFB
AS2 determination method
A sector shift (2 bytes) field is present in the header atfile offset 30. A sector shift specifies the sector size as a
power of 2. This field must be set to 0x0009 (Sizesector =512 bytes) or 0x000C (Sizesector = 4096 bytes). When
Eq. (1) is not satisfied, o-checker determines that the document has an AS2 feature.

AS8-2:Extra data after EOD
Even if a camouflaged stream contains extra data suchas an executable file, the stream can be decoded without problems, in some cases because of an end-of-data(EOD) marker, as follows.
Most filters are defined such that data are self-limited;
they use an encoding scheme that limits the length of datawith an explicit EOD marker. Document processors usually do not process data after the EOD, so most streams
with added extra data can still be decoded without problems. Taking advantage of this feature, however, attackers can add an executable file to the stream.

AS3 determination method
The number of FAT sectors (4 bytes) field is present in
the header at file offset 44. This integer field contains
the number of FAT sectors in the CFB file. We define CountFAT as this value, and calculate SizeFAT using
Eq. (2). When inequality (3) is not satisfied, o-checker
determines that the document has an AS3 feature.
6• CountminiFAT (4 bytes) is present in the header at fileoffset 64.

AS4 determination method
We define the sector number of the last sector of a CFB
file as n. The CFB file should have a 512-byte header
and n + 1 sectors, so the following formula should hold:
Sizefile = 512 + (n + 1) × Sizesector .

• CountDIFAT (4 bytes) is present in the header at fileoffset 72.

(4)

The header has only the sector number (4 bytes) of
the first sector of the DE. CountDE is obtained in threesteps: The first step is reading the 4-byte integer fromthe header at file offset 48. The second step is getting thewhole picture of the DE from the FAT. The final step iscounting sectors comprising the DE.
Obtaining CountStreams is more complex. The firststep is getting the whole picture of the DE, as describedabove. The second step is getting all the stream entries
from the DE. Next, we obtain the number of sectors foreach stream. The final step is calculating the total number of sectors for each stream.
We obtain the number of stream sectors as follows: We
define Sizen as the size of n-th stream and define Countn
as the number of sectors for the n-th stream. The value (4bytes) of Sizen is present in the n-th entry at offset 120.
When Sizen is less than a constant value, the stream isstored as a “root entry” stream, and Countn is “0.” Wedefine the constant value as Sizemini . Sizemini is present
in the header at file offset 56. When Sizen is more thanSizemini , Countn equals Sizen divided by Sizesector androunded up to the nearest integer. Therefore, Countn isexpressed as{0(Sizen < Sizemini )Countn =.
⌈Sizen ÷ Sizesector ⌉ (Sizen ≥ Sizemini )(6)
We obtain Countfree by counting the number of sectors
whose FAT value is −1.
Countreal should equal Countclassified . When a difference between Countreal and Countclassified appears, ochecker determines that the document file has an AS5
feature.

We solve this equation for n. When the FAT value ofn-th sector is −1 (indicating a free sector), o-checker determines that the document file has an AS4 feature.
AS5 determination method
We can detect unaccounted-for sectors by constructing
the hierarchy of sectors, starting from the header. We
then check all sectors to determine whether these sectors
appear in the hierarchy. To maximize o-checker’s speed,
we focus on differences between the number of classified
sectors and that of sectors of the file. When we find adifference, o-checker determines that the document file
has an AS5 feature.
We define Countreal as the number of sectors in the
CFB file. The file size should be 512 bytes (the headersize) plus the sector size multiplied by Countreal . Thus,
the following formula should hold:
Sizefile = 512 + Countreal × Sizesector .

(5)

We solve this equation for Countreal .
We define the following variables:• CountFAT is the number of sectors comprising the
FAT.
• CountminiFAT is the number of sectors comprising
the miniFAT.
• CountDIFAT is the number of sectors comprising the
DIFAT.
• CountDE is the number of sectors comprising the
DE.

3.3

• CountStreams is the number of sectors comprising all
streams.

PDF

AS6 determination does not depend on the condition ofa given PDF file. When a PDF file is encrypted, AS7 andAS8 determination are sometimes not applicable to the
file.
Figure 10 shows the flow of checking a PDF file witho-checker. First, it checks whether the file has an AS6
feature. Next, o-checker checks whether the file is encrypted according to the trailer dictionary. If the file is
not encrypted, o-checker checks whether the file has an
AS7 or AS8 feature.
Generally, encrypted PDF files can be decrypted by
two types of passwords, a user password or an owner
password. When the user password is an empty string,• Countfree is the number of free sectors.
• Countclassified is the number of classified sectors.
The following formula should hold:Countclassified = CountFAT + CountminiFAT + CountDIFAT+CountDE + CountStreams + Countfree .
We can obtain each variable as follows.
• CountFAT (4 bytes) is present in the header at fileoffset 44.
7ŶĐƌǇƉƚĞĚW&͍
EKin the PDF file. Next, o-checker finds all links to indirect objects to search for unreferenced objects. If ochecker finds an unreferenced object whose size exceeds
512 bytes, it determines that the document file has an
AS7 feature.
We exclude small (< 512 bytes) objects from thejudgment process, because these cannot contain an executable file. In Portable Executable (PE) files, the header
consists of an MS-DOS 2.0 Section, unused (null) data,a PE header, and so on [13]. The size of the header is atleast 512 bytes, so we set 512 as the criterion size.

z^

^ϲ
ĚĞƚĞƌŵŝŶĂƚŝŽŶ

^dZd

z^

ĞĐŽĚĂďůĞ
͍
z^

EK

EK

tŝƚŚŽďũĞĐƚƐƚƌĞĂŵ͍EK^ϴĚĞƚĞƌŵŝŶĂƚŝŽŶ
^ϳĚĞƚĞƌŵŝŶĂƚŝŽŶ
E

Figure 10: Flow of checking a PDF file with o-checker.
AS8 determination method

it suppresses prompting for a password when the file isopened. We usually do not mind whether the file is encrypted, because many PDF files are encrypted to avoid
detection based on pattern matching, but using an empty
string as the user password.
If the input file is encrypted, o-checker tries to decrypt the file using an empty string as the user password.
O-checker can currently handle four types of encryption
method, namely 40-bit RC4, 128-bit RC4, 128-bit AES,
and 256-bit AES. When o-checker succeeds in decryption, it checks whether the file has an AS7 or AS8 feature.
When o-checker fails the decryption, it searches forobject streams. If no object stream is present in the file,o-checker checks whether the file has an AS7 feature. If
an object stream is present in the file, evaluation of the
PDF file is finished.
The details of each evaluation method in Fig. 10 are
described below.

O-checker can reveal camouflaged filters that use FlateDecode, ASCIIHexDecode, ASCII85Decode, DCTDecode, or JBIG2Decode. It first tries to decodestreams using FlateDecode, ASCIIHexDecode, andASCII85Decode. If the decoding process fails, ochecker determines that the document file has an AS8
feature.
In the case that a stream uses FlateDecode, DCTDecode, or JBIG2Decode, o-checker searches for extra datain the stream. If there is a difference between the positionof the EOD marker and the position of the last byte of thestream, o-checker determines that the document file has
an AS8 feature.

4

Evaluation

We evaluated o-checker’s effectiveness in three experiments. The following summarizes our experiments:

AS6 determination method• Experiment 1: True positive rate to malicious files
containing an executable file like those used in targeted email attacks

O-checker reads files one byte at a time, classifying themaccording to the following four types:• A comment is a line starting with a % character.

• Experiment 2: False negative rate for benign files• A body consists of indirect objects, bracketed between the keywords obj and endobj.

• Experiment 3: True positive rate for all malicious
files• A cross-reference table is the lines starting from
xref.

Table 5 shows our experimental environment. We runo-checker on a virtual machine. The top of Table 5 shows
specifications of the host machine platform, which consists of a computer with a Core i5-3450 3.1 GHz CPU
and Windows 7 SP1. We run the virtual machine in
VMware Workstation 9. The bottom of Table 5 shows
specifications of the virtual machine platform, a dualcore CPU machine running Windows XP SP3. We used
Python 2.7.6.
The details of the experiments are as follows.

• A trailer is the lines starting from trailer.
When unclassified data is present in the file, o-checker
determines that the document file has an AS6 feature.
AS7 determination method
O-checker constructs a hierarchy of indirect objects forthe body section of the PDF file to search for unreferenced objects. First, o-checker reads all indirect objects
8

Table 5: Experimental environment.
CPUCore i5-3450 3.1 GHz
Memory8.0 GB
Windows 7 SP1
OS
Virtualization software VMware Workstation 9
Memory (VM)
512 MBOS (VM)
Windows XP SP3
Interpreter (VM)
Python 2.7.6

Type
RTF
CFB

PDF
Total

4.1

Table 7: Vulnerability used by Specimens 2.
Vulnerability
Num.
Rate
MS10-087
2 / 127
1.6%
MS12-027
71 / 127 55.9%
MS14-017
3 / 127
2.4%
JS1300315 / 127 11.8%
JS1400319 / 127 15.0%
APSB10-21
4 / 127
3.2%
APSB11-08
4 / 127
3.2%
APSB11-30
4 / 127
3.2%
APSB12-22
1 / 127
0.8%
APSB13-07
3 / 127
2.4%
None
3 / 127
2.4%
Unknown
6 / 127
4.7%

Table 6: Summary of Specimens 2.
Ext. Num. Avg. Size (KB) Camouflaged
rtf
44
554.1
40
doc
35
193.8
2
xls
15
277.3
0
pps
1
1210.0
0
25
437.0
0
jtd
pdf
7
753.0
0
127
415.2
42

Table 8: TPR of o-checker against Specimens 2.
Type Ext. Detection
TPR
Avg. TimeRTF
rtf
41 / 4493.2%
0.226 s
CFB doc
34 / 3597.1%
0.170 sxls
15 / 15100.0%
0.184 spps
0/1
0%0.171 sjtd
25 / 25100.0%
0.194 s
PDF pdf
7/7
100.0%
1.382 sTotal
122 / 12796.1%
0.263 sExperiment 1

Experiment 1 evaluates o-checker’s true positive rate(TPR) for document files containing an executable file.
We classified the eight anomalous structures fromSpecimens 1. We obtained targeted emails that various Japanese organizations received in 2013 and 2014.
We mechanically extracted the document files from theseemails, classifying them according to the file name. Andremoved duplicate files as identified by hash key. We
confirmed that each specimen contains an executable file.
This resulted in 127 specimens, which we call “Specimens 2.”
Table 6 summarizes Specimens 2. The extensions of
the specimens are sometimes camouflaged, so we classified specimens according to their header. The “pps” file
type is associated with Microsoft PowerPoint.
Table 7 shows the vulnerabilities exploited by Specimens 2. The most exploited vulnerability is MS12027, and 23 specimens exploited a zero-day vulnerability, meaning a software vulnerability that is unknown tothe vendor. The total for the Rates column (right sideof Table 7) is more than 100% because some specimens
exploited multiple vulnerabilities.
We input the specimens to o-checker, then calculated
TPR and measured the running time. Additionally, we
compared the ability of o-checker with three popular
brands of anti-virus software. Most anti-virus software
can detect well-known malware by updating a patternfile. We wished to evaluate the TPR of anti-virus software against unknown malware, so we updated anti-virus
software every day and performed evaluations immediately after obtaining the specimens.

ResultTable 8 shows the TPR of o-checker against Specimens 2. The “Detection” column in this table shows thenumber of detected files divided by the number of specimens. O-checker could detect 96.1% of all specimens.
Table 9 shows the results of comparison with popularanti-virus software. The “Detection” column in this table
is the same as that in Table 8. None of the popular antivirus software could detect even half of the specimens.
Detection characteristics varied for each anti-virus software. A combination of all three could detect only 50.4%of the specimens.

Table 9: Comparing TPR with anti-virus software.
detectionTPRo-checker
122 / 127 96.1%
46 / 127 36.2%
T’s AV
S’s AV30 / 127 23.6%
23 / 127 18.1%
M’s AV
T&S&M’s AV 64 / 127 50.4%

9

Table 10: Summary of Specimens 3.
Type Ext. Num. Avg. Size (KB)
RTF
rtf
199
516.2
CFB doc
1,195
106.1
xls
298
191.7
PDF pdf
9,109
101.7
Total
10,801
112.3

Table 12: Summary of Specimens 4.
Type Ext. Num. Avg. Size (KB)
RTF
rtf
69
487.7
CFB doc
61
259.0
xls
9
298.4
ppt
2
480.5
PDF pdf
86
653.5
Total
227
481.5

Table 11: FPR of o-checker against Specimens 3.
Type Ext.
Detection
FPR
RTF
rtf
0 / 199
0.0%
CFB doc
2 / 1,195
0.2%
xls
14 / 298
4.7%
PDF pdf
19 / 9,109 0.2%
Total
35 / 10,801 0.3%

4.2

EK

KͲĐŚĞĐŬĞƌ
ĚĞƚĞĐƚĞĚ͍

EKKD^ĚĞƚĞĐƚĞĚ͍

EKKƵƚƉƵƚ
͞EŽŶĞ͊͟z^z^KƵƚƉƵƚ
͞DĂůŝĐŝŽƵƐ͊͟

E

Figure 11: Flow of o-checker combined with OMS.

Experiment 2

Experiment 2 evaluates o-checker’s false positive rate
(FPR) against benign document files.
We prepared 10,801 specimens from a web site, “Contagio” [17]. Contagio distributes benign files for signature testing and research from various open sources.
Some of the specimens for some reason had added
HTML data in their headers, so we removed files witha mismatch between the file extension and the header.
These processed specimens are denoted as Specimens 3.
Table 10 summarizes Specimens 3.
We scanned these specimens using o-checker. Wheno-checker detected anomalous structures, we defined thedetection as a false positive.

obtained specimens from the search results. We classified specimens according to the file content in the samemanner as Experiment 1.
We scanned the specimens using o-checker, then calculated the resulting TPR. We did not measure the TPRof anti-virus software for the following reason. VirusTotal recorded these specimens, and after several months
we obtained them. Because we updated anti-virus software every day, anti-virus software detected almost all
anomalous structures in Specimens 4. Thus, we could
not obtain the TPR of anti-virus software against unknown malware.

Results

We compared the ability of o-checker with OfficeMalScanner [2] (OMS) v0.58 in place of anti-virus software. OMS mainly scans files for generic shell code
patterns. OMS can scan both CFB and RTF files. For
CFB files, we used OfficeMalScanner.exe with the
SCAN and BRUTE options. For RTF files, we used the
RTFScan.exe tool included in OMS with the SCAN option, which scans a target file for generic shell code patterns, an embedded CFB signature, or an embedded executable file. The BRUTE feature scans for an encrypted
CFB signature or an encrypted executable file.

Table 11 shows the FPR of o-checker against Specimens 3. The FPR against all the specimens is 0.3%.
However, note that the FPR against xls files in the specimens is a relatively high 4.7%.

4.3

z^

^dZd

Experiment 3

Experiment 3 evaluates o-checker’s detection rate against
malicious document files. We prepared 227 specimens
for Experiment 3, denoted as Specimens 4. Table 12
summarizes Specimens 4. Some of Specimens 4 do notcontain executable files, unlike the files used in Experiment 1.
We obtained Specimens 4 from VirusTotal [22]. The
search conditions specified files that exploit a CVE vulnerability, were obtained in 2013 or 2014, and have a fileextension of rtf, doc, xls, ppt, or pdf. We mechanicallyWe also examined the ability of o-checker combinedwith OMS. Figure 11 shows the flow of combined detection. In short, when o-checker or OMS detects a file, thismethod determines that the file is malicious. Because
OMS does not support PDF files, we excluded PDF files
from Specimens 4. Specimens 5 denotes these excluded
specimens.
10sulting document file has no anomalous structures, so ochecker cannot detect any anomalies.
However, execution of the embedded file requires
manual operations such as a double-clicking the OLE object and verifying a warning dialog. These operations reduce the success rate of targeted attacks, so it is rare that
executable files are embedded into document files by thismethod.

Table 13: TPR of o-checker and OMS against Specimens 4.
Type Ext. o-checker
OMS
RTF
rtf
34 / 69
12 / 69
CFB doc
44 / 61
31 / 61
xls
2/9
3/9
ppt
0/2
0/2
PDF pdf
40 / 86
Total
120 / 227 46 / 141
TPR
52.9%
32.6%

5.1.2 Embedding into shell code
Generally, exploit code needs to be processed by document processors to exploit vulnerabilities in them. In
other words, most of the exploit code is present in document files according to the specification. In addition,
most exploit codes contain the entirety of the shell code.
When an executable file is embedded into a large shellcode, the document file does not have the anomalous
structures we described, so o-checker rarely detects thiskind of file.
However, the possible size of shell code is often limited, in turn limiting embedded executable files to evensmaller sizes. Thus, executable files are rarely embedded in shell codes.

Table 14: TPR of o-checker combined with OMS against
Specimens 5.
Type Ext. o-checker
OMS
Combination
RTF
rtf
34 / 69
12 / 69
39 / 69
CFB doc
44 / 61
31 / 61
51 / 61
xls
2/9
3/9
5/9
ppt
0/2
0/2
0/2
Total
80 / 141
46 / 141
95 / 141
TPR
56.7%
32.6%
67.3%

Results
Table 13 shows the TPR of o-checker and OMS,
with the “OMS” column showing detection by
OfficeMalScanner.exe or RTFScan.exe.
The
TPR of o-checker is 52.9%, and that of OMS is 32.6%.
Table 14 shows the TPR of o-checker combined with
OMS against Specimens 5. The “Combination” column
in this table shows detection by o-checker or OMS. The
TPR of o-checker alone is 56.7%, and the combination
increases the TPR to 67.3%.

5.1.3 Camouflaged Stream in a CFB file
When a stream in a CFB file contains an executable file,
the CFB file has none of the anomalous structures described above. Thus, o-checker cannot detect anomalous
structures in the CFB file.
If document processors process the stream, the displayed content is garbled, or the software leads to strange
behavior. In this case, we can predict that the stream appears outside the hierarchy of streams, like an AS7 feature in a PDF file. We expect that we can detect anomalous structures in a CFB file by searching for unreferenced streams, like the AS7 determination method.
Additionally, there are many parse tools for PDF files,
but relatively few for CFB files. Attackers need to learn
the specifications of the CFB format to embed a stream
containing an executable file into a CFB file. In the caseof CFB files, it is rare that executable files are camouflaged as streams.

5 Discussion
5.1 Analysis of detection leakage for Specimens 2
In Experiment 1, o-checker could not detect five specimens in Specimens 2. We analyzed these specimens witha focus on how the executable file was embedded. The
results revealed three methods by which detection by ochecker was avoided. The details of these methods follow.

5.2 False positives in Experiment 2
O-checker generated false positives for 35 benign files
in Experiment 2. We analyzed these files with a focus
on deviations from file format specifications. As the result, we can classify these false positives into three types:
data corruption, injection of extra data, and benign unreferenced objects. The details follow.

5.1.1 Embedding by document processors
We can embed any executable file into a document fileusing document processors by transforming the executable file into an OLE object and including it into the
document file according to the specification. The re11

5.2.1

files are almost always forced into document files, ignoring the specification. These document files have theanomalous structures we mentioned, and we can detect
these files.
There are far fewer stealth techniques for hiding executable files than vulnerabilities of document processors.
Additionally, the pace of transition of document file format specifications is much slower than that of document
processor updates. Accordingly, we assert that o-checker
can continue detecting malware with a fairly high detection rate for fairly long period.

Data corruption

One cause of misdetection is file fragmentation. Fragmented document files violate the specification, creatingsome of the anomalous structures we described.
Document files made by document processors usuallyare not fragmented, because document processors cannot display the contents of the fragmented file. Although
the fragmented file might be a benign file, detecting it asanomaly file may be a good thing from the aspect of data
integrity.
5.2.2

Injection of extra data

5.4 Application of o-checker

Another cause of misdetection is the injection of extra
data at the end of the file. In all cases, the size of extra data was less than 4 KB. The size of executable filesin Specimens 3 was more than ten times this, so we
can likely avoid the misdetection through filtering. The
drawback to this is that attackers might then use an object
that passes the filter.
Then again, files made by document processors usually do not contain extra data. Although a document
file containing extra data might be benign, detecting it
as anomaly file might be a good thing from the aspect ofdata integrity.

Benign unreferenced objects can also result in misdetection. Twelve PDF files in Specimens 3 have unreferenced
objects (AS7), for unknown reasons. These unreferenced
objects are similar to the configuration information of apage of the document. The size of each object was lessthan 4 KB, as in the case of extra data described above,so similar pros and cons of filtering these anomalies holdhere too.

O-checker could detect 96.1% of Specimens 2 without
virus pattern files in Experiment 1. Furthermore, thecheck speed of o-checker was 0.263 sec per file. Filechecks using malware sandbox analysis generally takea few minutes, so o-checker is comparatively fast. If we
combine o-checker with a mail server, we can detect document files containing executable files passing throughthe mail server.
However, malware is not only delivered as document
files containing executable files. Thus, we used ochecker to examine malicious document files recorded
in VirusTotal in Experiment 3, by which we could detect 52.9% of the malicious files. Some of the specimens
have none of the anomalous structures we mentioned.
Therefore, improving detection rates will require combining other methods with o-checker.
In the case of Experiment 3, the detection rate of OMS
was lower than that of o-checker. However, OMS sometimes detected specimens that could not be detected by ochecker. Thus, the detection rate of o-checker combinedwith OMS (67.3%) is higher than the detection rate ofo-checker alone (56.7%).

5.3

5.5 Limitations of o-checker

5.2.3

Containing benign unreferenced object

Long-term detection rate of o-checker

O-checker is file format dependent, and can only examine RTF, CFB, or PDF files. In particular, o-checker
cannot examine Office Open XML (OOXML) [10] files.
However, we have not seen OOXML files containing executable files and exploit code until very recently, for two
reasons.
First, the OOXML specification has a mechanism fordetecting extra files. An OOXML file is a zip container
containing many files. The specification of OOXML defines a “relationship” that describe usages of all the files.
A file without a relationship is considered to be an extra
file, and document processors cannot open an OOXML
file containing extra files such as an executable file.
The second reason is that zip decoders require a large
amount of code. The size of shell code is often limited toWhen we analyzed the document files used in targetedemail attacks from 2009 to 2012, we found eight anomalous structures, and we created o-checker to detect theseanomalous structure. When we checked malicious document files used in targeted email attacks in 2013 and2014 with o-checker, we could detect these files with afairly high rate.
Generally, the structures of document files are complex, so decoders that export data from a valid document
file are also complex. In turn, a document file containing
an executable file according to the document specification will often have complex shell code. When the sizeof shell code is limited, the shell code cannot contain an
executable file, and furthermore the decoder contained in
the shell code must have simple code. Thus, executable12

a small size, so zip decoders embedded within shell codeare quite rare.
For these reasons, we have obtained OOXML files
containing executable files only very recently, the first
appearing in 2015. This example exploited a vulnerability in Microsoft Office via an EPS (encapsulatedPostscript) file containing an executable file. Shouldsuch approaches gain popularity, we should consider
strategies for scanning OOXML files.

We conducted a static analysis, examined only document
files without running embedded executable files. Indeed,
we did not consider executable files at all, instead focusing only on document specifications. References [19]and [18] are previous studies by the authors relevant tothis paper. Below is an overview of other related works.

we use Hyukdon’s tool to detect malicious CFB files, thetool would return many false positives.
Our method distinguishes between benign free sectors
and those containing an executable file, resulting in the
low FPR of o-checker.
Xu et al. [23] and Srndic et al. [20] applied machinelearning to detecting malicious PDF files, the former focusing on filters and the latter on document hierarchy.
These methods can detect malicious PDF files not containing an executable file. Because these methods use
a supervised learning model, they require samples forlearning and the detection rate of these methods depends
on these samples.
Our methods rarely detect malicious PDF files notcontaining an executable file. However, the document
files used in targeted email attacks in Japan very often
contain an executable file, and our method does not require samples for learning.

6.1

7 Conclusion

6

Related Work

Methods focusing on program codes

Laskov used machine learning to detect malicious PDF
files in a fast scan [11]. The method focuses on
JavaScript in PDF files. Because the method uses a supervised learning model, it needs samples for learningand the detection rate depends on these samples. In contrast, our method does not require learning samples.
Laskov’s method can detect whether a PDF file contains an executable file. However, exploit codes use not
only JavaScript but also Flash, font, and image files.
When searching for exploit code, it is important to consider various types of exploit code. Our method cannot
detect exploits in a document file not containing an executable file, but our method does not depend on the typeof exploit codes.
OfficeMalScanner [2] (OMS) is an analysis tool for
document files. OMS scans entire files for generic shellcode patterns, an embedded CFB signature, or an embedded executable file. However, OMS rarely detects
encrypted shell code or embedded files. This is why thedetection rate of OMS is lower than that of o-checker inExperiment 3. Our method is not affected by encryption,
because it focuses on deviation from file format specifications.

6.2

We proposed a tool for detecting document files containing an executable file. The tool, o-checker, examines document files according to the specification of the
document format. We demonstrated the effectiveness ofo-checker, with the result that it detected 96.1% of malicious specimens at an average rate of 0.263 seconds per
file. There are far fewer stealth techniques for hiding executable files than vulnerabilities of document processors.
Additionally, the pace of changes in document file format
specifications is quite slower than that of document processor updates. Accordingly, we feel that o-checker cancontinue detecting malware with a fairly high detection
rate for relatively long times.
Evaluation of the universal effectiveness of o-checker
is a future task. O-checker could detect document files
used in targeted attacks in Japanese organizations withfairly high detection rates. However, it is not clear that ochecker would be effective in other countries. Therefore,in future studies we will examine malicious document
files obtained from organizations in other countries.

References[1] A DOBE. PDF Reference and Adobe Extensions to the PDF Specification.
http://www.adobe.com/jp/devnet/pdf/pdf_
reference.html.

Methods focusing on document filestructures[2] B OLDEWIN , F.
Analyzing MSOffice malware with OfficeMalScanner.
http://www.reconstructer.org/
papers/Analyzing\%20MSOffice\%20malware\%20with\%20OfficeMalScanner.zip.

Hyukdon suggested a tool for analyzing extra data in a
CFB file [8]. The tool examines four areas of the CFB
file to search for hidden data. The four areas can containfree sectors, so o-checker also examines free sectors. A
document file containing extra data might be malicious,
but benign CFB files often contains free sectors. Thus, if[3] CVE D ETAILS.
Adobe Acrobat Reader :CVEsecurity vulnerabilities,
versions and detailed reports.
http://www.cvedetails.com/product/497/
Adobe-Acrobat-Reader.html?vendor_id=53.

13

> python o-checker.py malware.doc
Malicious!

[4] CVE D ETAILS.
Adobe Flash Player :CVE security vulnerabilities,
versions and detailed reports.
https://www.cvedetails.com/product/6761/
Adobe-Flash-Player.html?vendor_id=53.
[5] CVE D ETAILS. Microsoft Excel : CVE security vulnerabilities,
versions and detailed reports. https://www.cvedetails.
com/product/410/Microsoft-Excel.html?vendor_id=
26.
[6] CVE D ETAILS.
Microsoft Powerpoint :CVE security vulnerabilities,
versions and detailed reports.
https://www.cvedetails.com/product/623/
Microsoft-Powerpoint.html?vendor_id=26.
[7] CVE D ETAILS. Microsoft Word : CVE security vulnerabilities, versions and detailed reports. https://www.cvedetails.
com/product/529/Microsoft-Word.html?vendor_id=26.
[8] H YUKDON , K., Y EOG , K., S ANGJIN , L., AND J ONGIN , L. A
tool for the detection of hidden data in microsoft compound document file format. 08 Proceedings of the 2008 International Conference on Information Science and Security. 2008, pp. 141–146.
[9] ISO.
ISO 32000-1:2008 Document management Portable document format - Part 1：PDF1.7.
http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail.htm?csnumber=51502.
[10] ISO. ISO/IEC 29500:2012:Information technology – Document
description and processing languages – Office Open XML File
Formats, 2012.
[11] L ASKOV, P., AND S RNDIC , N. Static detection of malicious
javascript-bearing pdf documents. In ACSAC (2011), ACM,
pp. 373–382.
[12] M ICROSOFT. Component Object Model (COM). https://
msdn.microsoft.com/en-us/library/ms680573.aspx.
[13] M ICROSOFT.
Microsoft PE and COFF Specification.
https://msdn.microsoft.com/en-us/windows/
hardware/gg463119.aspx.
[14] M ICROSOFT.
[MS-CFB]: Compound File Binary File
Format. https://msdn.microsoft.com/ja-jp/library/
dd942138.aspx.
[15] M ICROSOFT. [MS-OLEDS]: Object Linking and Embedding(OLE) Data Structures.
https://msdn.microsoft.com/
en-us/library/dd942265.aspx.
[16] M ICROSOFT. Rich Text Format (RTF) Specification, version 1.9.1. http://www.microsoft.com/en-us/download/
details.aspx?id=10725.
[17] M ILA , P. 16,800 clean and 11,960 malicious files for signature
testing and research. http://contagiodump.blogspot.jp/
2013/03/16800-clean-and-11960-malicious-files.
html.
[18] OTSUBO , Y., M IMURA , M., AND TANAKA , H. Applying filestructure inspection to detecting malicious pdf files. Information
Processing Society of Japan (IPSJ) Journal 55, 10 (oct 2014),
2281–2289.
[19] OTSUBO , Y., M IMURA , M., AND TANAKA , H. Methods to detect malicious ms document file using file structure inspection.
Information Processing Society of Japan (IPSJ) Journal 55, 5(may 2014), 1530–1540.
[20] S RNDIC , N., AND L ASKOV, P. Detection of malicious pdf files
based on hierarchical document structure. In NDSS (2013), The
Internet Society.
[21] T REND
M ICRO.
Targeted
AttackCampaigns
and Trends:
2014 Annual Report.
http://www.trendmicro.com/cloud-content/us/
pdfs/security-intelligence/reports/
rpt-targeted-attack-trends-annual-2014-report.
pdf.

Figure 12: Example of o-checker input and output.
[22] V IRUS T OTAL. Virustotal. https://www.virustotal.com/.
[23] X U , W., WANG , X., Z HANG , Y., AND X IE , H. A fast and precise malicious pdf filter. Proceedings of the 22nd Virus BulletinInternational Conference. 2012, pp. 14–19.

Appendix
A The usage manual of o-checker
This section briefly describes how to use o-checker.

A.1 How to install o-checker
O-checker is available from Black Hat USA 2016 website.
The requirements for using o-checker are as follows:• Python 2.7.3 or later• An OS that can run Python• The PyCrypto package for Python (for encrypted
PDF files)

A.2 The basic usage of o-checker
In normal use, the path to a target file is the only parameter passed to o-checker.py. Figure 12 shows an example of o-checker input and output. In this case, we rano-checker.py against a malicious Microsoft doc file,which results in the Malicious! output. When the document file does not have any of the targeted anomalous
structures, the output is None!.

A.3 Advanced usage of o-checker
O-checker is not only a detection tool but also an analysis
tool that can describe the detailed structure of CFB or
PDF document files. The details of usage are as follows.
A.3.1 Analyzing CFB files
O-checker contains msanalysis.py for analyzing CFB
files. msanalysis.py scans a CFB file, and it outputs analysis logs describing the final determination of
Malicious! or None!.
Figure 13 shows an example of output ofmsanalysis.py against a malicious doc file withthe judgement option (-j). The result of the checkis shown in Fig. 13 as Malicious!. The following
describes the tool output:
14

> python msanalysis.py -j malware.doc
Compound File
1536
This is DocFile
Size of a sector: 512
Size of a short-sector: 64
Total number of sectors: 1
SecID of first sector of the dictionary stream 17
Minimum size of standard stream 4096
SecID of first sector of ssat 19
Total number of short-sectors: 1
0 Root Entry 20 stream size: 8064 composed size: 8192
1 U:Data 8 stream size: 4096 composed size: 4096
2 U:WordDocument 0 stream size: 4096 composed size: 4096.
.
.
18 Empty -2 stream size: 0 composed size: 0
19 U:CompObj 124 stream size: 121 composed size: 128
suspicious file size!
00008800-000089FF:unused
00008A00-00008BFF:unused.
.
.
0000FE00-0000FFFF:unused
00010000-000101FF:unused
suspicious unused sector!
file size: 140218
file size error!
header size: 1536
total composed size: 28672
Dictionary Stream size: 2560
unused sector 31232
unknown data: 107450
Null block size: 15360> python pdfanalysis.py -j malware.pdf
00000000-00000008:comment,
00000009-000006E2:obj 1 0 xref from [(8 0 R)]
000006E3-00000721:obj 2 0 xref from [(3 0 R), (8 0 R)]
00000722-0000075E:obj 3 0 xref from [(2 0 R), (4 0 R)]
0000075F-0000083F:obj 4 0 xref from [(3 0 R)]
00000840-000008D9:obj 5 0 xref from [(4 0 R), (6 0 R)]
000008DA-0000090E:obj 6 0 xref from [(5 0 R), (7 0 R)]
0000090F-0000098B:obj 7 0 xref from [(-1 -1 R)]
0000098C-000009DA:obj 8 0 xref from [(7 0 R)]
000009DB-00010E04:obj 17 0 xref from None Suspicious
00010E05-00010E09:xref
00010E0A-00010E28:trailer
00010E29-00010E38:startxref 000039AD
00010E39-00010E3D:EOF,
obj 1 0 xml form
obj 17 0 zlib decompress error
Malicious!
run time: 0.133231163025 sec

Figure 14: Example of pdfanalysis.py input and output.
judgement option (-j). The result of the check is shownin Fig. 14 as Malicious!. The following describes thetool output:• This PDF file contains nine indirect objects (Nos. 1–
8 and 17).

Suspicious 2
Malicious!
run time: 0.0584909915924 sec• The indirect object references are listed (e.g., No. 8
refers to No. 1).

Figure 13: Example of msanalysis.py input and output.

• No. 17 is an unreferenced object. (AS7)• No. 1 is an XML form. (Unrelated to determination)• This doc file contains 20 directory entries (Nos. 0–
19).

• No. 17 is a stream requiring the FlateDecode filter,but the decode process for No. 17 fails. (AS8-1)• There is data (at file offset 0x8800 to 0x101FF) notreferred to in the FAT. (AS3)This PDF file has AS7 and AS8-1 features. This suggeststhat object No. 17 (located at offset 0x9DB) in this PDF
file contains an executable file.

• Suspicious unused sector means the last sector is a free sector. (AS4)

Analyzing encrypted PDF file

• The file size is 140,218 bytes. 140218 mod 512 =
442 (nonzero). File size error! means the filesize is anomalous. (AS2)O-checker can handle four types of encryption methods,
namely 40-bit RC4, 128-bit RC4, 128-bit AES, and 256bit AES. When the specified PDF file is encrypted, ochecker usually tries to decrypt it using an empty password. If the password is known, you can use the -p option to decrypt the PDF file using a specified password.

• 107,450 bytes of data is unaccounted for. (AS5)
From the above, this doc file has AS2, AS3, AS4, andAS5 features, and an executable file may be present at
file offset 0x8800.

Exporting objects and streams
A.3.2

Analyzing PDF files

You can use the -o or -s options to export an indirect
object from this PDF file for analyzing exploit code.

O-checker contains pdfanalysis.py for analyzing
PDF files. This tool scans a PDF file, and it outputs analysis logs describing the final determination of
Malicious! or None!.
Figure 14 shows an example of output from
pdfanalysis.py against a malicious PDF file with the• The -o option decodes the stream of the specified
object, and outputs the object in JSON format.
• The -s option decodes and outputs the stream of thespecified object.
15

> python pdfanalysis.py -j malware.pdf -s 1<?xml version="1.0" encoding="UTF-8" ?><xdp:xdp xmlns:xdp="http://ns.adobe.com/xdp/"><config xmlns="http://www.xfa.org/schema/xci/1.0/"><present><pdf><version>1.65</version><interactive>1</interactive><linearized>1</linearized></pdf>.
.
.
<ImageField1 xfa:contentType="image/tif" href="">SUkqADggAACQ
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ.
.
.
FQAH/5CQkE0VAAcipwAHuxUAB////5BNFQAHMdcABy8RAAc=</ImageField1></topmostSubform></xfa:data></xfa:datasets>.
.
.

Figure 15: Example of pdfanalysis.py input and output.
Figure 15 shows an example of the command and its
output. In the above, we can find the exploit code in a tiff
image.

16