When I’m asked to perform a quick check of an online PDF document, that I expect to be benign, I will just point my PDF tools to the online document. When you provide an URL argument to pdf-parser, it will download the document and perform the analysis (without writing it to disk).
MD5 007de2c71861a3e1e6d70f7fe8f4ce9b is a malicious document: a spreadsheet with Excel 4.0 macros.
Excel 4.0 macros predate VBA macros: they are composed of functions placed inside cells of a macro sheet.
These macros are not stored in dedicated VBA streams, but as BIFF records in the Workbook stream.
Spreadsheets with Excel 4.0 macros can be analyzed with oledump.py and plugin plugin_biff.py.
Option -x of plugin_biff will select all BIFF records relevant for the analysis of Excel 4.0 macros:
In this output, we have all the BIFF records necessary to 1) determine that this is a malicious document and 2) report what this maldoc does.
The first BIFF record, BOUNDSHEET, tells us that the spreadsheet contains a Excel 4.0 macro sheet that is hidden.
The third BIFF LABEL record tells us that there is a cell with name Auto_Open: the macros will execute when the spreadsheet is opened.
And then we have BIFF FORMULA records that tell us that something is CONCATENATEd and EXECuted.
The BIFF STRING record provides us with the exact command (msiexec …) that will be executed.
The latest version of plugin_biff contains much larger lists of tokens and functions used in formula expressions. Of course, it’s still possible that tokens and/or functions are used unknown by my plugin. This is now clearly indicated in the output:
*UNKNOWN FUNCTION* is reported when a function number is unknown. The function number is always reported. Here, for the sake of this example, a crippled version of plugin_biff reports functions with number 0x0037 and 0x0150. In the released version of plugin_biff, functions 0x0037 and 0x0150 are identified as RETURN and CONCATENATE respectively.
*INCOMPLETE FORMULA PARSING* is reported when a formula expression can not be fully parsed. Left of the warning *INCOMPLETE FORMULA PARSING*, the partially parsed expression can be found, and right of the warning, the remaining, unparsed expression is reported as a Python string. If the remainder contains bytes that could be potentially dangerous functions like EXEC, then this is reported too.
The complete analysis of the maldoc is explained in this video:
This version comes with a major update of the BIFF plugin (for Excel files). New features for plugin_biff.py will be discussed in detail in next blog post.
And there are 2 minor changes to oledump itself.
A warning is displayed when an Office file format without macro-support is selected, like .docx files:
In prior versions, no output was produced at all when files like .docx files were processed.
And there’s a bug fix when selecting non-existing streams:
oledump_V0_0_42.zip (https)
MD5: C5CCF18F9F10CB6916CC74C002C78EDE
SHA256: 14A1FDA4AB57B09729AEB2697818782FAE498369A760FEC8AEE5CFB0A0E9D126
In this update, you can also save your library with custom regular expressions in the working directory (in prior versions, it would only take it from the application directory).
Here is an example with a regular expression for MAC addresses:
And there’s a small fix for URL regex: a – character was not considered to be part of the query of a URL.
re-search_V0_0_13.zip (https)
MD5: 241464482856756FF1C0C2386AF84CD5
SHA256: 9409EC639C4C6E988ADFC2401CA89200712BE171894D214B56E4ACC84C32E489
I got hold of a phishing PDF where the /URI is hiding inside a stream object (/ObjStm).
First I start the analysis with pdfid.py:
There is no /URI reported, but remark that the PDF contains 5 stream objects (/ObjStm). These can contain /URIs. In the past, I would search and decompress these stream objects with pdf-parser.py, and then pipe the result through pdfid.py, in order to detect /URIs (or other objects that require further analysis).
Since pdf-parser.py version 0.7.0, I prefer another method: using option -O to let pdf-parser.py extract and parse the objects inside stream objects.
With option -a (here combined with option -O), I can get statistics and keywords just like with pdfid:
Now I can see that there is a /URI inside the PDF (object 43).
Thus I can use option -k to get the value of /URI entries, combined with option -O to look inside stream objects:
And here I have the /URI.
Another method, is to select object 43:
From this output, we also see that object 43 is inside stream object 16.
Remark: if you use option -O on a PDF that does not contain stream objects (/ObjStm), pdf-parser will behave as if you didn’t provide this option. Hence, if you want, you can always use option -O to analyze PDFs.
This is a bug fix version for statistics (-a).
pdf-parser_V0_7_1.zip (https)
MD5: 1480D3BF602686C9E7C2FE82AC6C963B
SHA256: D2C8E0599A84127C36656AA2600F9668A3CB12EF306D28752D6D8AC436A89D1A
This new version of pdf-parser brings support for analysis of stream objects (/ObjStm). Use new option -O to enable this mode.
Stream objects (/ObjStm) are objects that contain other objects: they have a stream, containing other objects. These contained objects can not have a stream.
pdfid.py detects the presence of stream objects:
But pdfid can not look inside a stream, to figure out what objects are inside. That’s why I always say to use pdf-parser to select and decompress stream objects, and then pipe this through pdfid:
When pdf-parser parses a stream object, it does not parse the content of its stream:
This changes with this new version of pdf-parser. When option -O is used, pdf-parser extracts objects from /ObjStm streams and handles them like normal objects. In the following example, object 2 is contained in object 1:
pdf-parser provides statistics for a PDF’s content with option -a:
Combining option -a with option -O includes objects present inside stream objects (this is an alternative for combining both tools: pdf-parser -s objstm -f a.pdf | pdfid -f):
This output shows that /JavaScript can be found in object 7. We need to use option -O to find object 7 “hiding” in object 1:
If we forget to use option -O, object 7 is not found:
Here is a video showing this new feature:
pdf-parser_V0_7_0.zip (https)
MD5: CDE355BB3FCACE3C4EDBC762E632F9AB
SHA256: 219FF0BB729C4478679A79163CA9942296ACF49E4EC06D128CBC53FBEE25FF05
I added function ZlibRawD to translate.py to decompress Zlib compression without header (ZlibD already exists, and is for Zlib compression with header).
This compression is sometimes used in malicious PowerShell scripts:
translate_v2_5_5.zip (https)
MD5: 0BBB0E7E569BCB08D5A9278C974A3EE6
SHA256: 78E0BAC87DF47D06BB9C351FBF3CA623EE10B3993E071E7C9A0C9C4DB0FFF1D4
This is just an update to the cut option (-C), to support UNICODE searches, as shown in blog post “Update: cut-bytes.py Version 0.0.9“.
I show how to use this option in a malicious document analysis video below. If you want to jump straight to the point where I use option -C with a UNICODE string, go to 9:16.
oledump_V0_0_41.zip (https)
MD5: 4FD7E627F5078245705526EBE09D7989
SHA256: 0793CA920DA8B4BD09A040FEE12463BE7D8AF8AE6DFB0968CADCE478BC153CD8
This new version supports searching for UNICODE strings: u’…’.
Example: [u’Programmé’]:0x100l
This will look for UNICODE string “Programmé” and select 256 bytes starting from the first instance of this string.
cut-bytes_V0_0_9.zip (https)
MD5: 3D11868F238AF4369372CA083303716D
SHA256: AB3EA61B0F519AB99E659F73C263A0F4C2C9DB851314C49C5DA5A5F434E0CA4E
Didier Stevens 