Evaluating Automated Malware Analysis Tools & Techniques: Part 1 - Packer Attacker Overview

November 10, 2015

Pandas, Fridas, PackerAttackers Oh My!

As my professional career and personal interests begin to involve more and more reverse engineering I’ve been spending countless hours in debuggers and disassembling tools. What I’ve come to realize is the value of automated tools to assist in the reverse engineering process. My goal is to produce an automated unpacking and analysis framework for malicious code. There are projects that have aspired to do such things, such as https://github.com/BromiumLabs/PackerAttacker by Bromium Labs for automated unpacking/dumping of malicious code.

There are a subset of techniques that are used by most malware authors that can be programmatically automated so reverse engineers do not have to perform these tasks if the technique is known, however, these subsets are ever changing, thus the need for a framework to provide extensibility and that is not subject to code rot. This extensibility should provide the ability to integrate commonly used tools such as Volatility. Further, they should provide a means of assisting in static analysis. There are three tools that I’ll be evaluating throughout this series: Panda (Platform for Architecture-Neutral Dynamic Analysis), Frida and the aforementioned PackerAttacker in relation to one of the requirements for the framework. As you may have already realized I will be focusing on Windows x86/WoW64 Malware for the time being.

PackerAttacker

I’ve included this project as it was released when I was initially thinking about this concept. Nicolas Brulez covered a number of unpacking concepts during the Reverse Engineering Malware course that I took last year at REcon, he demonstrated an automated unpacking system that he has kept private due to a number of reasons, which is what initially set me on a path to create my own using readily available technologies.

Hooking With Detours

PackerAttacker is essentially a user-land rootkit that monitors API calls and adjusts memory permissions to force DEP exceptions to track memory page usage using a vectored exception handler. Function hooking is done using Microsoft’s Detours. Detours is a library for instrumenting Windows x86 binary functions. From the paper: by re-writing target function images. ... Detours replaces the first few instructions of the target function with an unconditional jump to the user-provided detour function. So essentially it enables user-land rootkit functionality for a given set of target binary functions.

Overall Technique for Dumping

It’s quite intuitive in the sense that traditional packers will allocate memory pages to which they’ll adjust to have executable permissions for executing position independent code. The functions they track being NTProtectVirualMemory and NTAllocateVirtualMemory will then call a trampoline function to remove the execution permission so when the target memory is fully unpacked and is executed it results in the DEP exception. The exception is caught with the aforementioned Vectored Exception Handler, the unpacked region is dumped to disk, permissions are returned to the memory range so the code can continue its execution process, and the exception is handled.

PE Based Packers

They also handle PE-based packers by identifying -WX PE sections prior to injecting their hooks and since entry-points are typically not write-able it can be assumed that this is to be written to by the packer. They then adjust this permission to be --X so at which point the packer is writing to the section they will get an ACCESS_VIOLATION at which point they can then remove execution permissions from the section, and use the aforementioned method to dump memory when a DEP exception is hit.

Process Injection

Since process injection has two API ‘entry points’ from the binary they dump any memory being written to remote processes by hooking NtWriteVirtualMemory and NtMapViewOfSection. NtWriteVirtualMemory is awaited to be dumped when the injecting process exits.

Limitations

• The obvious limitations are that of API function resolution, for example if the dumped code is pointing to runtime structures that provide the API translation for function calls, we’ll get a disassembly that does not provide an immense amount of value. This is a typical unpacking step for those unfamiliar, known as ‘reconstructing the IAT’. Not to say that this is a simple task to accomplish, and that there is no silver bullet for unpacking binaries but this is needed nonetheless. That step will require manually unpacking the translation function, for example, and using those checksums to mark up the dumped disassembly.

• Currently only 32-bit binaries are supported, as the WoW64 version of Detours is currently private, and they have not written a 64-bit hooking framework.

• Virtual machines, and other forms of packers are outside of the scope of this toolset as well.

• Lack of extensibility. As was defined by my above mentioned requirements, C++ code is not extensible or easily integratabtle with other toolsets.

An overview of the project can be found in this video (their talk from this year’s DerbyCon) which I found to be the only decent source of information as there is a lack of documentation currently.

This was a quick post, but I’d like to split these up as the next two are going to be quite extensive. Give PackerAttacker a try.

Thanks for reading!