We covered dynamic malware analysis by analyzing and comparing changes and modifications done on the registry using Regshot. This was part of TryHackMe Basic Dynamic Malware Analysis.
What is a Sandbox?
Analyzing malware is like a cat-and-mouse game. Malware analysts keep devising new techniques to analyse malware, while malware authors devise new techniques to evade detection.
It has been emphasized that malware should only be analyzed in a controlled environment, ideally a virtual machine. However, this becomes increasingly important for the dynamic analysis of malware. The primary concern regarding performing static analysis on malware in a live environment is an accidental execution, but we intentionally execute malware in a dynamic analysis scenario. This makes it all the more important to ensure that malware is analyzed in a sandboxed environment.
So what is required to create a sandbox?
Broadly, the following setup will be required to create a sandbox:
- An isolated machine, ideally a virtual machine, that is not connected to live or production systems and is dedicated to malware analysis.
- The ability of the isolated or virtual machine to save its initial clean state and revert to that state once malware analysis is complete. This functionality is often called creating and reverting a snapshot. We will need to revert to the original clean state before analyzing a new malware so that infection from the previous malware doesn’t contaminate the analysis of the next one.
- Monitoring tools that help us analyze the malware while it’s executing inside the Virtual Machine. These tools can be automated, as we see in automated sandboxes, or they can be manual, requiring the analyst to interact while performing analysis. We will learn about some of these tools later in the room.
- A file-sharing mechanism that can be used to introduce the malware into the Virtual Machine and sends the analysis data or reports out to us. Often, shared directories or network drives are used for this purpose. However, we must be careful that the shared directory is unmounted when executing the malware, as the malware might infect all the files. This is especially true of ransomware, which might encrypt all shared drives or directories.
In the Intro to Malware Analysis room, we learned about some automated sandboxes to help perform dynamic analysis. Below, we will learn about some tools to help create our sandbox, which gives us more analysis control. So let’s start.
Virtualization
A lot of commercial and free tools are available for virtualization. Some of the most famous ones include Oracle’s VirtualBox and VMware’s Player and Workstation. These three tools allow us to create Virtual Machines isolated from our local machine. However, VMWare Player can’t create snapshots. For dynamic analysis of malware, snapshot creation is a critical requirement, which makes VMWare Player unsuitable for malware analysis. VMWare Workstation and VirtualBox have the snapshot creation option and are, therefore, suitable for malware analysis. VirtualBox is free, but VMWare Workstation has a paid license.
Apart from these, server-based virtualization software like XenServer, QEmu, ESXi, etc., help with virtualization on a dedicated server. This type of setup is often used by enterprises for their virtualization needs. Security research organizations often use similar technologies to create a VM farm for large-scale virtualization.
For the scope of this room, we will be skipping the step of creating a VM and installing an OS in it. Please note that the VM’s OS needs to be the same as the malware’s target OS for dynamic analysis. In most scenarios, this will be the Windows OS. We will be covering tools related to Windows OS in this room.
Analysis Tools
Once we have a VM with the OS installed, we need to have some analysis tools on the VM. Automated malware analysis systems have some built-in tools that analyze malware behaviour. For example, in Cuckoo’s sandbox, cuckoomon is a tool that records malware activity in a Cuckoo sandbox setup. In the coming tasks, we will learn about some tools to perform manual dynamic analysis of malware. Once we have our required tools installed on the VM and before running any malware on the VM, we must take a snapshot. After analysis of every malware, we must revert the VM to this snapshot, which will hold the clean state of the VM. This will ensure that our analysis is not contaminated by different malware samples running simultaneously.
File-sharing
Different platforms provide different options for sharing files between host and guest OS. In the most popular tools, i.e., Oracle VirtualBox or VMWare Workstation, the following options are common:
- Shared folder.
- Creating an iso in the host and mounting it to the VM.
- Clipboard copy and paste.
Apart from these, there are other, less common options, for example, running a web server on the guest where malware samples can be uploaded or mounting a removable drive to the Virtual Machine. Please note that the more isolated the option to share files, the safer it will be for the host OS. Apart from sharing malware with the VM, the file-sharing option is also used to extract analysis reports from the VM.
Once we have created a VM, set up analysis tools, taken a snapshot, and placed the malware inside our sandbox, we can start analysing our malware. In the next task, we will learn about tools to help us.
Room Answers
~Desktop\Samples\1.exe
using ProcMon. This sample makes a few network connections. What is the first URL on which a network connection is made?What network operation is performed on the above-mentioned URL?
What is the name with the complete full path of the first process created by this sample?
~Desktop\samples\1.exe
creates a file in the C:\
directory. What is the name with the full path of this file?What API is used to create this file?
In Question 1 of the previous task, we identified a URL to which a network connection was made. What API call was used to make this connection?
We noticed in the previous task that after some time, the sample’s activity slowed down such that there was not much being reported against the sample. Can you look at the API calls and see what API call might be responsible for it?
What is the name of the first Mutex created by the sample ~Desktop\samples\1.exe? If there are numbers in the name of the Mutex, replace them with X.
Is the file signed by a known organization? Answer with Y for Yes and N for No.
Is the process in the memory the same as the process on disk? Answer with Y for Yes and N for No.
~Desktop\Samples\3.exe
using Regshot. There is a registry value added that contains the path of the sample in the format HKU\S-X-X-XX-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXX-XXX\. What is the path of that value after the format mentioned here?Video Walkthrough