Basic Malware Analysis Lab Setup

You are in the middle of an investigation and you recover a sample of the malware used to compromise one of your high valued targets. Now, depending on how mature your IR security strategy/team is in your organization, you as a security analyst or incident handler have 4 options:

1. Hand it over to your malware analysts team
2. Use third party enterprise automated sandbox solutions
3. Contact your On-Demand special IR service to help you with the analysis
4. Or freak out because you couldn’t afford the first three options in the first place, and all you have is Google to find out if anyone has analyzed the same piece of malware already.

The purpose of this post is to provide some basic ideas in order to allow incident responders to feel more comfortable building their own malware analysis lab when budget is a constraint or when the analysis needs to be strictly done in-house.

Also, This post will be the start of my "Analyzing the Predator" series which will go through some beginner steps on how to analyze malware and also show my development in this field. I am always learning new stuff so I hope we can learn together!

Malware Analysis Goals

1. Answer your boss's questions
• What is the impact?
• What is the risk?
2. Understand malware capabilities
3. Provide new IOCs to the investigation
4. Determine if it is commodity malware or a targeted attack (Attribution)

Malware Analysis Technique

1. Static Analysis
• Malware is not executed in order to be examined
• It can go all the way from looking up the file hash online, finding strings, checking functions or headers to disassembling the piece of malware (stare at it, stare at it..)
2. Dynamic Analysis
• Malware is executed in order to be analyzed
• Considered the very next step after a basic static analysis
• Easy and fast way to determine malware capabilities
• Used also with advanced static analysis when the piece of malware has encrypted content and needs to be run in order to show itself.

Malware Lab Standard layout (Basic)

Figure 1: Basic standard layout

• You will need 2 virtual machines ( XP/Win7 and REMnux). I am pretty sure you know who will be the victim and who can play the role of a gateway
• Victim has one virtual network adapter which communicates only with the virtual internal network (Virtualbox default "intnet")
• Gateway has two virtual network adapters (One to communicate with the virtual internal network and another one to talk to the Internet or the host to download the malware sample and then pass it to Victim)
• You can also have Burp running as a transparent proxy on the gateway VM and have full control of the network communications originated from the victim. (That will be part of another post where I will show you how you can take your lab set up to the next level and perform a dynamic analysis responding to malware calling home as if you were the C2)
• DO NOT RUN THIS ON A PRODUCTION ENVIRONMENT

Step I - INSTALL VMs

• Use VirtualBox (Because it is Free)
• Install Windows XP - Victim VM
• Take a snapshot of victim after the installation and call it Fresh
• Install REMnux - Gate VM 
• Update Built-in toollssudo update-remnux full
• Install guest utils:sudo apt-get install virtualbox-guest-utils
• Reboot :sudo reboot now
• Take a snapshot of Gate and call it Fresh-Updated

Step II - NETWORK SETUP

GATE 

• Enable network adapter 1 and attach it to NAT (It will be used to download the piece of malware either from the physical host or the Internet. You should disable the adapter from your shell when you are ready to run the sample of malware in you victim VM to avoid any interaction either with the physical host or the Internet during the infection/analysis )
• Also, just in case you wonder, I am hard-wired to my network and my Adapter type, under Advanced options, is Intel PRO/1000 MT Desktop

Figure 2: Enabling adapter 1 and attaching it to NAT

• Enable network adapter 2 and attach it to Internal Network
• Click on the arrow pointing down to the left of the option Name, and you will be able to select your Internal networks
• By default VirtualBox has intnet already created for you, but since I use intnet for other vms, I create a new unique virtual network called Internal

Figure 3: Enabling adapter 2 and attaching it to Internal network

• Now, start your Gate VM (It might show you a message saying it is Waiting for network configurations. Just wait..)
• Once it shows you the desktop, open a shell and elevate your rights to root ( You can do this or just type sudo on every single command that will configure system settings. My instructions use sudo before any command just in case you forget to do this or skip this step)
  
  sudo -s 

• check if you got an IP assigned to the NAT adapter ( Should be the eth0 interface)
• You can see that only eth0 and lo are active/enabled in your box.
• We have to enable our Internal Network Adapter eth1 (Internal network)


• You can use commands such as ifconfig eth1 up to enable that adapter, but it will not survive a reboot
• Therefore, you will need to edit the interfaces file (/etc/network/interfaces)
  
  sudo vim /etc/network/interfaces

• Once you open the file, you will see that eth0 interface is enabled and receiving an IP via DHCP
• Next, you will have to enable eth1 and assign a static IP to it. Also, remember that eth1 will be the gateway for the VM Victim.
• Make sure your file looks like this after adding eth1 configurations:

Figure 4: Adding eth1 configurations to /etc/network/interfaces

• Next, restart your network services :
  sudo service network restart (ignore "failed to bring up eth1" message) 

• Run ifconfig and check your interfaces (You should have eth1 enabled with the static IP you assigned to it in the interfaces file)

• Configure INetSim
• INetSim allows your vm to simulate common Internet services such as HTTP, HTTPS, FTP, IRC, DNS, SMTP and others.
• This will avoid the sample of malware to call out to a C2 (You don’t want the owner of the C2 to see your VM/house/work talking to his/her server)
• INetSim comes pre-installed in REMnux and these are some Key file locations to keep in mind if you want to customize your INetSim application your way or add more complex features:
• Init.d config file: /etc/default/inetsim
• Main Config :    /etc/inetsim/inetsim.conf
• Reports :            /var/log/inetsim/reports
• Main Log:          /var/log/inetsim/
• Data Files:         /var/lib/inetsim/

• For this setup, you will have to, first, access the Main Config file with sudo rights
  
  sudo vim /etc/inetsim/insetsim.conf 

•  Once you start going down the file with the down arrow key, you will start seeing services that the application supports ( dns, http, https, etc)
• Make sure you have "start_service dns" enable (uncomment that line - delete the # symbol next to it)
•  Then, keep going down the file and  bind the eth1 static address to the services handled by INetSim as shown below in figure 5.

Figure 5: binding eth1 static address to the services handled by INetSim

• In addition, uncomment dns_default_ip  and add the gateway IP in order to resolve all DNS requests from the victim machine to our gateway server
• Make sure start_service dns ,in the Main conf file, is not commented anymore

Figure 6: uncommenting dns_default_ip line and binding it to eth1 static IP

• [OPTIONAL] if you want to avoid malware fingerprinting INetSim:
• Uncomment #dns_default_domainame some.doman and give it a name (Change some.domain to anything)
•  In addition, edit the init.d config file (/etc/default/inetsim) to start INetSim at boot, and to be enable the application:
  
  sudo vim /etc/default/inetsim
  Change ENABLED= 0 to ENABLED=1 
  
• In addition, you have to make sure you create an iptable rule which will redirect new connections to eth1
  Sudo iptables -t nat -A PREROUTING -i eth1 -j REDIRECT

• Restart INetSim:
  sudo /etc/init.d/inetsim restart

• You can check if your gateway INetSim is listening on specific ports:
  
  netstat -an | less

Figure 7: Output showing INetSim  services running/listening on the static IP of eth1

• For now, this will be our basic gate set up, but later in another post, I will show you how you can  use Burp in VM Gate and manipulate the traffic produced by the malware. Also, ApateDNS, a free tool by Mandiant, can be install in our VM Victim to see DNS request made by malware right away and then redirect the traffic to INetSim or Burp.
• Take another snapshot of Gate and call it "Ready" 

VICTIM 

• Enable network adapter 1 and attach to Internal Network
• Make sure you select the new unique Internal network you created "Internal"

Figure 8: selecting internal network to be attached to the only network adapter for Victim

• Start Victim and configure your network adapter:

Figure 9: Configuring the Internal Network adapter to use Gate IP address as its gateway and set a static IP

• As you can see we are statically assigning an IP address that belongs to our 192.168.2.1/24 subnet (Internal Network)
• Gateway = VM Gate eht1 IP address
• We can test if Victim  can ping Gateway and vice versa:

Figure 10: Pinging Gate (Gateway)

Figure 11: Pinging Victim from Gate
  

• Next, check your Routing Table and make sure you see your Gateway IP as a default gateway address. If not, type route add 0.0.0.0 mask 255.255.255.0 192.168.2.1

Figure 12: checking the Routing Table in Victim to make sure we have Gate  as the default gateway

• Test your browser to see if Victim is talking to INetSim

Figure 13: Victim browsing to google.com, and Gate, via INetSim, responding to the request
  

Step III: INSTALL TOOLS

• Before Installing tools on Victim, make sure you do the following to it :
• Uninstall guest additions if installed (You will need Guest additions for when you want to share a folder from your host ONE TIME ONLY to push tools to it, but for this first image, we want to keep it fresh without extra applications)
• Disable updates (XP: Control Panel>System>Automatic Updates>Turn off Automatic Updates
• Disable Firewall
• Disable Pop-up blocking
• Show Hidden Files
• Show protected operating system files
• Change your security and privacy settings in IE to Low or customize it to make it really vulnerable
• Stop IE prompts (i.e. ActiveX Plugins)
• Create a shared folder on your Victim VM in order to be available for your Gate VM ( this is will be helpful to copy malware samples from Gate to Victim ONLY)
• The shared folder, by default will ask you for credentials to access it (This shared folder will be only available in the Internal Network)
• Finally take a snapshot of your Victim VM and call it "Before Tools"

• Victim's ToolKit: (All the following versions below worked well with my old XP)

• ApateDNS v1.0 - Controls DNS responses through an easy-to-use GUI, and redirect traffic to REMnux (You need at least .NET Framework v2.0)
• Autoruns  v13.51- Shows you what programs are configured to run during system boot or login
• Process Explorer V16.1 - It shows you information about which handles and DLLs processes have opened or loaded
• Process Monitor V3.20 (ProcMon) - It shows real-time system, registry and process/thread activity
• CaptureBAT V2.0.0-5574- Monitors the state of a system during the execution of applications and processing of documents
• CFF Explorer x86 version-  Portable Executable (PE) editor
• Dependency Walker v2.2.6000 - Allows you to explore Dynamically Linked Functions
• Exeinfo PE v0.0.4.2 - Provides great information about an executable such as signatures of commonly-used packers.
• FileAlyzer V2.0.5.57- Provides basic PE information and automated unpacking capabilities (UPX and PECompact)
• McAfee FileInsight V2.1 Build 90 - Hex Editor
• Free Hex Editor Neo V6.20 - Another great Hex Editor
• IDA Pro Free V5.0 - Disassembler and debugger
• Md5deep - Windows - Computes hashes, or messages digests, for any number of files recursively
• OllyDbg V1.10 - A 32-bit assembler level analyzing debugger for Windows
• OfficeMalScanner V0.54 - MS Office forensic tool to analyze malicious Office files
• OleDump - Allows you to analyze OLE files (You need Python installed as well)
• Peid V0.95- Another easy quick program to detect type of packer or compiler of an application
• Pestudio 8.54 - Spots malicious/suspicious functionalities of malware. Powerful Parser
• PEView V0.9.9.0- Another good program to examine PE Files
• Regshot V1.9.0 x86 - Allows  you to compare how much your registry entries have changed after running malware
• Rekall V1.5.2 Furka x86 - Memory analysis framework that allows you to acquire memory, analyze memory images, and perform live memory analysis
• Resource Hacker V4.2.5- Used to modify, delete and export resources embedded into a PE File
• Mandiant Memoryze V3.0 - used to dump memory from a Windows system and perform live memory analysis
• Upx V3.91 - Packer - used also to unpack malware packed with UPX
• WinDbg V6.11.1.404- Windows Debugger ( unpacking Malware)
• Wireshark Win32 V1.10.1 - Network protocol analyzer (make sure you have WinPcap V4.1.3 installed)

• Now you can install Guest additions on Victim  ONLY to transfer the toolkit (Easiest and most convenient way to transfer all your tools)
• Next, share the folder where you keep your tools locally (HOST) with Victim VM:
  Devices Tab > Shared Folders> Shared Folder settings

Figure 14: Adding a Shared folder to Victim's Shared Folder List

• Move all your tools to Victim and install the ones that need to be set up (Some tools are just executables that can be run without being installed)
• Remove the shared folder you created mapping a folder in your physical host
• Uninstall Guest Additions from Victim
• Take a snapshot of Victim and name it "Tools Installed" (make sure Guest additions are not installed anymore in Victim and the shared folder removed)
• Now you should be ready to start using your Lab

Step IV: QUICK TEST

• I recommend to read the book "Practical Malware Analysis", and go over its labs. You can download the binaries used in the labs from http://sourceforge.net/projects/labs-encryptzip/ (password: malware)

Materials

• For this quick simple test we are going to use the following:
• Malware Sample: Lab03-01.exe from the Practical Malware Analysis Lab Binaries
• FileAlyzer
• Pestudio
• ApateDNS
• ProcMon
• Process Explorer
• Regshot
• INetSim
• Wireshark

Copy Sample ( Physical Host --> Gate ---> Victim)

• You can either download the binaries straight to your Gate or if you are analyzing a sample that you have locally in your physical host, you can use an http file server.
• (The reason why I use the http file server is because that way I don’t share any folders with my VMs, SSH cannot be done Host-guest via NAT, and I can easily turn on and off my http server just for the download. DO NOT leave it up and running with malware samples ready to be downloaded)
•  I recommend HFS HTTP File Server 2.3i
• You can easily launch the application, drag an executable to the Virtual File System window and all your REMnux has to do is wget to the URL string showing next to the option Open in browser

Figure 15. HFS HTTP File Server

• Go to your Gate VM:
• Test if you can ping your physical host
• If you can't, restart your network service (this happens sometimes when  you wake up your vm or run it from a snapshot with different physical NICs )
  
  sudo service network restart

• Get the malware sample from your file server by typing the following on Gate
  
  wget http://192.168.1.230:8080/lab03-01.exe

• Once you do that, on the HTTP File Server GUI, click:
• Menu>Switch OFF
• Menu> Exit> Don’t Save
• In Gate open the folder being shared by Victim in the internal network (Go>Network>VictimSharedFolder), and move the malware sample to it
• Restore gate to forget what just happened ( easy and clean unmount -I am paranoid)
• Then on your Gate, disable eth0 (NAT adapter)
• This will have Gate communicate with Victim ONLY
  
  sudo ifconfig eth0 down (You might have to do this twice to disable the adapter)

BASIC STATIC ANALYSIS 

•  DO NOT upload files to VirusTotal if you are analyzing malware found in your production environment (malware found in your organization could have been developed specially for your organization and could contain sensitive information about your environment)

• FileAlyzer(victim)
• Launch FileAlyzer, open the malware sample, and get general information:

figure 16: General Option for FleAlyzer

• Check PE Imports and get an idea of the malware capabilities:
• Kernel32.dll (Allows core functionalities such as access and manipulation of memory, files, and hardware)
• This piece of malware is showing only one import. Indicator that this PE file is packed

Figure 17: Malware capabilities

• Pestudio(Victim)
• We can also use this other great tool to automate part of the basic investigation and point out several malicious/suspicious indicators

Figure 18: Malware capabilities

• We can also look at the strings of the malware sample and get more information about what it does
• Interaction with Registry keys
• A domain Name ( possible C2)
• Admin
• An executable that most likely will be dropped when it runs

Figure 19: Suspicious strings

• Scroll down a little bit over the strings and find out more about the malware sample:
• I see a CONNECT  HTTP/1.0 string . Clear indicator that this malware sample sends a GET request to most likely the domain found before
• Interesting VideoDriver and WinVM32- strings

Figure 20:  Suspicious strings

• After running our first tools, we can have a basic understanding of a few of the malware capabilities
• Now, let's see it in action

BASIC DYNAMIC ANALYSIS SETUP 

• ApateDNS(victim)
• This tool will fake a DNS server and capture the DNS request made by the malware ( This will stop malware from connecting to the Internet)
• Since we don’t want the malware to realize that it is being analyzed, we will redirect the calls to Gate which is capable to provide fake network services, through INetSim, pretending to be the C2 and even dropping fake executables.
• When using ApateDNS along with INetSIm, you will have to make a slight change to your adapter
• You have to set the adapter Preferred DNS server to 127.0.0.1
• This will allow ApateDNS to catch the DNS request first before redirecting the traffic to Gate

Figure 21:  Setting adapter's preferred DNS server to 127.0.0.1

• Launch ApateDNS, and set DNS Reply IP to 192.168.2.1 in order to redirect traffic to our Gate
• Next, start the server and test it by pinging google.com from command prompt

Figure 22: ApateDNS configuration ready

Figure 23: Successful Test of ApateDNS

• Now, we can just leave ApateDNS like this, and start setting up other tools before running the malware sample.

• ProcMon(victim)
• Disclaimer:
• Procmon can miss the device driver activity of a user-mode component talking to a rootkit via I/O controls.
• It can also miss hooking procedures such as SetWindowsHookEx
• In order to avoid ProcMon to crash our system due to the amount of system calls that already exist in the XP machine, we have to run procmon only for short period of times. ( basically don’t have it running, capturing events if you are not using it yet)
• In order to do this, click on File and uncheck  Capture Events
• Then, clear all the irrelevant data captured before launching the malware sample
• Edit> Clear Display
• Now your ProcMon GUI should look like this:

Figure 24:  ProcMon after initial configurations

• Now when you are ready to run the malware sample, all you have to do is click on File again and then check Capture Events right before running the sample
• You can also create a filter to monitor the specific name of the piece of malware as a process. This will filter all the other garbage.
• Remember this is just filtering what it captures. You can apply other filters after malware is executed and gather more information
• You can add extra filters such as RegSetValue and WriteFile in order to show changes the malware makes to the filesystem and registry.

Figure 25: Procmon Filtering on our malware sample before running.

• Process Explorer(Victim)
• Launch process explorer
• This tool will be used to gather valuable information of the processes running on victim
• It shows processes in a tree structure with child -parent relationships
• Understand the colors:
• Services = Pink
• Processes = light purple/light blue ( looks purple to me)
• New process = Green
• Terminated process = Red
• Make sure  you pay attention to New processes when you run the piece of malware

Figure 26:  Process Explorer Ready

• RegShot(Victim)
• Open Source registry comparison tool
• All you have to do is take the 1st shot right before you run the piece of malware
• Then, you have to wait until the malware is done making changes to the system in order to take a 2nd  shot
• Finally, when you have 2 regshots, the option Compare will be available to compare both shots

Figure 27: RegShot and its first Regshot

• INetSIm (Gate)
• INetSim, as you know will fake network services and make things more legit for your piece of malware
• In this step, we are just going to check if INetSim is running and if it is listening on all the ports it is supposed to
  
  Netstat -an | less

Figure 28:  INetSim listening on the right ports to fake network services

• Wireshark (Gate)
• Packet capture tool which will gives us more details of the traffic hitting Gate eth1
• We will be able to understand how the piece of malware performs network communications
• Launch Wireshark and then select eth1 as your Capture Interface

Figure 29:  Wireshark Capture Interfaces

BASIC DYNAMIC ANLYSIS: RUNNING MALWARE 

Flow:

1. Gather a first snapshot of the Registry using RegShot  (1st Shot> Shot>) - (Victim)
2. Start Wireshark on eth1 interface (Gate)
3. Start capturing events with Procmon (File> Capture Events) - (Victim)
4. Run Malware

Results

• We can see Process Explorer showing us the malware sample running at the bottom
• I can enable options such as view>Show Lower Pane
• We can see that the malware created a mutex named WinVM32

Figure 30:  Gathering quick information about the process that just started



• I also enabled another options,  view>lowerPaneView>DLLs
• We can see more than what we were able to see while doing static analysis to it.

Figure 31: Process Explorer showing DLLs associated to our malware sample

• Next, we can check ProcMon and start seeing some of the strings we found during the basic static analysis (things are starting to make more sense)
• One interesting first entry is the write file operation. After double-clicking on the path, we can see that Lab03-01.exe wrote 7,168 bytes to C:\Windows\System32\vmx32to54.exe. The size of that file is the same as our malware sample.

Figure 32: ProcMon Findings

 Figure 33:  Malware sample wrote itself to another location

• It is suspicious that it is the same size as the malware sample. Therefore, I checked if they were the same file by simply calculating its MD5 and compare it with our malware sample.

Figure 34:  Comparing MD5s

• We can now say that our malware sample copied itself to that location and changed its name (That name was spotted during string analysis)
•  Analyzing our second entry RegSetvalue, and double clicking on it, it is clear that this is the persistence mechanism of our malware sample. It added that registry entry VideoDriver ( Spotted during our strings analysis too) pointing to the malware sample with a new name.

Figure 35:  Second Entry - RegSetvalue

Figure 36: Persistence Found

• We can now take a Second shot with Regshot  and compare the two shots to confirm the suspicious registry entry:

Figure 37: Regshot Compare Output

• Now, what we can do is take the Operation filters off and see what else we were able to capture

Figure 38: Taking  Operation filters off

• We can see a lot of entries after taking the Operation filters off:
• Network API operations
• Functions/DLLs used by our packed malware such as DNSAPI.dll
• Definitely calling out ( Time to check our Network tools)

Figure 39: more information from the malware activity

• Checking ApateDNS, we can see our malware sample constantly calling out to www.practicalmalwareanalysis.com
• Not signs of sleeping…constantly calling out.. Really noisy…

Figure 40: malware DNS requests

• We can also check our Wireshark pcap and see random data being sent over port 443 ( not SSL traffic though)

Figure 41: Traffic over 443 captured by Wireshark

MALWARE REPORT 

• Even though, we were able to see strings, it seemed to be packed since it was showing only ExitProcess as only import
• The malware wrote itself to another location and changed its name to vmx32to64.exe
• Mutex name also spotted during basic dynamic analysis: WinVMX32
• A persistence mechanism was spotted during dynamic analysis were a registry key was added pointing to the file where the malware copied itself to :
  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\VideoDriver 
• DNS calls were captured by ApateDNS : www.practicalmalwareanalysis.com and non-ssl traffic over port 443 captured by WireShark.

This is all for this post, On my next posts, I will be adding Burp to my analysis and going over other tools that can be used to do more static analysis (a little bit more advanced). I hope you liked it, and it was helpful to those that didn't know how to start their journey to become a Malware Hunter. 

Feedback is appreciated ! .

Wardog Out!