Didier Stevens

Saturday 7 November 2015

Analysis Of An Office Maldoc With Encrypted Payload: oledump plugin

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

After a quick and dirty analysis and a “slow and clean” analysis of a malicious document, we can integrate the Python decoder function into a plugin: the plugin_dridex.py

First we add function IpkfHKQ2Sd to the plugin. The function uses the array module, so we need to import it (line 30):


Then we can add the IpkfHKQ2Sd function (line 152):


And then we can add function IpkfHKQ2Sd to the list in line 217:


This is the code that tries different decoding functions that take 2 arguments: a secret and a key.

I also added code (from plugin_http_heuristics) to support Chr concatenations:


The result is that the plugin can now extract the URLs from this sample:


oledump_V0_0_19.zip (https)
MD5: DBE32C21C564DB8467D0064A7D4D92BC
SHA256: 7F8DCAA2DE9BB525FB967B7AEB2F9B06AEB5F9D60357D7B3D14DEFCB12FD3F94

Friday 6 November 2015

Analysis Of An Office Maldoc With Encrypted Payload (Slow And Clean)

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

In my previous post we used VBA and Excel to decode the URL and the PE file.

In this  post we will use Python. I translated the VBA decoding function IpkfHKQ2Sd to Python:


Now we can decode the URL using Python:


And also decode the downloaded file with my translate program and the IpkfHKQ2Sd function:




Thursday 5 November 2015

Analysis Of An Office Maldoc With Encrypted Payload (Quick And Dirty)

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

The malicious office document we’re analyzing is a downloader: 0e73d64fbdf6c87935c0cff9e65fa3be

oledump reveals VBA macros in the document, but the plugins are not able to extract a URL:


Let’s use a new plugin that I wrote: plugin_vba_dco. This plugin searches for Declare statements and CreateObject calls:


In the first half of the output (1) we see all lines containing the Declare or CreateObject keyword. In the second half of the output (2) we see all lines containing calls to declared functions or created objects.

Although the code is obfuscated (obfuscation of strings and variable names), the output of this plugin allows us to guess that Ci8J27hf2 is probably a XMLHTTP object, because of the .Open, .send, .Status, … methods and properties.

The Open method of the XMLHTTP object takes 3 parameters: the HTTP method, the URL and a boolean (asynchronous or synchronous call):


As we can see, the third parameter is False and the first 2 parameters are the return value of a function called IpkfHKQ2Sd. This function takes 2 parameters: 2 strings. The first string is the result of concatenated Chr functions, and the second string is a literal string. Since the Open method requires the HTTP method and URL as strings, is very likely that function IpkfHKQ2Sd is a decoding function that takes 2 strings as input (meaningless to us) and returns a meaningful string.

Here is the original IpkfHKQ2Sd function. It’s heavily obfuscated:


Here is the same function that I deobfuscated. I didn’t change the function name, but I removed all useless code, renamed variables and added indentation:


We can now see that this function uses a key (sKey) and XOR operations to decode a secret string (sSecret). And now we can also see that this is just a string manipulation function. It does not contain malicious or dangerous statements or function calls. So it is safe to use in a VBA interpreter, we don’t need to translate it into another language like Python.

We are going to use this deobfuscated function in a new spreadsheet to decode the URL parameter:


In the VBA editor of this new spreadsheet, we have the deobfuscated IpkfHKQ2Sd function and a test subroutine that calls the IpkfHKQ2Sd function with strings that we found in the .Open method for the URL argument. The decoded string returned by function IpkfHKQ2Sd is displayed via MsgBox. Executing this test subroutine reveals the URL:


Downloading this file, we see it’s not a JPEG file, but contrary to what we could expect, it’s neither an EXE file:


Searching for .responseBody in the VBA code, we see that the downloaded file (present in .responseBody) is passed as an argument to function IpkfHKQ2Sd:


This means that the downloaded file is also encoded. It needs to be decoded with the same function as we used for the URL: function IpkfHKQ2Sd (but with another key).

To convert this file with the deobfuscated function in our spreadsheet, we need to load the file in the spreadsheet, decode it, and save the decoded file to disk. This can be done with my FileContainer.xls tool (to be released). First we load the encoded file in the FileContainer:



FileContainer supports file conversion: we have to use command C and push the Process Files button:


Here is the default conversion function Convert. This default function doesn’t change the file: the output is equal to the input:


To decode the file, we need to update the Convert function to call the decoding function IpkfHKQ2Sd with the right key. Like this:


And then, when we convert the file, we obtain an EXE file:


This EXE turns out to be Dridex malware: 50E3407557500FCD0D81BB6E3B026404

Remark: reusing code from malware is dangerous unless we know exactly what the code does. To decode the downloaded file quickly, we reused the decoding VBA function IpkfHKQ2Sd (I did not translate it into another language like Python). But to be sure it was not malicious, I deobfuscated it first. The deobfuscation process gave me the opportunity to look at each individual statement, thereby giving me insight into the code and come to the conclusion that this function is not dangerous. We could also have used the obfuscated function, but then we ran the risk that malware would execute because we did not fully understand what the obfuscated function did.

Translating the obfuscating function to another language doesn’t make it less dangerous, but it allows us to execute it in a non-Windows environment (like Linux), thereby preventing Windows malware from executing.

Monday 21 September 2015

PDF + DOC + VBAs Videos

Filed under: Malware,PDF — Didier Stevens @ 10:46

I produced videos showing how I created my “Test File: PDF With Embedded DOC Dropping EICAR” and how to change the settings in Adobe Reader to mitigate this.

Thursday 13 August 2015

Update: pdf-parser Version 0.6.4

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

In this new version of pdf-parser, option -H will now also calculate the MD5 hashes of the unfiltered and filtered stream of selected objects, and also dump the first 16 bytes. I needed this to analyze a malicious PDF that embeds a .docm file.


As you can see in this screenshot, the embedded file is a ZIP file (PK). .docm files are actually ZIP files.

pdf-parser_V0_6_4.zip (https)
MD5: 47A4C70AA281E1E80A816371249DCBD6
SHA256: EC8E64E3A74FCCDB7828B8ECC07A2C33B701052D52C43C549115DDCD6F0F02FE

Wednesday 8 April 2015

Quickpost: Maldocs: VBA And Pastebin

Filed under: Malware — Didier Stevens @ 20:24

Since a day or two I’m seeing yet another trick used by malware authors in their VBA macros.

The sample I’m looking at is 26B857A0A57B89166584CBB7167CAA19.

The VBA macro downloads base64 encoded scripts from Pastebin:



The scripts are delimited by HTML-like tags like <text10>. Tags that start with stext are scripts for Windows XP systems, and tags that start with text are for Windows Vista and later. This difference is for Powershell: on XP, VBS scripts are executed, and on more recent systems, Powershell scripts are executed.

The URL of the payload comes from another Pastebin entry:


Correct: that trojan is hosted on Dropbox.

Quickpost info

Friday 27 March 2015

oledump And XML With Embedded OLE Object

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

I updated oledump to handle a new type of malicious document: an XML file, not with VBA macros, but with an embedded OLE object that is a VBS file.

And the man page is finished. Run oledump.py -m to view the man page.

The sample I’m using here is 078409755.doc (B28EF236D901A96CFEFF9A70562C9155). The extension is .doc, but it is an XML file, not an OLE file.

First check:


The XML file contains an OLE file with 1 stream.

Let’s take a look inside the stream:


Byte 0x78 could be the start of a ZLIB compressed data stream. Let’s checks this with option –decompress:


It is indeed ZLIB compressed, and the decompressed data seems to be another OLE file (D0 CF 11 E0).

So let’s pipe this decompressed OLE file into a second instance of oledump:


This OLE file contains an embedded object (Ole10Native). Let’s have a look:


It seems to be a .VBS file. Let’s have a look:


So this looks like VB Script with base64 strings. Let’s try to decode them with a plugin:


So now it’s clear what this maldoc does: launch PowerShell, download a file and store it as a .cab file in a temporary folder. Expand the downloaded .cab file to an .exe file, and then launch the .exe file. In other words, it is a downloader.

oledump_V0_0_13.zip (https)
MD5: 6651A674F4981D9AEDE000C1F5895B69
SHA256: 4452DF48F7D852140B4CD662AD95C6BC695F5F04009B37A367EB392384935C51

Tuesday 17 March 2015

Update oledump.py Version 0.0.12

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

This update adds support for metadata and fixes an XML parsing bug.


oledump_V0_0_12.zip (https)
MD5: 0AB5F77A9C0F1FF3E8BE4F675440A875
SHA256: 6F87E65729B5A921079B9E5400F63BE6721673B7AC075D809B643074B47FB8D3

Wednesday 11 March 2015

VBA Maldoc: We Don’t Want No Stinkin Sandbox/Virtual PC

Filed under: Malware — Didier Stevens @ 20:06

Today I got an interesting maldoc sample (77f3949c2130b268bb18061bcb483d16): it will not activate if it runs in a sandboxed or virtualized environment.

The following statements are executed right before the malicious actions begin:

    If IsSandBoxiePresent(1) = True Then End
    If IsAnubisPresent(1) = True Then End
    If IsVirtualPCPresent = True Then End

The presence of SandBoxie can be detected by the successful load of DLL Sbiedll.dll or the presence of string [#] in the Windows’ title. In this sample, the DLL is checked (1).

The presence of Anubis can be detected by checking the serial number of the system drive, checking Windows’ Product ID, checking the name of the application or the user. In this sample, the serial number is checked (1).

The presence of virtualization is detected by enumerating the services\disk and looking for strings “virual”, “vmware” or “vbox”.

With the help of Google, I discovered that the criminals copy/pasted 7 year old code posted on a forum here, here and here. It’s in Spanish, while the Excel document has code page 1251 ANSI Cyrillic.

Monday 9 March 2015

A New Type Of Malicious Document: XML

Filed under: Malware,My Software — Didier Stevens @ 9:08

Since last week we see XML documents being spammed: they are actually Microsoft Word documents with VBA Macros.

I wrote an ISC Diary entry (I’m a SANS ISC Handler now) detailing the internals of these XML files.

oledump is updated to parse these XML documents.

oledump_V0_0_11.zip (https)
MD5: 02AEF764545213E1B1A5895AD0706F78
SHA256: 162EE94B1A4533956EE2CE0CB13ECDF2FF6C18A0597685E690B8524526FD694E

Next Page »

The Rubric Theme. Blog at WordPress.com.


Get every new post delivered to your Inbox.

Join 342 other followers