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 13 July 2015

Extracting Dyre Configuration From A Process Dump

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

There are a couple of scripts and programs available on the Internet to extract the configuration of the Dyre banking malware from a memory dump. What I’m showing here is a method using a generic regular expression tool I developed (re-search).

Here is the Dyre configuration extracted from the strings found inside the memory dump:


I want to produce a list of the domains found as first item in an <litem> element. re-search is a bit like grep -o, it doesn’t select lines but it selects matches of the provided regular expression. Here I’m looking for tag <litem>:


By default, re-search will process text files line-by-line, like grep. But since the process memory dump is not a text file but a binary file, it’s best not to try to process it line-by-line, but process it in one go. This is done with option -f (fullread).

Next I’m extending my regular expression to include the newline characters following <litem>:


And now I extend it with the domain (remark that the Dyre configuration supports asterisks (*) in the domain names):


If you include a group () in your regular expression, re-search will only output the matched group, and not the complete regex match. So by surrounding the regex for the domain with parentheses, I extract the domains:


This gives me 1632 domains, but many domains appear more than once in the list. I use option -u (unique) to produce a list of unique domain names (683 domains):


Producing a sorted list of domain names is not simple when they have subdomains:


That’s why I have a tool to sort domains by tld first, then domain, then subdomain, …

re-search_V0_0_1.zip (https)
MD5: 5700D814CE5DD5B47F9C09CD819256BD
SHA256: 8CCF0117444A2F28BAEA6281200805A07445E9A061D301CC385965F3D0E8B1AF

Friday 19 April 2013


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

As a thank you to those who nominated me for the European Security Bloggers Awards, I’m going to release some new scripts this week. Here’s the fourth one.

pecheck.py is a wrapper for pefile, but this version has a new feature: check a PE file stored in a (password protected) ZIP file (password infected).

pecheck_v0_3_0.zip (https)
MD5: C2AC9FED3C7F1787854C8D0E651B2591
SHA256: 3CDEBADA4C594DD3622E234747C6AABD41573C94087C0554CBA65D0472F6B413

Monday 15 April 2013

New Tool: XORStrings

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

XORStrings is best described as the combination of my XORSearch tool and the well-known strings command.

XORStrings will search for strings in the (binary) file you provide it, using the same encodings as XORSearch (XOR, ROL, ROT and SHIFT). For every encoding/key, XORStrings will search for strings and report the number of strings found, the average string length and the maximum string length. The report is sorted by the number of strings found, but can also be sorted by the maximum string length (use option -m). By default, the string terminator is 0x00, but you can provide your own with option -t, like the space character (0x20) in this example:


I’ve used XORStrings to identify the encoding used in TeamViewer traffic.

There are more options than the ones I mentioned here. I’ll create a dedicated page for this tool, but for now, I invite you to discover the options yourself.

XORStrings_V0_0_1.zip (https)
MD5: 27DA0B3BC5296179CB58181BDFF99F8D
SHA256: 5EA7E063A41E38E9E6277F1CD73FCEA2AEF50C33C44D75C226900314FF84A1B5

Wednesday 27 March 2013

Cisco IOS Patching: Defense and Offense

Filed under: Forensics,Hacking,Networking,Reverse Engineering — Didier Stevens @ 22:39

I will give a talk on network forensics at my local ISSA chapter.

I’m preparing it with a couple of PoCs.

First PoC is how changing the canary value 0xFD0110DF to another value can provide defense against exploits like FX explained in this paper. I changed the appropriate instructions so that IOS uses canary value OxFC0220CF. You can see it at the bottom of this memory dump:


Second PoC is how I can change the behavior of an IOS command for offensive purposes. Topo mentioned this idea at Black Hat. The verify command checks the embedded MD5 signature in an IOS image. I patched the appropriate instructions so that the verify command always reports a valid signature, regardless of the actual embedded value:


I did not change CCO hash. This is the MD5 hash of the complete IOS image. I did not change this on purpose, but it would be as easy as changing the embedded hash. If you lookup this CCO hash with Cisco, you will not find it.

Wednesday 20 February 2013

Update XORSearch V1.8.0: Shifting

Filed under: My Software,OSX,Reverse Engineering,Update — Didier Stevens @ 21:32

This new version of XORSearch comes with a new operation: shifting left.

It comes in handy to reverse engineer protocols like TeamViewer’s remote access protocol.

Here’s an example. When you run TeamViewer, your machine gets an ID:

20-02-2013 22-11-39

We capture some TeamViewer traffic with Wireshark, and then we use XORSearch to search for TeamViewer ID 441055893 in this traffic:


And as you can see, XORSearch finds this ID by left-shifting the content of the pcap file with one bit.

Thursday 14 February 2013

Quickpost: TeamViewer and Proxies

Filed under: Forensics,Networking,Reverse Engineering — Didier Stevens @ 22:15

Sorry for the lack of recent posts, I’ve been ill and had to catch up with a lot of work.

Braden Thomas wrote an interesting series of posts on reversing the TeamViewer protocol.

I want to add my own observation: when TeamViewer is forced to communicate over an HTTP proxy, it will issue GET statements with parameter data that can be decoded in a similar way as Braden describes for the direct protocol (i.e. without proxy).

First of all, to identify TeamViewer traffic in proxy logs, you look for this User Agent String: “Mozilla/4.0 (compatible; MSIE 6.0; DynGate)”.

You will see HTTP GET requests like this one:


When you decode the value of the data= parameter as base64, you can identify the version of the protocol (first 2bytes) and the command (3rd byte):

0x1724 0x12

0x12 is a CMD_MASTERCOMMAND. By left-shifting the data from the 5th byte with 1 bit, you can decode the arguments of a MASTERCOMMAND, like this:


When parameter f (the function) is RequestRoute2, you know that the TeamViewer user issued a command to connect to another TeamViewer client. Parameter id identifies the originating client (123456789 in my example), and parameter id2 identifies the destination (987654321 in my example).

Tuesday 21 October 2008

The Case of the Corrupted Stream Object

Filed under: Malware,PDF,Reverse Engineering — Didier Stevens @ 21:38

A malicious PDF file I analyzed a couple of months ago (the one featured in this video) had a corrupted stream object. It uses a /FlateDecode filter, but I could not find a way to decompress it with the zlib library. Back then, I wrote it off as an error of the malware author.

Lately, I’ve been analyzing some shellcode, and while looking at the shellcode in said malicious PDF, I saw it! The second-stage shellcode, a egghunt shellcode, is searching through process memory for the 8 bytes at the beginning of the corrupted stream object.

The malware author knows that the PDF reader loads the PDF document in memory, so he just overwrote the stream object with his third-stage shellcode. This way, his third-stage shellcode is already in memory, waiting to be found by his second-stage shellcode. And the size of his third-stage shellcode is not limited by the buffer he is overflowing.

Next Page »

The Rubric Theme. Blog at WordPress.com.


Get every new post delivered to your Inbox.

Join 342 other followers