Over at the ISC Diary I have an entry on Locky JavaScript Deobfuscation. I use my translate tool to perform part of the static analysis.

When you read this diary entry, you’ll see that I have to create 2 Python scripts to be used by translate.py to search with a regular expression and replace all matches with the output of a Python function.

I updated translate.py so that I don’t have to create Python scripts for this regex search-and-replace, but that I can do it from the command-line with a new option. This new option (-r, –regex) takes a regular expression and does a search-and-replace.

Here are the 2 “scripts” using this new option:

translate.py -r "\([^\\\(]+\\u([0-9a-f]{4})[a-z]+'\.e\(\)\)" "lambda oMatch: chr(39) + chr(int(oMatch.group(1), 16)) + chr(39)"
translate.py -r "('[^']*' ?\+ ?)+'[^']*'" "lambda oMatch: chr(39) + eval(oMatch.group(0)) + chr(39)"

If you just want to do a search-and-replace, you can use a constant regex and lambda function, like this (replace False with True):

translate.py -r "False" "lambda oMatch: 'True'"

translate_v2_2_0.zip (https)
MD5: D561D9987A3E5264E40A4B5C4057A732
SHA256: BC532BD5C7DD86DCADDF7B7B9A34453E983E226E103E0591E7D480BB43C350E0

I’m providing a 2-day training at Brucon Spring Training 2016: “Analysing Malicious Documents“. Use promo-code SPRING16 for a 10% discount.

I received a maldoc sample (MD5 FAF75220C0423F94658618C9169B3568):

You can see it’s a MIME Type file, and that it is obfuscated. The second line is a very long line of seemingly random letters and digits. This throws of Python’s MIME parser used by my emldump tool:

emldump just detects this as a text file, and not as a multipart MIME Type file.

If we remove that second line, for example with findstr /v (or grep -v), emldump recognizes the different parts:

Since obfuscated MIME Type files are becoming more and more prevalent, I’m adding a filter option to emldump to filter out lines that obfuscate the MIME Type files. For the moment, option -f throws out lines longer than 100 characters and header lines that are not fields (just like option -H).

This new version of emldump.py detects some (simple) types of obfuscation:

And with option -f you can filter out these obfuscating lines:

Download:

emldump_V0_0_7.zip (https)
MD5: 819D4AF55F556B2AF08DCFB3F7A8C878
SHA256: D5C7C2A1DD3744CB0F50EEDFA727FF0487A32330FF5B7498349E4CB96E4AB284

I’m providing a 2-day training at Brucon Spring Training 2016: “Analysing Malicious Documents“. Use promo-code SPRING16 for a 10% discount.

I received another maldoc sample (MD5 73D06B898E03395DA3D60D11E49751CC):

Lines 2, 3, 6, 7 and 8 are there to obfuscate this MIME type file. emldump.py now detects all lines without a colon in the first block (all lines before the empty line 9: 1 – 8).

You can filter out these lines with option -f:

emldump_V0_0_8.zip (https)
MD5: B6FBAF2AB403AFE30F7C3D7CA166793B
SHA256: 7A7016B29F291C3D42B43D43B265DAD86B96DA519DB426163CC2D15C556896E3

I’m providing a 2-day training at Brucon Spring Training 2016: “Analysing Malicious Documents“. Use promo-code SPRING16 for a 10% discount.

This new version of oledump brings an update to the –cut option and a new plugin: plugin_hifo.

As I documented in this ISC Diary entry, maldocs can store URLs in properties of userforms:

The plugin plugin_hifo is a simple plugin that looks for streams that end with /o and then searches for strings starting with http (hence the name: http in form /o).

oledump_V0_0_23.zip (https)
MD5: 991910FF4AA47808A5BBCE0CC109D41A
SHA256: 612B6FD06856C7790D2F66B29286E7B89D35D8354ADB167CA512CC1CDE3F6C47

Malicious documents that drop VBE scripts (VBScript Encode scripts) are in the wild. Here is an example:

I have a YARA rule to detect VBE scripts:

yara-rules-V0.0.6.zip (https)
MD5: 01CB37759AC30EEA8D2B66226609C73E
SHA256: 1B56C1D7D0E1A8F500674B74F93F3E7DE6B2EFC85259ABE3A57F1DCA458CCFF8

This is a YARA rule to detect PE files that were created with PyInstaller (a tool to convert Python programs to binary executables).

More info in my ISC Diary entry: Python Malware – Part 1.

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

  Shortcomings, or todo's ;-) :

  History:
    2016/05/14: start
*/

import "pe"

rule PE_File_pyinstaller
{
    meta:
        author = "Didier Stevens (https://DidierStevens.com)"
        description = "Detect PE file produced by pyinstaller"
    strings:
        $a = "pyi-windows-manifest-filename"
    condition:
        pe.number_of_resources > 0 and $a
}

yara-rules-V0.0.8.zip (https)
MD5: 83D10B0A18D3F8E2C744B8FEA10F5E67
SHA256: 2D47165757F909440F6D1A95FF5C0EA1355B355AE7475D2A0CF821D3B9A6235A

There are Office maldocs out there with some complex payload decoding algorithms. Sometimes I don’t have the time to convert the decoding routines to Python, and then I will use the VBA interpreter in Excel. But I have to be careful not to execute the payload, just decode it. In the following video, I show how I do this.

Tools: oledump.py, decoder.xls

Sample: 2f918f49c3f926bb1538eaad6e8e6883

Last week I came across a new Hancitor maldoc sample. This sample contains encoded shellcode that starts a new (suspended) explorer.exe process, injects its own code (an embedded, encoded exe) and executes it. This process hollowing technique bypasses application whitelisting.

This maldoc uses VBA macros (no surprise) to execute its payload.

The encoded shellcode is a property in stream 17:

I used my decoder.xls method to decode the shellcode (the name of the decoding function is apocope). And then Radare2 and my script to disassemble the shellcode (32-bit and 64-bit shellcode):

The shellcode uses WIN32 API functions like CreateProcess, ZwUnmapViewOfSection, GetThreadContext, ResumeThread, … to inject code into the newly created process (explorer.exe) and execute it. This method is called process hollowing or process replacement.

The explorer.exe process is created in a suspended state, the code for explorer.exe is removed, the code for the payload is injected, the context of the thread is updated and then the thread is resumed. This method bypasses application whitelisting, as explorer.exe is a whitelisted PE-file.

The payload is an PE-file (exe) embedded and encoded in the maldoc in stream 5. STARFALL is the string that indicates the start of the payload. The PE-file is encoded with base64 with each byte XORed with 15 and then 3 subtracted. This file can be detected and extracted with my decode-search.py tool:

This executable was not yet submitted to VirusTotal, most likely because it’s never written to disk. I did submit it: cdcd2ca36ed9a2b060dd4147bc5f7706.

This exe tries to download a payload from 3 URLs:

This new version can produce a compact overview of all the resources in a PE file using option o: -o r.  Here is the overview of resources in an exe (malware) created with iexpress:

It contains a cab file with 2 executables, which are executed after extraction (no surprise):

pecheck-v0_6_0.zip (https)
MD5: D3A9C71AAF63D83884B4FEF2C2C21D03
SHA256: 08DB82F190AEEB065A65FEE0DD03D20B0CC788878C4864B537BBD1807E4D6B71

I produced 4 videos covering the process hollowing maldoc “Maldoc With Process Hollowing Shellcode“.

While reading-up on ClamAV and YARA, I came across something I wanted to try for some time: have ClamAV decrypt and scan a password protected ZIP file.

It can be done by creating a .pwdb password signature file, as explained in section 3.12 of Creating signatures for ClamAV.

I created one signature for password “infected”:

ZipPasswordInfected;Engine:81-255;0;infected

ZipPasswordInfected is the name I gave to the signature.

Engine:81-255 defines the required functionality level of the ClamAV engine. If I’m not mistaken, 81 is version 0.99.

0 indicates that the password is in ASCII.

infected is the password to attempt ZIP decryption.

And then I can pass the password signature file to clamscan with option -d. Or I can put the password signature file in the database directory.

In this example, notepad.exe is stored in a password protected ZIP file (password infected), and is_pe_file.yara is a YARA rule to detect PE files.

clamscan.exe -d is_pe_file.yara -d passwords.pwdb notepad.exe.zip
notepad.exe.zip: YARA.is_PE_File.UNOFFICIAL FOUND

----------- SCAN SUMMARY -----------
Known viruses: 1
Engine version: 0.99.2
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.21 MB
Data read: 0.14 MB (ratio 1.50:1)
Time: 0.063 sec (0 m 0 s)

Quickpost info

I have an analysis of a CVE-2017-0199 maldoc with my tools here, and produced 2 videos:

In the second video, I use nixawk‘s Metasploit module for cve-2017-0199 (not yet merged into the Metasploit GitHub repository at time of writing).

I must admit that I was (patiently) waiting for the type of malicious document I’m about to describe now. First I’m going to analyze this document with my tools, and after that I’m going to show you some of the mitigations put in place by Adobe and Microsoft.

Malicious document 123-148752488-reg-invoice.pdf is a PDF with an embedded file and JavaScript. Here is pdfid’s report:

As we can notice from this report, the PDF document contains /JavaScript and an /OpenAction to launch this JavaScript upon opening of the PDF file, and also an /EmbeddedFile.

pdf-parser.py searching for JavaScript (option -s javascript) reveals that the JavaScript is in object 5:

Object 5 contains JavaScript (option -o 5 to select object 5, and option -f to decompress the stream with JavaScript):

This script (this.exportDataObject) will save the embedded file (996502.docm) to a temporary file and launch the associated application (if MS Office is installed, Word will be launched). A .docm file is a Word document with macros.

So let’s search for this embedded file:

The embedded file is stored in object 3, as a compressed stream (/FlateDecode).

So let’s decompress and extract the file with pdf-parser: option -f to filter (decompress) and option -d to dump the content. Since I expect the embedded file to be a Word document with macros, I’m going to analyze it with oledump. So in stead of writing the embedded file to disk, I’m going to extract it to stdout (-d -) and pipe it into oledump:

oledump‘s report confirms that it is a Word document with macros. I’m not going to spend much time on the analysis of the VBA code, because the intent of the code becomes clear when we extract all the strings found in the VBA code. First we select and extract all VBA code (options -s a -v) and then we pipe this into re-search to produce a list of unique strings (enclosed in double quotes) with these options: -n str -u

One of the extracted strings contains 3 URLs separated by character V. The macros will download an XOR encoded EXE file from these sites, decode it and execute it.

Mitigations

The first mitigation is in Adobe Reader: the embedded .docm file will not be extracted and launched without user interaction. First the user is presented a dialog box:

Only when clicking OK (the default option), will the .docm file be extracted and launched. Remark that the maldoc authors use some weak social engineering to entice the user to click OK: see in 996502.

When opened in Word, macros will be disabled:

This next mitigation is put into place by Microsoft Word: macros are detected, and by default, they are not executed. Here we see a better attempt at social engineering the user into executing the macros.

You might have expected that this document would be opened in Protected View first. After all, the PDF document was e-mailed to the victims, and Outlook will mark the PDF with a mark-of-web when it is saved to disk:

But Adobe Reader will not propagate that mark-of-web of the PDF document to the extracted Word document (at least the version I tested, version XI). Without mark-of-web, Word will open the document without Protected View.

Another simple mitigation for this type of malicious document that you can put into place but that is not enabled by default, is to disable JavaScript in Adobe Reader.

Remark that these documents do not contain exploits: they just use scripting.

It looks like #WannaCry’s killswitch check (www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com) is not proxy aware:

Organizations that use proxies will not benefit from the killswitch.

Sample: 5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec

I have not tested this in a VM. If someone has, please post a comment with your findings.

Update: I did test the sample, it is not proxy aware. In an environment with an HTTP proxy and no direct connections to the Internet, the sample can not connect to www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com, and it will infect the host.

If I patch the sample to make it proxy aware, it can connect to the site through the proxy, and it does not infect the host.

Quickpost info

I’ve seen reports that WannaCry uses a mutex with name Global\MsWinZonesCacheCounterMutexA.

The samples I analyzed all use another mutex: Global\MsWinZonesCacheCounterMutexA0. That’s a digit zero at the end.

I have not found a sample that uses mutex Global\MsWinZonesCacheCounterMutexA (e.g. without digit zero at the end).

Update 1: I got confirmation from Costin Raiu from Kaspersky that the mutex is Global\MsWinZonesCacheCounterMutexA0.

Update 2: dynamic analysis with sample 84c82835a5d21bbcf75a61706d8ab549 shows that there are 2 mutexes that can prevent the ransoming of files: MsWinZonesCacheCounterMutexA and Global\MsWinZonesCacheCounterMutexA0. Remark that the Global namespace must be used with mutex MsWinZonesCacheCounterMutexA0, while it may not be used with mutex MsWinZonesCacheCounterMutexA.

Remark that the code above contains string “Global\\MsWinZonesCacheCounterMutexA”, but that is not the actual string used for OpenMutexA.

The actual string used for OpenMutexA is created by a sprintf “%s%d” call, and results in “Global\\MsWinZonesCacheCounterMutexA0“, that is “Global\\MsWinZonesCacheCounterMutexA” with a digit 0 (zero) appended.

Mutexes have long been used by malware authors to prevent more than one instance of the malware running on the same machine. An old anti-malware trick consists in the creation of a specific mutex, to prevent the execution of a specific malware.

I’ve seen tools and scripts published to create mutex Global\MsWinZonesCacheCounterMutexA to prevent WannaCry from infecting machines. This will not work for the samples I analyzed.

Samples I disassembled:

7c465ea7bcccf4f94147add808f24629644be11c0ba4823f16e8c19e0090f0ff (contained as a resource in 5ad4efd90dcde01d26cc6f32f7ce3ce0b4d4951d4b94a19aa097341aff2acaec).

86721e64ffbd69aa6944b9672bcabb6d (contained as a resource in 5bef35496fcbdbe841c82f4d1ab8b7c2).

Samples I searched for containing the mutex and sprintf code:

509c41ec97bb81b0567b059aa2f50fe8
5bef35496fcbdbe841c82f4d1ab8b7c2
638f9235d038a0a001d5ea7f5c5dc4ae
7f7ccaa16fb15eb1c7399d422f8363e8
84c82835a5d21bbcf75a61706d8ab549
86721e64ffbd69aa6944b9672bcabb6d
d6114ba5f10ad67a4131ab72531f02da
db349b97c37d22f5ea1d1841e3c89eb4
f107a717f76f4f910ae9cb4dc5290594

If you have a sample that actually uses mutex Global\\MsWinZonesCacheCounterMutexA and not mutex Global\\MsWinZonesCacheCounterMutexA0 (e.g. with digit zero appended), please post a comment with the hash of your sample.

Quickpost info

In this video, I show how to get started with my tools and a WannaCry sample.

Tools: pecheck.py, zipdump.py, strings.py

Sample: 84c82835a5d21bbcf75a61706d8ab549

I can’t help feeling some kind of satisfaction when a friend uses my tools to analyze malware, and hacks his way to a solution when my tool falls short

In this nice blogpost, @bluejay00 analyzes RTF malware with my rtfdump.py tool. But because of obfuscation, rtfdump.py is not able to extract the object. @bluejay00 understands this, deobfuscates the RTF sample with an editor, and is then able to get my tool to work correctly.

I’ll just show how I would have used my translate.py tool to remove the obfuscation:

Years ago I wrote a C program to create a new process with a chosen parent process: selectmyparent. And recently I showed what process monitor and system monitor report when you use this tool.

Starting a new process with a chosen parent process can be done from VBA too, as shown in this video (I’m not sharing the VBA code):

While updating my Petya/Notpetya notes, I saw that ClamAV now detects resources 1 and 2 (zlib compressed PE files) as Mimikatz. Curious about how they detect Mimikatz, I wanted to take a look at the signature. I’ve done this before, but I forgot exactly how. So here is a blog post to remind me next time.

First I update the signatures (yup, that’s ClamAV on Windows):

This is a standard scan:

The signature is Win.Trojan.Mimikatz-6331391-0.

Then I do a scan with option –debug, this will print out the signature:

The signature is: 2813d34f6197eb4df42c886ec7f234a1:47616:Win.Trojan.Mimikatz-6331391-0

I hoped for something more interesting: this is an MD5 hash-based signature. 2813d34f6197eb4df42c886ec7f234a1 is the MD5 hash of the file, 47616 is its file size, and Win.Trojan.Mimikatz-6331391-0 is the signature name.

My previous blog post “Analyzing ClamAV Signatures” is incorrect. Here is a better explanation.

I wrongly assumed that the signature printed in the debug statement would be the actual signature in the ClamAV database. That is not always the case.

So here is a better method.

First I update the signatures (yup, that’s ClamAV on Windows):

This is a standard scan:

The signature is Win.Trojan.Mimikatz-6331391-0.

Then I do a search with sigtool in the database, providing a regular expression (Mimikatz-6331391) to match signature names (this matching process is case sensitive):

And this signature is more interesting. This is an extended signature. It is composed of several fields (: is the separator). Here I have each field on a separate line:

Field 1 is the name of the signature.

Field 2 is the type of file to scan: 1 is for PE files

Field 3 is the part of the file to scan: SE1 is the second section of the PE file.

Field 4 is the hex signature: the sequence of bytes to search for in the section, expressed as hexadecimal data. {-10} is a wildcard for 0 to 10 arbitrary bytes.

Field 5 is the minimum version of the ClamAV engine that supports this type of signature.

The bytes represent strings (UNICODE and ASCII):

This signature does not trigger on the genuine mimikatz binaries: