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.
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?
- It executes the malware on a VM.
- It waits for a pre-defined period of time.
- It suspends the VM.
- 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)
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
https://bitbucket.org/martink90/volatilitybot_public/downloads/Documentation_Nov_2015.pdf
Source code is available here: https://bitbucket.org/martink90/volatilitybot_public
My VB2015 slides are available here: https://www.virusbtn.com/pdf/conference_slides/2015/Korman-VB2015.pdf
For any questions, feel free to reach me via twitter (@MartinKorman), or open an issue in the project's Bit Bucket.
No comments:
Post a Comment