In recent weeks I've spent a good amount of time delving into a topic that truly fascinates me, and that's malware reverse engineering. As an incident responder, I've spent a lot of time leveraging automation and pre-built/publicly available sandboxes to do a lot of the heavy lifting when it came to understanding what exactly an executable was doing. Despite this, I understood that these resources definitely have their limits, especially when it comes to more sophisticated pieces of code.
This blog post series is going to offer some useful tidbits on how to get a better idea of what a piece of malware is doing without relying solely on automation or commercially-available sandboxes. While these tools are great timesavers and can give you a decent idea of what's going on, a little bit more time and diligence can offer a more reliable result of the capabilities within what I'm calling the "malware piñata."
This series will not be a primer in assembly code or structures, but will rather offer some additional insight below the OSINT/sandbox surface that can help today's incident responder get some additional context on what a piece of suspicious code is doing.
LAB REQUIREMENTS & COMPONENTS
A good amount of analysts are apprehensive to experiment with malware for fear of accidentally detonating it and infecting their workstation, or even worse, doing so with a self-propagating piece of destructive code and damaging more than their own endpoint. The first step is setting up a virtual environment with all of the tools you'll need.
Hardware Requirements
For anyone that wants to explore static and dynamic malware analysis, the recommendation will be two virtual machines (VMs) running concurrently (at minimum). With great VMs come great hardware requirements. My personal recommendation for a comfortable setup is as follows:
500 GB hard drive
16 GB RAM
3.0GHz+ processor
Scaling down on hardware components won't completely cancel your ability to dissect some badness, but may reduce the smoothness in doing so. If possible, the last thing to sacrifice on would be RAM.
Hypervisor
VirtualBox and VMWare are both options here, the biggest difference being that VirtualBox is completely free and open-source, where as only the basic versions of VMWare's products are available for free. In my experience, VMWare's free products have too many limitations to be useful when it comes to building a good environment. There's no NAT customization and no ability to generate snapshots, which are an important part of cleaning an environment after detonating malware.
In my environment, I pay for and use VMWare Pro; it's personal preference and the hypervisor I'm most familiar with.
For VMWare's product comparisons, visit their website.
For VirtualBox's information, visit their website.
Recommended VMs
There is a broad range of possibilities when configuring a testing environment. Some folks like to keep it on the simpler side, with one or two VMs. Others like to emulate a realistic network configuration and have multiple VMs with different versions of the same operating system along with completely different platforms. My personal minimum recommendation is setting up one Windows and one Linux VM; not only can you then work with a broad swath of tools, but these two VMs can also be networked to observe potential network capabilities of whatever malware is being analyzed.
Linux distributions are available for free. You can start from scratch and download a clean distro to then load tools into, or download a pre-loaded distribution. I use REMnux in my environment, which can be found here. This VM already has preloaded tools and documentation to accompany it.
For Windows, Microsoft offers VMs for testing and development that can be found here. Note that the VMs expire after 90 days. After downloading and installing the VMs on your hypervisor, you can then load it up with all of the tools needed.
TOOL INSTALLATION
Linux Tool Installation
If using REMnux, there's already a plethora of tools available; however, in the event you've started with a clean Linux distro or want to add another tool to your REMnux arsenal, here's how to do it.
Copy the code for the tool you'd like to install (normally from GitHub)
Open your Linux VM, open a terminal, and type "nano filename"
Paste the code into the nano window
Type Ctrl + x to write and save the file
Move the file into the /usr/local/bin directory
For more information on how to use nano, visit Linuxize. Note that this is not the only text editor you can use, feel free to use any Linux text editor you're comfortable with to perform the above steps.
Windows Tool Installation
There's two main ways one could install tools on a Windows VM. The first is to bridge the VM's network connection to the host, and download the tools directly from the internet. The alternative is to download the tools to the host, and then drag the files over into the VM.
SAFE CONFIGURATION
This is a key part of the lab setup. It is paramount that the lab be configured in a manner to where the host system has very limited interaction with the VMs, and the VMs have extremely limited (if any) connection to the internet. MAJOR NOTE: If you have connected your Windows VM directly to the internet as mentioned in the previous section, MAKE SURE YOU CHANGE YOUR NETWORK ADAPTER PRIOR TO MALWARE DETONATION as I'll indicate below. I'll be describing the changes for users utilizing VMWare Pro, however all analysts setting up an environment should make sure these changes are made in their environments regardless of hypervisor or number of virtual endpoints.
For each VM in your environment:
Make sure the virtual network adapter is set to "host-only." In VMWare Pro, this is done by clicking on "Virtual Machine" at the top of the screen, followed by hovering over "Network Adapter" and selecting "host-only." VirtualBox users can reference the instructions found here. Doing this creates a virtual network interface and does not allow the VM to utilize the host's physical network interface.
Make sure that "Folder Sharing" is disabled. In VMWare Pro, this is done by clicking on "Virtual Machine" at the top of the screen, followed by hovering over "Sharing" and selecting "Sharing Settings..." Review and make sure that "Enable shared folders" is NOT checked. Details for the same on VirtualBox can be found here.
Networking configurations between VMs will be covered in a future blog post in the series. Recommended tools will be covered in future blog posts as requirements for those tools arise in the analysis process.
CONCLUSION
The above guidelines are not the "end all, be all" on how to setup a malware analysis environment. There's many different configurations and setups possible, but following the guide above will get any analyst set up with a solid, basic environment. The safety recommendations are a top priority for any setup, whether the environment is more or less intricate than the walkthrough provided.
As we head into the holiday season worldwide, I hope everyone has a happy, warm time with loved ones. For the analysts working through this time, stay vigilant, stay sharp, but take care of yourself. This time of year can be very tumultuous, especially as threat actors capitalize on opportunities that arise. Take care of yourselves and know that you're appreciated. Cheers!
Comments