Didier Stevens

Wednesday 14 November 2018

Video: Analyzing PowerPoint Maldocs with oledump Plugin plugin_ppt

Filed under: maldoc — Didier Stevens @ 0:00

I produced a video for my blog post “Analyzing PowerPoint Maldocs with oledump Plugin plugin_ppt“:

Thursday 25 October 2018

Analyzing PowerPoint Maldocs with oledump Plugin plugin_ppt

Filed under: maldoc,My Software — Didier Stevens @ 0:00

VBA macros inside a PowerPoint document are not stored directly inside streams, but as records in the “PowerPoint Document” stream. I have a plugin to parse the records of the “PowerPoint Document” stream, but I failed to extract the embedded, compressed OLE file with the macros. Until a recent tweet by @AngeAlbertini brought this up again. On his sample too I failed to extract the compressed OLE file, but then I remembered I had fixed a problem with zlib extraction in pdf-parser.py. Taking this code into plugin_ppt.py fixed the decompression problems.

VBA macros in a PowerPoint document do not appear directly in streams:

Plugin plugin_ppt parses records found in stream “PowerPoint Document”:

Each line represents a record, prefixed by an index generated by the plugin (to easily reference records). Records with a C indicator (like 1 and 435) contain sub-records. Records prefixed with ! contain an embedded object.

Record 441 (RT_ExternalOleObjectStg) interests us because it contains an OLE file with VBA macros.

Plugin option -s can be used to select this record:

Plugin option -a can then be used to do an hex/ascii dump:

The first four bytes are the size, and then follows the zlib compressed OLE file (as indicated by 0x78).

This OLE file can be decompressed and extracted with option -e, but pay attention to use option -q (quiet) so that oledump will only report the output of the plugin, and nothing else. This can then be piped into a second instance of oledump:

And now we can extract the VBA macros:

oledump_V0_0_38.zip (https)
MD5: C1D7F71A390497A516F67D798BA25128
SHA256: 4CADEE69D024E9242CDA0CE3A9C22BCB1CAFF9D5BA2D946519C6B7C18F895B81

Wednesday 24 October 2018

Update: oledump.py Version 0.0.38

Filed under: maldoc,My Software,Update — Didier Stevens @ 0:00

This new version of oledump.py includes a new plugin to extract VBA code from PowerPoint files and an update to plugin plugin_http_heuristics.

plugin_http_heuristics was updated to increase the chance of success for the XOR dictionary attack, triggered by a maldoc sample I analyzed.

Two new options were added: -e and -k.

By default, plugin_http_heuristics searchers for keywords http: and https:. Using option -e, this list is extended with keywords msxml, adodb, shell, c:\, cmd and powershell.

With option -k, the default keyword list is replaced by your own list (using , as separator). Here I look for ftp (which is not present), remark that http is no longer detected:

oledump_V0_0_38.zip (https)
MD5: C1D7F71A390497A516F67D798BA25128
SHA256: 4CADEE69D024E9242CDA0CE3A9C22BCB1CAFF9D5BA2D946519C6B7C18F895B81

Thursday 7 June 2018

Encrypted OOXML Documents

Filed under: Encryption,maldoc — Didier Stevens @ 0:00

The Office Open XML format introduced with MS Office 2007, is essentially composed of XML files stored inside a ZIP container.

When an OOXML file (like a .docx file) is protected with a password for reading, it is encrypted. The encrypted OOXML file is stored inside a Compound File Binary Format file, or what I like to call an OLE file. This is the “old” MS Office file format (like .doc), the default file format used before MS Office 2007.

This is how an encrypted .docx file looks like, when analyzed with oledump:

Stream EncryptedPackage contains the encrypted document, and stream EncryptionInfo contains information necessary to help with the decryption of stream EncryptedPackage.

The structure of stream EncryptedPackage is simple:

First there’s an integer with the size of the encrypted document, followed by the encrypted document. If we decode the binary data for the integer with format-bytes.py, we get the size 11841:

The EncryptionInfo stream starts with binary data, the version format, and is then followed by more binary data, or XML data, depending on the version:

The first bytes specify the major and minor version used for the EncryptionInfo stream. This example is mostly XML:

Which can be further parsed with xmldump.py:

To help identifying what version is used, I developed an oledump plugin named plugin_office_crypto:

Depending on the version, different tools can be used to decrypt office documents.

Python program msoffcrypto-tool can only decrypt agile encryption (for the moment, it’s a work in progress).

C program msoffice-crypt can decrypt standard, extended and agile encryption.

 

Sometimes, malicious documents will be encrypted to try to avoid detection. The victim will have to enter the password to open the document. There is one exception though: Excel documents encrypted with password VelvetSweatshop.

 

Thursday 14 December 2017

Update: plugin_biff.py Version 0.0.2 / oledump.py Version 0.0.31

Filed under: maldoc,My Software,Update — Didier Stevens @ 0:00

This is an update to plugin_biff, the oledump plugin to parse the BIFF format (used in .xls files).

New options allow to search for opcodes (-o) and strings/bytes (-f) inside BIFF records:

 

oledump_V0_0_31.zip (https)
MD5: 63B2B5ECE2BC46B937D33A6494F7F6A0
SHA256: D2CF42662897642DF27C863F6C246CE70019EDF03F275354A7A505DCE27632D1

Monday 13 November 2017

WebDAV Traffic To Malicious Sites

Filed under: maldoc — Didier Stevens @ 0:00

If observed WebDAV traffic to malicious sites in the past (in proxy logs), and recently I took some time to take a closer look.

TL;DR: when files are retrieved remotely with the file:// URI scheme on Windows, Windows will fallback to WebDAV when SMB connections can not be established.

I did my tests with 2 Windows 7 VMs on the same subnet, one Windows 7 machine with IIS/WebDAV, and the other Windows 7 machine with Word 2016 and a .docx document with a remote template (template.dotx) (using the file:// URI scheme). The Windows firewall on the IIS machine was configured to block ports 139 and 445.

When the .docx document is opened, Word will retrieve the template:

Here is the URI:

First we see attempts to connect on ports 445 and 139 on the IIS machine (SYN packets):

These come from the “System process”:

There are no packets coming back from the IIS machine (I blocked port 139 and 445), and after almost 30 seconds we see an HTTP request to port 80 on the IIS machine:

This is a WebDAV request, notice the User Agent string “DavClnt”:

This TCP connection originates from the Word process:

And about 3 seconds after this request, we get another WebDAV request:

For this request, the User Agent string is “Microsoft-WebDAV-MiniRedir/6.1.7601”.

This TCP connection originates from the WebClient service:

This service was not started:

The svchost service host process will load and start the WebClient service:

WebClient (WebClnt.dll) is the WebDAV service:

To summarize, when the file:// URI scheme is used in a Word document and SMB connections can not be established, we will see WebDAV requests from:

  1. Word (DavClnt)
  2. WebClient service (Microsoft-WebDAV-MiniRedir/6.1.7601)

I’ve observed the same behavior with Windows 10 (with a different version number for the WebClient User Agent string).

When the document is opened a second time, there is no WebDAV request from Word (1), only requests from the WebClient service (2).

When I stop the WebClient service and reopen the document, there is first a WebDAV request from Word (1) followed by requests from the WebClient service (2).

When I disable the WebClient service and reopen the document, there are no more WebDAV requests at all.

 

Thursday 2 November 2017

Analyzing Metasploit’s Office Maldoc

Filed under: maldoc — Didier Stevens @ 0:00

Metasploit has a module to create Microsoft Word document with macros (.docm): office_word_macro.

Documents generated with this module are not that hard to analyze and detect, because they always use the same VBA code. As I explain in my workshops and trainings, although the “new” Office file format (OOXML) is a ZIP container for XML files, VBA code is still stored inside a binary file (vbaProject.bin) using the “old” file format (Compound File Binary Format, or ole file as I like to call it). This Metasploit module always uses the same vbaProject.bin file (inside the template file), and I explain how to analyze and detect it in this video:

I show YARA rules and ClamAV signatures in this video to detect documents created with this Metasploit module.

Here are the YARA rules:

/*
  Version 0.0.1 2017/08/20
  Source code put in public domain by Didier Stevens, no Copyright
  https://DidierStevens.com
  Use at your own risk

  History:
    2017/08/20: start
*/

import "hash"

rule metasploit_office_word_macro_ID_GUID {

    meta:
        description = "Detect Metasploit's office_word_macro unique GUID"

    strings:
        $ID = "ID=\"{BB64F33D-3617-FA44-AFC9-63F65314A8A3}\""

    condition:
        $ID
}

rule metasploit_office_word_macro_vbaproject_bin_zipped {
    meta:
        description = "Detect .docm files created with Metasploit's office_word_macro exploit"

    strings:
        $a = {776F72642F76626150726F6A6563742E62696EED3B0D7853D775E75D3D0959B6B1640C7120908B4CB04C2421C9B22D3B98EADF86D860B0032421C1FA79C222B2A44A4FD8E4A795B1D3928435AC5D33CAD20E42DAA62DEB489AB07EE9BA8976FB42F3B5DF48D3ED4BBA7531C99666FDBE0E4AB32F69B6C43BF7BD275BFE2350BA}

    condition:
        $a and hash.md5(@a + 19, 5962) == "e5995aba8551f30cc15c87ee49fb834a"
}

The first rule (metasploit_office_word_macro_ID_GUID) detects the vbaProject.bin file used by this Metasploit module based on the unique ID ({BB64F33D-3617-FA44-AFC9-63F65314A8A3}) stored inside stream PROJECTwm of file vbaProject.bin. This rule must be used with a tool that can scan inside ZIP files, like zipdump.py or ClamAV.

If you can’t use such a tool, you can still use the second rule (metasploit_office_word_macro_vbaproject_bin_zipped) with the standard YARA scanner: this rule looks for the datastream of the compressed vbaProject.bin file inside Office files.

Here are the ClamAV signatures:

Signature to be put inside a .ndb file:
metasploit_office_word_macro_ID_GUID:0:*:49443D227B42423634463333442D333631372D464134342D414643392D3633463635333134413841337D22
Signature to be put inside a .hdb file:
1788454ae206101fa6febf99005ce03b:15872:metasploit_office_word_macro_vbaproject_bin

The first signature (metasploit_office_word_macro_ID_GUID) detects the unique ID (just like the first YARA rule), and the second signature (metasploit_office_word_macro_vbaproject_bin) detects the vbaProject.bin file based on the MD5 hash (1788454ae206101fa6febf99005ce03b).

ClamAV is able to scan inside OOXML/ZIP files.

Tuesday 31 October 2017

Analyzing A Malicious Document Cleaned By Anti-Virus

Filed under: maldoc,Malware — Didier Stevens @ 0:00

@futex90 shared a sample with me detected by many anti-virus programs on VirusTotal but, according to oledump.py, without VBA macros:

I’ve seen this once before: this is a malicious document that has been cleaned by an anti-virus program. The macros have been disabled by orphaning the streams containing macros, just like when a file is deleted from a filesystem, it’s the index that is deleted but not the content. FYI: olevba will find macros.

Using the raw option, it’s possible to extract the macros:

I was able to find back the original malicious document: f52ea8f238e57e49bfae304bd656ad98 (this sample was analyzed by Talos).

The anti-virus that cleaned this file, just changed 13 bytes in total to orphan the macro streams and change the storage names:

This can be clearly seen using oledir:

 

Monday 31 July 2017

Update: translate.py Version 2.5.0

Filed under: maldoc,My Software,Update — Didier Stevens @ 20:17

I analyzed a malicious document send by a reader of the Internet Storm Center, and to decode the payload I wanted to use my tool translate.py.

But an option was lacking: I had to combine 2 byte streams to result in the decoded payload, while translate will only accept one byte stream (file, stdout, …).

I solved my problem with a small custom Python script, but then I updated translate.py to accept a second file/byte stream (option -2).

This is how I use it to decode the payload:

 

translate_v2_5_0.zip (https)
MD5: 768F895537F977EF858B4D82E0E4387C
SHA256: 5451BF8A58A04547BF1D328FC09EE8B5595C1247518115F439FC720A3436519F

Tuesday 18 July 2017

.ISO Files With Zone.Identifier

Filed under: maldoc,Malware — Didier Stevens @ 22:20

An .iso file downloaded from the Internet (thus with a Zone.Identifier ADS) opened in Windows 10 will not propagate this “mark-of-the-web” to the contained files.

Here is an example with file demo.iso, marked as downloaded from the Internet:

When this file is opened (double-clicked), it is mounted as a drive (E: in this example), and we see the content (a Word document: demo.docx):

This file is not marked as downloaded from the Internet:

Word does not open it in Protected View:

Next Page »

Blog at WordPress.com.