During recent malware analysis, I had a need to quickly extract overlays from a bunch of PE files. This can be done with this new version: use option “-g o” to get the overlay:
Option -A (rle ASCII dump) is also new.
And option -y (yara) supports regex (#r#) and hexadecimal (#x#) ad-hoc rules.
pecheck-v0_7_6.zip (https)
MD5: C07704E37FB1C18B769BB5336CD2478A
SHA256: 312E730F6DE784808B6E5BE355752803F281F7DC838E4B9C6B3FE924622F47F8
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
Here is an overview of content I published in February:
Blog posts:
YouTube videos:
Videoblog posts:
SANS ISC Diary entries:
Didier Stevens 