Monday, November 30, 2015

Guest Post: Martin Korman (VolatilityBot - An Automated Malicious Code Dumper)

This is a guest post from Martin Korman, author of VolatilityBot.

Lately, I've found myself manually unpacking different versions of the same malware in order to perform static analysis with IDA and BinDiff. Therefore, I've decided to write a small system that will automate the entire process – the VolatilityBot.

How does VolatilityBot work?
  1. It executes the malware on a VM.
  2. It waits for a pre-defined period of time.
  3. It suspends the VM.
  4. It compares the snapshot to a golden image of the VM, finds new processes, injected code, loaded DLLs or Kernel Modules, dumps them from the memory and fixes the PE file in order to make static analysis easier.

All metadata is saved to a SQLite DB. Dumps are saved to a configured storage path on disk. All PE files pass a short static analysis and reports are stored as well. VolatilityBot can theoretically manage an unlimited quantity of virtual machines, depending on the performance of your host machine. 

Some core capabilities of this automation tool were designed to make it as scalable as possible and easy to work with over time:

  • The Bot-Excavator's Manager can handle an unlimited number of machines at once, all depending on the performance of the researcher's equipment.
  • Automatic "Golden Image" generation is provided in order to ease the process of creating all "Golden Image" data. Just create your configuration file, and execute the script.
  • To simplify scalability, any database supported by SQLalchemy can be set or replaced as needed. The default Bot-Excavator's backend saves data to an SQLite database.
  • Memory dumps and data from all configured post processing modules are saved to a predefined storage directory.
  • Add tags to each execution of the script for quick visual reference to information you may need later.
  • Add dynamic tags to post-processing modules. For example, for malware that loads a kernel mode driver, tag it with "loads_kmd".Volatility Bot-Excavator's modular structure makes it easy to add additional modules and post-processors that may be deemed necessary with time. 

Let's dive deeper into the architecture of VolatilityBot. The Bot-Excavator is made of four (4) major components:


1. The Manager. This is the core of the Bot-Excavator tool. The Manager executes the automatic extraction as well as the post-processing modules. This module also controls the associated machines' activity to streamline the workflow.


2. Machines Module. This is an abstract design of a research machine; it contains five functions: Revert, Start, Suspend, Clean-up and Get memory path. Each machine has a minimal python agent running, that listens and waits for a malware sample. When the sample is sent, it executes it by double clicking the sample, using an AutoIt script. 


The agent is really minimal in order to not affect the behavior of the malware in the machine. The agent does not perform any API hooking and does not control the machine in any form besides executing the malware. The machines are controlled and monitored by the manager component, which knows not to send more analyses to a machine if its busy or if it encountered any errors analyzing the previous sample.


3. Code Extractors. This component consists of a number of modules grouped together for the purpose of extracting all the different malicious code components from memory. These are separate for code injections, new processes, etc. This component is modular and allows researchers to write new code for other extractors they may need.


These are the existing modules for this component:

  • injected_code – uses the Volatility "malfind" plugin in order to find suspect memory areas, after dumping them it tries to determine if the section contains a valid PE or valid shell code. If it found a valid PE, it fixes PE the header. Either way it will extract strings and execute YARA on the section dumped from memory.
  • module_scan - Uses the Volatility "modscan" plugin to load kernel modules. It detects and dumps newly loaded kernel modules.
  • create_process_dump - Uses the Volatility "procdump" and "pslist" plugins to dump new processes created by malware. Executes YARA, and extracts malware strings.
  • create_process_dump_as - Uses the Volatility "procdump" plugin to dump address space. Executes YARA, and extracts malware strings.
  • hooks – Extract API hooks done by malware (User-mode and Kernel-mode)
4. Post-Processing Modules. The post-processing modules kick in after the extraction is complete. They are then tasked with automated actions like fixing the PE, or availing the resulting elements to static analysis, YARA scans, strings and IP address logging etc.


This module type can help with:

  • Executing the configured YARA rules on post-extraction input as defined by the researcher.
  • Extracting strings from the input defined. Other modules can be layered on top in order to extract IP addresses, URLs, etc.
  • Producing a report for static analysis with basic PE analysis of the input file.

Because the malware samples are executed in a virtual machine, in order to avoid VM detection, a few tricks were used:

  • Registry keys cleanup (all VMware stuff I don't think there is a need to describe, as there's a lot of information on the internet regarding this issue).
  • A macro that moves the mouse and executes the malware.
  • Of course, no VMware tools on the machine.

Documentation and installation instructions are available here:
https://bitbucket.org/martink90/volatilitybot_public/downloads/Documentation_Nov_2015.pdf






For any questions, feel free to reach me via twitter (@MartinKorman), or open an issue in the project's Bit Bucket. 

Friday, November 6, 2015

PlugX: Memory Forensics Lifecycle with Volatility

At OSDFCon last week, we discussed a case study showing how we identified manipulated memory artifacts in an infected environment. We were then able to rapidly introduce new capabilities to Volatility that could be used proactively in other environments.

The presentation (hosted on prezi) takes you on a tour of this activity, using a series of videos. Unfortunately, there's no audio (you should have attended the conference!) but it should be fairly self explanatory what's going on. Here's a short description of what the presentation covers:

  • A recent PlugX variant penetrated the target's network. It installed a service named RasTls for persistence and then hid the service from all live tools (WMI, Power Shell, services.msc, sc query, etc). 
  • It injected code into a process and then erased its PE header to evade detection and make dumping the PE file out of memory a bit more complicated. 
  • We identified the injected region with malfind, extracted it with Volatility, then used a hex editor and PE editor to reconstruct the PE file format. 
  • We leveraged the impscan plugin to label API calls inside IDA Pro, then reverse engineered the binary to figure out how it's rootkit component was working. It was clearly targeting the double-linked list of services in usermode space of services.exe. 
  • Next we wrote a new Volatility plugin to automatically detect unlinked services, by comparing the records in memory with the memory-resident registry hives. 

The second part of our talk covered the new features in Volatility 2.5 (including the unified output, community integration, and support for Windows 10, Mac El Capitan, and Linux kernels up to 4.2.3) and all of the submissions to this year's Volatility Plugin Contest.

You can find the slide deck for our talk here (pdf).