Author Archives: didiernviso

Decompiling py2exe Executables

We had to decompile an executable (.exe) generated with py2exe for Python 3.

py2exe takes a Python program and generates a Windows executable. This .exe file contains the Python bytecode of the program, a Python interpreter and all the necessary modules. The bytecode is stored as a resource inside the .exe file.

unpy2exe will extract the Python bytecode as a pyc file from the .exe file, which can then be decompiled with uncompyle6. Unfortunately, unpy2exe does not support files generated with py2exe for Python 3.

We release our program decompile-py2exe to handle py2exe Python 3 executables. It is simple to use:

20170102-110208

decompile-py2exe takes an executable as argument, extracts the Python bytecode and decompiles it with uncompyle6, all in one step. The executable can also be passed via stdin or inside a (password protected) ZIP file. Be sure to use Python 3 to run decompile-py2exe.

 

PDF Analysis: Back To Basics

When you receive a suspicious PDF these days, it could be just a scam without malicious code. Let’s see how to analyze such samples with PDF Tools.

As always, we first take a look with pdfid:

20161228-111628

There’s nothing special to see, but we have to check the content of the Stream Objects (/ObjStm):

20161228-111805

Still nothing special to see. This could be a malicious PDF document with a pure binary exploit (e.g. without using JavaScript), but nowadays, it’s more likely that we received a PDF containing links to a malicious website, like a phishing website.

To check for URLs, use option search (-s) to search for the string uri (the search option is not case sensitive):

20161228-111841

And indeed we find objects with URIs. These are links tied to a rectangle, thus a zone that must be clicked by the user to “activate” the URL: Adobe Reader will display a warning, and after user acceptance, the default browser will be launched to visit the given URL.

pdf-parser also has an option to select key-value pairs from dictionaries of PDF objects: option -k. This is useful to generate a quick overview. This option is case sensitive, and the full keyname must be provided:

20161228-111902

When we open the PDF document with Adobe Reader, we get visual confirmation that it is a phishing PDF:

20161213-174821.png

And this is the phishing website:

20161213-175330.png

Conclusion: if pdfid reports nothing suspicious, before looking for binary exploits (for example with pdf-parser’s YARA support), search first for URIs with pdf-parser.

Analyzing an Office Maldoc with a VBA Emulator

Today we were informed of another maldoc sample. After a quick look, we were convinced that this sample would be a good candidate for Philippe Lagadec’s VBA emulator ViperMonkey.

The maldoc in a nutshell: when the spreadsheet is opened, the VBA code builds a long JScript script and then executes it. This script contains base64 code for an executable (ransomware Petya GoldenEye version), which is written to disk and executed. The building of the script is done with heavily obfuscated VBA code, so we thought it would be a good idea to try ViperMonkey. ViperMonkey is a free, open-source VBA emulator engine written in Python. You can use it to emulate VBA code on different platforms without MS Office.

Taking a look with oledump.py at this sample (md5 b231884cf0e4f33d84912e7a452d3a10), we see it contains a large VBA macro stream:

20161207-140153

 

Here is the end of the VBA code:

20161207-140222

Let’s analyze this with ViperMonkey:

vmonkey.py sample.vir

Since there are a lot of VBA statements, it will take ViperMonkey some time (couple of minutes) to parse this:

20161207-134559

In the end we get this result:

20161207-135220

ViperMonkey doesn’t identify any suspicious actions, but we see that the ActiveX object to be created is “MSScriptControl.ScriptControl”. This string was obfuscated with Chr concatenations, and ViperMonkey was able to parse it. To parse all obfuscated expressions like this, we provide option -e to ViperMonkey:

vmonkey.py -e sample.vir

20161207-140124

 

We this information, we can understand what subroutine Workbook_Open does: it executes a JScript script stored in variable LQ3.

How to we get the value of LQ3? We can set ViperMonkey’s log level to debug, and log the emulation of all statements. This will produce a lot of output, so it’s beter to redirect this to file.

vmonkey.py -l debug sample.vir > output.log 2> debug.log

Searching for the last occurrence of string “setting LQ3” in debug.log, we find the JScript script:

20161207-141806

This script decodes a BASE64 payload, writes it to disk and then executes it: it’s a new variant of Petya ransomware, GoldenEye.

 

PDF URIs

I was handed an interesting PDF document. It doesn’t contain malicious code, yet it generates network traffic. Let me explain how this is achieved.

Creating a PDF that makes a HTTP(S) connection to a website is easy. There’s no need to use an exploit, not even JavaScript. You just have to use a URI object:

20161128-103231

On its own, this object will do nothing. An action is needed to have this URI requested. If you want this URI to be requested when the PDF document is opened, you could add an /OpenAction:

20161128-103504

Adobe Reader will not let this connection happen silently. The user will be prompted before the TCP connection (to subdomain.nviso.be in our example) is established:

screen-shot-2016-11-28-at-10-44-35

But even before the user clicks one of the buttons, Adobe Reader will do a DNS request for this domain (nviso.be):

screen-shot-2016-11-28-at-10-43-43

If the domain does not resolve to an IP address, Adobe Reader will do another DNS request for the subdomain (subdomain.nxdomains.be in this example, where nxdomains.be does not resolve to an IP address):

screen-shot-2016-11-28-at-10-46-50

In this case, the warning presented to the user is slightly different:

screen-shot-2016-11-28-at-10-47-05

This type of PDF document can be used to track users: when the document is opened, a DNS request is performed. If the request is a FQDN unique to the PDF document, then such a DNS request logged by the DNS server is a sure indicator that the PDF document has been opened. Remark that this DNS request will have a source IP address from a DNS server, not from the user’s machine.

If the user allows a connection to be made, then a TCP connection will be established between the user’s machine and the web server.

In a corporate environment with HTTP(S) proxies, the DNS requests can be prevented from going to the Internet.

Malicious Document Targets Belgian Users

In this blog post I want to show how a malicious document (maldoc) behaves and how it can be analyzed with free tools.

A couple of weeks ago many users in Belgium received an e-mail, supposedly from a courier company, informing them that a package was waiting for them (article in Dutch).

This is an example of the e-mail:

20161114-142948

This e-mail contains a link to a Word document:

20161114-142226

The Word document contains VBA macro code to download and execute malware (downloader behavior). But MS Word contains protection features that prevent the code from running when the document is opened in Word.

First of all, since the Word document was downloaded from the Internet, it will be marked as such, and MS Word will open the document in Protected View:

20161114-143404

The user is social-engineered into clicking the Enable Editing button. Because the Word document contains VBA macros, another protection kicks in:

20161114-143421

By default, MS Word disables macros for documents of untrusted sources. Only after the user clicks on the Enable Content button, will the VBA macros run.

The user is presented with an empty document, but meanwhile malware was downloaded and executed invisibly to the user:

20161114-143442

The VBA macro code can be extracted with a free open-source tool: oledump.py.

20161114-153022

When looking at the VBA code (streams 8 and 9), we find subroutine Document_Open in stream 9:

20161114-153526

This subroutine is automatically executed when Word opens the document. Subroutine Document_Open contains a call to subroutine TvoFLxE in Module1:

20161114-155109

Subroutine TvoFLxE removes the content of the document (this causes the document to become blank, see screenshot), saves the document and calls function HuEJcCj.

20161114-155123

In this function we see a call to CreateObject. This is always interesting and requires further analysis. CreateObject takes a string as argument: the name of the object to be created. In this code, the string is returned by function JFZzIeCKcjgPWI which takes 2 arguments: 2 strings that look like gibberish. We see this often in maldocs (malicious documents): strings are obfuscated, e.g. made unreadable. Function JFZzIeCKcjgPWI is a string decoding function, taking strings “MWqSBYcnRrviVpGRtY.ASJhGneqYlVl”and “FYqRnVNvJB1GqMA” and converting them to a meaningful string.

In this maldoc, the string obfuscation method is rather simple. Function JFZzIeCKcjgPWI removes all characters found in string “FYqRnVNvJB1GqMA” from string “MWqSBYcnRrviVpGRtY.ASJhGneqYlVl”. Was is left is string “WScript.Shell”. This Shell object can be used to make Windows execute commands. So we need to deobfus.

20161114-155207

When we deobfuscate these strings, we get this PowerShell command:

20161114-162354

This PowerShell command downloads an executable (malware) to disk and executes it. The downloaded malware seems to be ransomware, we’ll write another blog post if it has interesting features.

To protect yourself from this kind of attacks, never activate the document (Enable Editing and Enable Content). Anti-virus can also protect you by 1) detecting the maldoc and 2) detecting the executable written to disk. When you don’t trust a document, you can always upload it to VirusTotal.