When studying malware for network defense, you have two options: static or dynamic analysis. Static analysis requires a deep understanding of executables, low-level programming and the use of specialized tools for reverse engineering. This is generally done in a lab environment with analysts breaking down API calls and casting debugging spells that makes the rest of us feel rather incompetent. In other words, you need some serious skills for static malware analysis. Dynamic malware analysis, on the other hand, requires only an elementary knowledge of APIs and coding in addition to expert level understanding of networking and virtual environments. In today's post, we will focus on the latter, which while seemingly daunting, is surprisingly easy and straightforward as long as you can keep the whole thing in focus as you go about your tasks.
While Static Malware Analysis would yield the most complete understanding of a threat, most of the time, network defenders will need to know what to look for should a system be infected and what the network activity looks like. Dynamic malware analysis provides a relatively quick and easy answer to the most important questions regarding a specific malware threat:
- What does the malware do?
- What is the threat that this malware presents to our environment?
- How do I identify infected systems?
I should note that there are of course tools and scripts all over the Internet that can help you do most of these tasks. I'm sure there might even be a whole application that can complete dynamic malware analysis without having to configure too many things. My approach is focused on understanding what is happening and controlling as many variables as possible. Loading some kind of malware analysis toolbox can definitely make life easier, but I feel that one should know how to do something without relying too heavily on a particular tool.
REQUIREMENTS
As stated above, you will need a very good grasp of networking and a general understanding of APIs and how programs work. While this can be done in a non-virtual environment, it is much easier with tools like VMware ESXi and other virtualization platforms. As such, a clear understanding of how virtualization works is also required.
So, here's a list:
- A hefty system that can run multiple virtual machines.
- Several working virtual machines running the operating system that is being targeted (usually Windows).
- Either a host running Linux (easier) or Windows (harder) or a virtual machine running the same, on the same host.
- Snapshots of the target virtual machines in known good states.
FIRST THINGS FIRST
The first thing to setup is your sandbox. By definition, a sandbox is where you play, but more importantly, it is isolated from your normal working environment. If at all possible, it is best to have your sandbox or virtual machine host separated from your production network. It is not necessary though, but it completely removes the possibility of releasing malware into your production environment and may even be a requirement depending where you work.
For our purposes, we will have a VMware ESXi host running two virtual machines: A plain Windows XP system and a Linux system for analysis. Additionally, the VMWare ESXi host will have a virtual switch that is not connected to a physical network adapter. By default, ESXi will have a virtual switch named "vSwitch0" which is connected to your physical network adapter and is also used for your management network:
Virtual Switch: vSwitch0
--------------------------
Virtual Machine Port Group - VM Network |<-------> vmnic0 (Physical Adapter)
VMKernel Port - Management Network (vmk0) |
Port Group Label: "VM Network" |
Create a new virtual switch named "vSwitch1" that has no physical adapters and add a port group and call it "Malware Network":
Virtual Switch: vSwitch1
--------------------------
Virtual Machine Port Group - VM Network |<-------> No adapters
Port Group Label: "Malware Network" |
VLAN ID: None |
Some of the settings for vSwitch1 one should include:
Promiscious Mode: Accept
MAC Address Changes: Accept
After that is setup, ensure that your virtual machines are setup to use vSwitch1 instead of vSwitch0. You should also add two network cards to your Linux system, one for the Malware Network and one for the regular network. This allows you to do even more dynamic malware analysis by downloading malware components through your Linux system.
Windows XP
----------
Network Adapter 1 = Malware Network
Linux
-----
Network Adapter 1 = Malware Network
Network Adapter 2 = VM Network
Once this is setup, you will have a network that looks like this:
+----------+ +----------+
| Win XP |<--------->| Linux |<-------> NETWORK ACCESS
| Target | | |
+----------+ +----------+
This gives you a lot of flexibility: you can run malware on the Windows XP target and observe the network activity on the Linux system. Additionally, you can quickly access the network from the Linux system for things like DNS lookups and additional code and tool downloads.
THE SETUP
Windows XP is relatively easy to setup, so I won't go into detail for that. There are tons of resources on the 'net to help with that. Linux is also relatively easy, so grab your favorite distribution and get that installed. There are some good software packages and configurations to load for each:
Windows
- Sysinternals Suite (get the whole suite, just in case and install it): http://technet.microsoft.com/en-us/sysinternals/bb842062
- Java (it's a good idea to install it, since most malware these days like it): http://www.java.com/en/download/index.jsp
- Ollydbg (for quick looks): http://www.ollydbg.de
- Wireshark: http://www.wireshark.org/
- Create an administrative account with a password
- Create a non-administrative account
- Install/configure your network defenses*
- DO NOT load the VMware Tools
- Static IP address with Default Gateway and DNS server as the Linux IP address on the Malware Network.
Linux (note that most of these are built-in)
- tcpdump (or wireshark if you like GUIs)
- A kernel that allows routing ("Enable Routing" in most kernel configurations)
- wget
- netcat
- apache (or another web server)
- Static IP address on eth0 with the Default Gateway as the loopback address (127.0.0.1)
- Static route on eth0 pointing to the loopback address
SNAPSHOTS
Once you have a good configuration setup on both, take a snapshot. A snapshot allows you to revert to a known good state, which is important between malware runs. Over the years, I've found that I have to continually adjust my snapshots and have multiple snapshots depending on what I am doing. There is no magic formula for this - you will have to just learn by doing and find that works best for you. For example, I've found that having Diskmon, Process Explorer and Process Monitor running on the Windows system with established filters works for me. Basically if you find that you keep setting things up before running the malware on the target box, you'll want to take a snapshot with those things setup just before you load and run the malware.
Snapshots are not so critical on the Linux system, but your mileage may vary, so take one anyway.
HIDING THE HOUSE
There are breeds of malware that have virtualization detection built in and they may or may not run depending if it detects a virtual environment. If this is a concern, you can modify the .vmx file of your Windows target system and add some parameters that will essentially hide the fact that this is running in a virtual environment. The following lines do this to some extent. Note that there are many ways to detect if you are in a virtual environment, so this is not a 100% solution. For particularly sensitive malware, the only solutions are to go physical or do static malware analysis. Note that I have yet to run into this problem.
isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.disable_directexec = "TRUE"
monitor_control.disable_chksimd = "TRUE"
monitor_control.disable_ntreloc = "TRUE"
monitor_control.disable_selfmod = "TRUE"
monitor_control.disable_reloc = "TRUE"
monitor_control.disable_btinout = "TRUE"
monitor_control.disable_btmemspace = "TRUE"
monitor_control.disable_btpriv = "TRUE"
monitor_control.disable_btseg = "TRUE"
LINUX SETUP
Setting up your Linux environment can vary by distribution, so here are some generalized items to setup:
- tcpdump running constantly and saving to a file. The idea is to capture everything for data collection and further analysis. This should also be running in a different terminal window.
- tcpdump -nn -i eth0 -s1600 -U -w capture.pcap
- Another terminal window that you can use to query the capture.pcap file as needed. For me, I like to see the packets as they come in, so in that terminal window, I run:
- tail -f capture.pcap | tcpdump -nn -r - -vvX
- Note that the above command should be run immediately after starting the tcpdump command.
- Or you can bypass all the tcpdump business by simply running a GUI version of Wireshark.
TESTING ALL SYSTEMS
Once your snapshots are all setup, it's time to do some communication checks.
For this post, we'll assume the following setup:
Windows Target System
---------------------
IP: 10.0.0.1
MASK: 255.255.255.0
GATEWAY: 10.0.0.2
DNS: 10.0.0.2
Linux System (eth0)
-------------------
IP: 10.0.0.2
MASK: 255.255.255.0
GATEWAY: 127.0.0.1
First, on the Windows system, send a ping to 10.0.0.2 and observe the response. On the Linux host, observe the incoming and response ICMP packets in Wireshark or tcpdump windows.
On the Linux system, send a ping to 10.0.0.1 and observe the outbound and response ICMP packets in Wireshark or tcpdump windows.
Next, again on the Windows system, ensure that your tools for monitoring your system (i.e. Process Monitor).
FIRE THE MALWARE
On the Windows system, run the malware. Switch over to your Linux VM and see if any network traffic was generated. The setup above ensures that any DNS queries or connection attempts are captured in the Linux system by pointing all traffic towards the Linux VM. The first thing you will notice is that there is a lot of traffic already captured. This is because Windows is particularly chatty on the network. Review the captured packets and look for any DNS queries (Wireshark filter: "udp.port eq 53") or TCP connection attempts (Wireshark filter: "tcp.flags.syn == 1").
What you do next depends on what happened. First, review the network traffic.
DNS Queries - if there are DNS queries captured:
- Take note of the domain being resolved.
- Revert the Windows target system to the known good state
- Edit the Windows hosts file (C:\WINDOWS\SYSTEM32\drivers\etc\hosts) and add the domain to point to the Linux system. For example, if the domain is "www.abc.com", add an entry to the hosts file like so: "www.abc.com 10.0.0.2"
- Run the malware again.
- Review what happens differently.
- Take note of the IP address being attempted.
- Take note of the port being connected to.
- For example, let's assume it tried to connect to 1.2.3.4 TCP port 8080.
- Create the 1.2.3.4 address on the Linux VM as another loopback interface: ifconfig lo:1 inet 1.2.3.4 netmask 255.255.255.255
- This adds another interface (lo:1) to the system with an IP address of 1.2.3.4.
- Setup a netcat listener on port 8080: nc -n -l -k 8080
- Revert the Windows target system to the known good state
- Run the malware again.
- Review what happens differently.
As you revert the Windows target system and run the malware, observe what happens and see if you can identify what the malware is doing by:
- Analyzing the registry, file, process information collected by the Sysinternals suite
- Review the collected network traffic and identify any second stage downloads or command and control channels.
- Second stage downloads can be downloaded manually by sending the exact GET request observed from the malware.
- Rinse and repeat with the second stage download.
FINAL REPORT
At the end of a dynamic malware analysis task, you should know enough to identify what the malware does to the system, what it does on the network, what sort of threat it presents to your environment and how to find infected systems. This type of information is invaluable to your incident responders.
Thanks for reading this post - I hope it was useful and helps you find your own techniques for dynamic malware analysis. In future iterations of this topic, we'll explore ways to identify and execute malicious JavaScript safely.