Malware Analyst’s Cookbook and DVD: Tools and Techniques for Fighting Malicious Code (2011)
Chapter 7. Automation
Many of the actions you perform when analyzing malware can be automated. As a general rule, if you find yourself running the same commands over and over again, then it’s probably a good idea to create scripts to automate these tasks. This chapter presents several Python modules that allow you to transfer, execute, and monitor malware in virtual environments such as VirtualBox and VMware. We don’t cover all of the possible actions that you may want to automate, but we’ll show you enough to get started and point you in the right direction for developing your own extensions. If you’re looking for a solution that doesn’t require any programming, this chapter presents some preconfigured environments such as ZeroWine and Buster Sandbox Analyzer.
The Analysis Cycle
Figure 8-1 shows the general steps for creating an automated sandbox, whether you’re working with virtual machines or physical machines. Before starting an analysis, you’ll create a baseline of the system on which you plan to execute malware. The baseline consists of existing files (names, hashes, timestamps), registry contents, memory contents, and so on.
1. Begin in a clean state. If you’re working with virtual machines, you must revert the VM to the baseline snapshot at the beginning of each analysis so you can start with a clean system. If you’re working with physical machines, then this step is where you re-image the machine’s disk with a baseline image (see the Truman and FOG recipes in Chapter 7).
2. Transfer the malware. If you’re working with virtual machines, this step can include copying the file with VMware’s copyFileFromHostToGuest function or simply making the file accessible to the VM by copying it into a shared folder. If you’re working with physical machines, you can copy the malware remotely using PsExec (http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx) or a command line SMB client.
Figure 8-1: cle for automating malware in a reusable sandbox
3. Pre-execution tasks. This step is a placeholder for anything you need to do before executing the malware. It can include setting environment variables on the target machine, starting packet captures or network simulation suites, performing static analysis of the malware sample, and so on.
4. Execute malware. VirtualBox and VMware have command line utilities that you can use to execute a program, such as malware you have transferred, with the privileges of any user on the machine (provided you supply the right credentials). If you’re working with physical machines, you can do the same thing with PsExec.
5. Post-execution tasks. This step is a placeholder for anything you need to do after executing the malware. It can include running any live tools on the infected system to gather evidence, stopping any active packet captures, taking screenshots of the desktop or new windows, and so on.
6. Acquire and analyze RAM. If you’re working with virtual machines, this step involves suspending the VM and accessing its memory file on the host’s file system. If you’re working with physical systems, this step involves dumping memory to a file or straight across the network to your host/analysis machine.
7. Analyze the hard drive. If you’re working with virtual machines, this step involves mounting the VM’s disk on your host operating system to analyze the changes to files, registry hives, event logs, application logs, and so on. If you’re working with physical machines, you can transfer the disk image to your analysis machine using the Truman or FOG setup. This is when your baseline data comes in handy—you can compare the new data with your baseline to see what changed as a result of running the malware.
As previously mentioned, the code on the book’s DVD for this chapter simply provides a Python API and example scripts to get you started—it does not implement a fully-fledged sandbox. The list that follows outlines a few of the resources that you can reference for additional tips and techniques. Although the projects are each unique in their own way, there is no “best” method—it all depends on your goals and how much effort you want to put into customizing them.
· Automating Malware Analysis, Part I and Part II, by Tyler Hudak (published in Hakin9 magazine): Tyler automates VMware using a bash script. You can find more information on Tyler’s blog at http://secshoggoth.blogspot.com/2009/05/automating-malware-analysis-article.html.
· Mass Malware Analysis: A Do-It-Yourself Kit, by Christian Wojner: Describes a sandbox based on VirtualBox and the Purebasic programming language (http://www.cert.at/static/downloads/papers/cert.at-mass_malware_analysis_1.0.pdf)
· Building an Automated Behavioral Malware Analysis Environment Using Open Source Software, by Jim Clausing: Describes Jim’s updates to the Truman framework (http://handlers.dshield.org/jclausing/grem_gold/)
· HIVE: Honeynet Infrastructure in Virtualized Environment, by Davide Cavalca and Emanuele Goldoni: Based on VirtualBox with several bash scripts, Python scripts, and a PHP front end (http://netlab-mn.unipv.it/hive/)
Automation with Python
The recipes in this section assume you are using VirtualBox or VMware on a Linux, Windows, or Mac OS X host operating system. You’ll need Python (version 2.6 or greater is recommended) installed on your host and copies of vmauto.py, analysis.py, and either myvbox.py or myvmware.py (depending on which virtualization product you choose) from the DVD that accompanies this book.
Recipe 8-1: Automated Malware Analysis with VirtualBox
You can find supporting material for this recipe on the companion DVD.
VirtualBox1 is a free, general-purpose virtualizer for x86 hardware. It has many great features that make it suitable for malware analysis, such as a command line interface with bindings in Python, remote access/management, and, of course, all the basics such as host isolation, virtual networking, shared folders, and snapshots. This recipe presents one possible way to build a custom, reusable sandbox based on VirtualBox. You’ll set up a Windows virtual machine (VM) and automate it using the VBoxManage command line utility or the vboxapi Python API (both tools are included with VirtualBox).
Note The VirtualBox SDK includes a file named vboxshell.py, which leverages the vboxapi. It shows some really cool ways to monitor mouse and window movements inside guest virtual machines, take screenshots, and control just about every aspect of a VM using Python.
Initial VirtualBox Setup
The following steps describe how to set up your environment.
1. Install the latest version of VirtualBox. You can get it from the virtualbox.org website or type the following commands into your Ubuntu Linux machine:
$ sudo apt-get install virtualbox-3.2 virtualbox-guest-additions
2. Create a VM running Windows. Boot the VM and configure it as you would configure any sandbox (i.e., leave out identifying personal information, disable the firewall, install any tools you want available for analysis). To use shared folders, you’ll need to install the VirtualBox guest additions by clicking Devices ⇒ Install Guest Additions. Also, set a password for the user account that you’ll use to execute malware and enable automatic login for the user.
3. Create a read-only shared folder. You can do this using the VirtualBox GUI interface, as shown in Figure 8-2. Make sure you check the Read-only option to prevent malware on the VM from making changes to your host. Remember the name you enter for the share because you’ll need to reference it later.
Figure 8-2: Configuring a read-only shared folder
If you prefer the command line, you can add a shared folder with VBoxManage, like this:
$ VBoxManage sharedfolder add "WinXP" \
--name "input" \
--hostpath "/Users/mike/Desktop/vbox/input" \
--readonly
4. Map the shared folder to a drive. Log on to the VM and add a static mapping to associate the shared folder with a drive letter. The easiest way is to open a command shell and type the following:
C:\> net use X: \\vboxsvr\input /PERSISTENT:YES
This will enable you to copy a file into your shared folder and access it within the VM as X:\filename.exe.
5. Record the IP address. While you’re still in the command shell, type ipconfig and record the VM’s IP address so you can distinguish its traffic in packet captures.
6. Take a snapshot. You can do this using the VirtualBox GUI or on the command line. If you choose the command line, supply the name of your VM and a name for the new snapshot.
$ VBoxManage snapshot "WinXP" take "cleanimg"
Oracle VM VirtualBox Command Line Interface Version 3.2.0
(C) 2005-2010 Oracle Corporation
All rights reserved.
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Automation in Python
The vmauto.py file contains a Python class (VBoxAuto) specifically designed for automating malware analysis. We provide the script with the hope that it will simplify the procedure of setting up a custom sandbox and reduce the amount of code you have to write yourself. The VBoxAuto class supports the following methods:
· VBoxAuto(machine): Create an instance of the class that is associated with a VM named machine.
· VBoxAuto.check(): This function returns True if the machine you supplied is valid. Otherwise, it returns False. You can call this function before performing automation tasks, as a sanity check that you’re working with the correct VM.
· VBoxAuto.revert(snapname): Revert the VM to the snapshot named snapname.
· VBoxAuto.start(nsec): Start the VM and wait nsec seconds for the system to boot.
· VBoxAuto.winexec(user, pass, args): Execute a program in the VM that runs under the account user with password pass. The credentials you supply must be valid on the VM. The full path to the program (i.e., malware or monitoring tools) to execute must be the first item in the args array and the path must be accessible inside the VM.
· VBoxAuto.stop(): Stop the VM and power it down.
You can import the VBoxAuto class from your own Python scripts to perform actions in a custom order. In addition, by creating your own script, you can perform any desired tasks before, during, and after executing the malware. The code that follows, which you can find on the book’s DVD in the file myvbox.py, shows an example of using the VBoxAuto class. The script copies each malware sample you want to analyze to the folder shared with the VM. Then the script instructs the VM to execute the sample and allow it to run for a specified amount of time.
#!/usr/bin/python
from vmauto import VBoxAuto
import os, sys, time, shutil
'''
path to shared folder on your host machine where you'll
place malware to be picked up by the guest. this folder
should be shared with read-only permissions
Linux: vbox_hostpath = '/home/mike/vbox'
Mac OS X: vbox_hostpath = '/Users/mike/Desktop/vbox'
Windows: vbox_hostpath = 'C:\\Users\\mike\\Desktop\\vbox'
'''
vbox_hostpath = '/Users/mike/Desktop/vbox/input'
# path to shared folder on your guest machine. this will
# always be in the form \\vboxsvr\YOURSHARENAME
vbox_guestpath = '\\\\vboxsvr\\input'
def main(argv):
if len(sys.argv) != 2:
print 'Usage: %s <file>' % argv[0]
return 0
# select your VM to work with
vm = VBoxAuto('WinXP')
if not vm.check():
print 'Error initializing'
sys.exit()
file = sys.argv[1]
# copy the malware to the shared folder
try:
shutil.copy(file, vbox_hostpath)
except Exception, e:
print 'Cannot copy: %s' % e
return
try:
# revert the VM to a clean state
vm.stop()
vm.revert('cleanimg')
# start the VM
vm.start()
# do pre-execution analysis here
# execute malware in the VM using the account 'hal'
vm.winexec(
'hal',
'password',
["%s\\%s" % (vbox_guestpath, os.path.basename(file))]
)
# do post-execution analysis here
except Exception, e:
print e
return
if __name__ == '__main__':
main(sys.argv)
As you can see, we only marked where to place your pre-execution and post-execution analysis tasks. The rest is up to you to implement, but in the remainder of this chapter, you’ll learn about a variety of techniques and tools to include. On the other hand, you might not want to add anything else. In fact, the myvbox.py script is perfect if you just want a simple reusable sandbox for capturing network traffic and observing which windows (if any) malware samples create when executed.
Assuming you have placed malware samples in the ./samples/ directory, you could use the script in the following manner:
$ for i in 'find ./samples/ -type f'; \
do sleep 5; \
python myvbox.py $i; \
done
[INFO] Using WinXP (uuid: 25037e79-c677-4fa1-abb1-18a73493009e)
[INFO] Session state: Open
[INFO] Machine state: Running
[INFO] Powering down the system
[INFO] Reverting to snapshot 'cleanimg'
[INFO] Waiting 20 seconds to boot...
[INFO] Executing '\\vboxsvr\input\brakecodec4348.exe' with args ''
[INFO] Process ID: 1992
[INFO] Using WinXP (uuid: 25037e79-c677-4fa1-abb1-18a73493009e)
[INFO] Session state: Open
[INFO] Machine state: Running
[INFO] Powering down the system
[INFO] Reverting to snapshot 'cleanimg'
[INFO] Waiting 20 seconds to boot...
[INFO] Executing '\\vboxsvr\input\e93f6755e0c7e26.exe' with args ''
[INFO] Process ID: 172
[REMOVED]
Figure 8-3 shows how your setup should appear. A video covering all of the steps in this recipe, including how to set up VirtualBox and use myvbox.py, is included on the DVD.
As you can see in Figure 8-3, the traffic generated by malware in the VM shows up in Wireshark (which is running on the host). At the same time, you can see the window that the malware created in the VM. When the script is done analyzing all of the malware in your directory, you can save the packet capture in Wireshark to a file. However, you won’t be able to distinguish which samples created the requests, since all traffic is combined into one file. This may or may not be an issue, depending on your goals. If you need to create separate packet captures for each malware sample, see Recipe 8-4.
Figure 8-3: Automating malware analysis in VirtualBox on Mac OS X
Note The Minionz2 tool by the Australian Honeynet Project automates VirtualBox guests by providing a Perl wrapper around VBoxManage. Instead of using a read-only shared folder to transfer malware into the guest, the project’s authors use the mkisofs command to build an ISO image containing the malware and an autorun.inf file. Then they connect the ISO image to the running VM’s CD-ROM. Minionz uses a daemon (continuously running process) that waits for you to move samples into the input directory and then chooses an available VirtualBox VM if you have more than one.
1 http://www.virtualbox.org
2 http://honeynet.org.au/?q=node/10
Recipe 8-2: Working with VirtualBox Disk and Memory Images
The final steps in the analysis cycle diagram from Figure 8-1 involve accessing the memory and file system of the target machine. The best way to analyze these two resources is by mounting them read-only from the host system while the target machine is suspended or powered down. VirtualBox stores the VM’s disk file and memory file in a proprietary format on the host with .vdi and .sav extensions, respectively. This recipe describes the challenges associated with the disk and memory files and gives you some pointers for overcoming the challenges.
VirtualBox Disk Images
Analyzing VDI files is problematic, because few tools understand VirtualBox’s proprietary header format. The “All about VDIs”3 tutorial on the VirtualBox forum describes the header format for VDI v1.1. Here is an example of the fields:
$ xxd WinXP.vdi
0000000: 3c3c 3c20 5375 6e20 5669 7274 7561 6c42 <<< Sun VirtualB
0000010: 6f78 2044 6973 6b20 496d 6167 6520 3e3e ox Disk Image >>
0000020: 3e0a 0000 0000 0000 0000 0000 0000 0000 >
0000030: 0000 0000 0000 0000 0000 0000 0000 0000
0000040: 7f10 dabe Image signature
0100 0100 Version (1.1)
9001 0000 Header size (0x190)
0100 0000 Type (Dynamic VDI)
0000050: 0000 0000 Image flags
0000 0000 0000 0000 0000 0000 Description
[REMOVED]
With early versions of VirtualBox (circa 2008), it was possible to mount VDI files on the host operating system with a utility called vditool. VirtualBox has since replaced vditool with VBoxManage, but the functionality to mount VDI files was lost in the transition. Further, the format of VDI files has changed since the creation of vditool, so even if you found a copy of the tool, it wouldn’t help you mount VDI images from recent versions of VirtualBox.
Note You can find more information regarding vditool and VDI images at the following locations:
· Hogfly’s VirtualBox and Forensics Tools Blog Post4
· The Mounting .vdi on host post on the VirtualBox forums5
· The online repository of VirtualBox Open Source Edition (OSE) source code—in particular the ImageMounter module6
The proprietary format of disks is not only an issue when it comes to conducting automated analysis, but it’s also an issue for forensic investigators who need to extract files from an infected VM (without powering it on). VirtualBox, VMware, Parallels, VirtualPC, and other products all use different headers, formats, and techniques for storing disk images. A work-around involves converting the proprietary disk file into a format that forensic tools and system administration tools can understand. For example, you can convert VDI images to a dd-style (raw) disk image with the clonehd feature of VBoxManage. Then you can mount the disk using the NTFS-3g module (this allows you to mount NTFS drives in Linux), which should already be installed on your Ubuntu system.
Here is the syntax and example usage for the clonehd command:
VBoxManage clonehd <uuid>|<filename> <outputfile>
[--format VDI|VMDK|VHD|RAW|<other>]
[--variant Standard,Fixed,Split2G,Stream,ESX]
[--type normal|writethrough|immutable]
[--remember] [--existing]
$ VBoxManage clonehd WinXP.vdi WinXP.dd --format RAW
Oracle VM VirtualBox Command Line Management Interface Version 3.2.0
(C) 2005-2010 Oracle Corporation
All rights reserved.
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone hard disk created in format 'RAW'. UUID: 06d1cd17-025c-494[REMOVED]
After converting the VDI to a raw image, you can use fdisk or the mmls command from the Sleuth Kit (see Chapter 10) to find the location of the NTFS partition within the disk image. The following output shows that the NTFS partition starts at sector 63 and each sector is 512 bytes.
$ mmls WinXP.dd
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors
Slot Start End Length Description
00: Meta 0000000000 0000000000 0000000001 Primary Table (#0)
01: ----- 0000000000 0000000062 0000000063 Unallocated
02: 00:00 0000000063 0020948759 0020948697 NTFS (0x07)
03: ----- 0020948760 0020971519 0000022760 Unallocated
If you multiply 63 × 512 = 32256, you’ll have the offset within the raw image where the NTFS partition begins. Pass that value to the NTFS-3g module like this:
$ sudo mkdir /mnt/vmware/
$ sudo mount -t ntfs -o ro,offset=32256 WinXP.dd /mnt/vmware/
That’s all there is to it. Now you can list the contents of the VM’s disk by typing ls /mnt/vmware. The biggest issue with this method is that you don’t want to be converting the VDI image after each round of automation because it takes far too long. If you don’t mind the delay, then wrap the clondhd, mmls, and mount commands into a script and you’ll be all set.
VirtualBox Memory Images
Analyzing the VirtualBox memory files can be problematic as well. There is a proprietary header on each .sav file. Furthermore, VirtualBox only stores the amount of memory currently in use by the VM to the file. In other words, if you’ve allocated 1GB of RAM for the VM and it’s using only 300MB, then your .sav file will be 300MB. This is good for performance reasons, but not from a forensic analysis perspective. The two options you currently have for analyzing VirtualBox memory images is to run the strings command on the .sav file or use a program on the live VM to dump memory (see Recipe 15-1 for examples) and then copy the dump file to your host system.
3 http://forums.virtualbox.org/viewtopic.php?t=8046
4 http://forensicir.blogspot.com/2008/01/virtualbox-and-forensics-tools.html
5 http://forums.virtualbox.org/viewtopic.php?f=7&t=52&start=15
6 http://www.virtualbox.org/browser/trunk/src/VBox/ImageMounter
Recipe 8-3: Automated Malware Analysis with VMware
You can find supporting material for this recipe on the companion DVD.
VMware is extremely flexible when it comes to automating tasks. There are several existing options for controlling VMware virtual machines from the command line or from your own programs. Here is a summary of the major methods:
· VMware’s VIX7 API provides you full control over guests and includes bindings in C, Perl, and COM.
· VMware’s vmrun command (ships with VMware products), which is based on VIX and provides a majority of the functionality you’ll need to automate tasks
· Pedram Amini’s vmcontrol.py,8 which is part of his “sulley” fuzzing framework. This is a wrapper around the vmrun command—similar to the one we present in the recipe.
Automation with vmrun
Our preference is for the vmrun command because it provides all the capabilities you need to automate malware analysis. Plus, it works with Workstation, Server, Player, ESX, and Fusion. To control VMs with vmrun, you must install VMware Tools on each VM you plan to automate. The syntax for vmrun looks like this:
$ vmrun
vmrun version 7.0.1 build-227600
Usage: vmrun [AUTHENTICATION-FLAGS] COMMAND [PARAMETERS]
AUTHENTICATION-FLAGS
--------------------
These must appear before the command and any command parameters.
-h <hostName> (not needed for Workstation)
-P <hostPort> (not needed for Workstation)
-T <hostType> (ws|server|server1|fusion|esx|vc|player)
for example, use '-T server' for VMware Server 2.0
use '-T server1' for VMware Server 1.0
use '-T ws' for VMware Workstation
use '-T esx' for VMware ESX
use '-T vc' for VMware vCenter Server
-u <userName in host OS> (not needed for Workstation)
-p <password in host OS> (not needed for Workstation)
-vp <password for encrypted virtual machine>
-gu <userName in guest OS>
-gp <password in guest OS>
The required authentication flags vary depending on which VMware product you’re using, but aside from that, the syntax is the same across all products. Here is a brief list of the commands you’ll likely need to use when automating tasks.
POWER COMMANDS PARAMETERS DESCRIPTION
-------------- ---------- -----------
start Path to vmx file Start a VM or Team
[gui|nogui]
stop Path to vmx file Stop a VM or Team
[hard|soft]
suspend Path to vmx file Suspend a VM or Team
[hard|soft]
SNAPSHOT COMMANDS PARAMETERS DESCRIPTION
----------------- ---------- -----------
revertToSnapshot Path to vmx file Set VM state to a snapshot
Snapshot name
GUEST OS COMMANDS PARAMETERS DESCRIPTION
----------------- ---------- -----------
runProgramInGuest Path to vmx file Run a program in Guest OS
[-noWait]
[-activeWindow]
[-interactive]
Complete-Path-To-Program
[Program arguments]
CopyFileFromHostToGuest Path to vmx file Copy a file from host OS
Path on host Path in guest to guest OS
CopyFileFromGuestToHost Path to vmx file Copy a file from guest
Path in guest Path on host OS to host OS
captureScreen Path to vmx file Capture the screen
Path on host of the VM to a local file
The following commands demonstrate how to transfer and execute a malware sample in a VM using vmrun. We assume you are running VMware Workstation, you have a snapshot named cleanimg, and your malware sample is /data/mal.exe. Of course, for automation purposes, you can copy these commands into a script and launch it locally, via SSH, or even as a cron job.
$ export VMX=/vmware/vms/XPSP2.vmx
$ vmrun –T ws revertToSnapshot cleanimg $VMX
$ vmrun –T ws start $VMX
$ vmrun –T ws –gu Administrator –gp mypassword \
copyFileFromHostToGuest $VMX \
/data/mal.exe C:\\mal.exe
$ vmrun –T ws –gu Administrator –gp mypassword \
runProgramInGuest $VMX –noWait \
–activeWindow –interactive C:\\mal.exe
As you can see, you need to supply valid credentials for an account on the VM in order to copy files to the VM or launch programs in the VM. The additional parameters to runProgramInGuest specify that the executed program should be allowed to create windows and interact with users on the desktop (-activeWindow, -interactive), and that vmrun should not wait for the process in the VM to terminate (-noWait).
Automation with Python
The vmauto.py file, which is on the DVD that accompanies this book, contains a Python class (VMwareAuto) that automates the execution of malware inside VMware VMs. The VMwareAuto class supports the following methods:
· VMwareAuto(vmx_path): Create an instance of the class that is associated with the VM whose configuration file can be found at vmx_path.
· VMwareAuto.revert(snapname): Revert the VM to the snapshot identified by snapname.
· VMwareAuto.start(): Start the VM.
· VMwareAuto.setuser(user, pass): Set the credentials for an account on the VM to use for copying files and executing programs.
· VMwareAuto.copytovm(src, dst): Copy the file identified by src (a path on the host) to dst (a path on the VM).
· VMwareAuto.copytohost(src, dst): Copy the file identified by src (a path on the VM) to dst (a path on the host).
· VMwareAuto.suspend(): Suspend the VM.
· VMwareAuto.winexec(exe_path, args): Execute the program at exe_path on the VM and optionally supply arguments args. You must have previously set the user’s credentials by calling setuser.
· VMwareAuto.scrshot(out_file): Take a screenshot of the VM’s desktop and save it to out_file on the host’s file system.
· VMwareAuto.findmem(): Find the virtual memory file (.vmem) associated with the VM.
· VMwareAuto.stop(): stop a VM and power it down.
The following code shows how to use the VMwareAuto class from your own Python script. The code accomplishes the same tasks as the sequence of vmrun commands shown earlier in the recipe.
#!/usr/bin/python
from vmauto import VMwareAuto
# select your VM to work with
vm = VMwareAuto('/data/WinXP.vmx')
# revert to the snapshot
vm.revert('cleanimg')
# start the VM running
vm.start()
# set the user and password
vm.setuser('Administrator', 'mypassword')
# copy the malware to a path on the VM
vm.copytovm('/data/mal.exe', 'C:\\mal.exe')
# execute the malware
vm.winexec('C:\\mal.exe')
The next few recipes show you how to extend your script to include packet captures, simulated Internet, and memory analysis. Recipe 8-7 shows an updated version of the code with many of the additional features.
7 http://www.vmware.com/support/developer/vix-api/
8 http://code.google.com/p/sulley/source/browse/trunk/vmcontrol.py
Adding Analysis Modules
So far in this chapter, you’ve learned how to use Python to automate tasks in VirtualBox and VMware virtual machines. Now, we’ll present some additional Python modules that you can use to capture network traffic, enable simulated Internet access, and analyze memory dumps for each malware sample. The code for these modules is within a file named analysis.py on the DVD that accompanies this book. By importing analysis.py into scripts that also use the VirtualBox or VMware APIs, you can perform all the automation and data-gathering tasks from a single script.
Recipe 8-4: Capturing Packets with TShark via Python
You can find supporting material for this recipe on the companion DVD.
In almost all cases, you’ll want to capture network traffic generated by malware that you’re analyzing. As previously mentioned in Recipe 7-2, tcpdump and tshark are two command-line tools that serve this purpose well. This recipe shows you how to use a Python wrapper around tshark (you can create a similar one for tcpdump) to start and stop packet captures, read back the data, and produce statistics about the traffic. Here is an example of the code from analysis.py:
# set this to the path of tshark on your machine
tshark = '/usr/bin/tshark'
class TShark:
def __init__(self, pcap_file):
self.pcap_file = pcap_file
self.proc = None
if not os.path.isfile(tshark):
raise 'Cannot find tshark in ' + tshark
def start(self, iface, guest_ip=None):
pargs = [tshark, '-p', '-i', iface]
pargs.extend(['-w', self.pcap_file])
if guest_ip:
pargs.extend(['-f', 'host %s' % guest_ip])
self.proc = subprocess.Popen(pargs)
def stop(self):
if self.proc != None and self.proc.poll() == None:
self.proc.terminate()
def read(self):
proc = subprocess.Popen(
[
tshark, '-z', 'http_req,tree',
'-z', 'ip_hosts,tree', '-z', 'io,phs',
'-r', self.pcap_file
],
stdout=subprocess.PIPE
)
return proc.communicate()[0]
The TShark class supports the following methods:
· TShark(pcap_file): Create an instance of the class that dumps captured traffic to the file specified by pcap_file.
· TShark.start(iface, guest_ip): Begin capturing packets on interface iface using a filter that only includes traffic sent to or from guest_ip.
· TShark.stop(): Stop capturing packets.
· TShark.read(): Read back the traffic contained within pcap_file, including statistics on IPs, protocols, and HTTP requests.
Before integrating the TShark class into your automated sandbox, you should test it in a Python shell. The following example shows how to listen on the eth0 interface, capture traffic sent to or from 192.168.1.141, save the file to /tmp/my.pcap, and then read back results.
$ sudo python2.6
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
>>> from analysis import TShark
>>> cap = TShark("/tmp/my.pcap")
>>> cap.start("eth0", "192.168.1.141")
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
40
>>> cap.stop()
>>> print cap.read()
[REMOVED]
===================================================================
IP Addresses value rate percent
-------------------------------------------------------------------
IP Addresses 90 0.014359
192.168.1.141 90 0.014359 100.00%
8.8.8.8 40 0.006382 44.44%
91.189.90.40 12 0.001915 13.33%
63.245.209.93 10 0.001595 11.11%
96.17.106.105 28 0.004467 31.11%
[REMOVED]
The few commands you entered during the test are the same ones you can use to extend your VirtualBox and VMware automation scripts. If you need extra flexibility regarding statistics or filtering, you just need to modify the TShark class. However, the default code is enough to save the packets to a file. Once this is done, you can get additional information in the following ways:
· Scan the pcap file with the Snort IDS (see Recipe 7-2).
· Analyze the pcap file with chaosreader.pl9 or pcapline.py10 (these tools generate an HTML report from conversations in the packet capture).
· Scan the pcap file with Jsunpack-n (see Recipe 6-13) to extract JavaScript and detect attempts to exploit vulnerabilities.
See Recipe 8-7 for an example of a finished automation script that utilizes the TShark class.
9 http://chaosreader.sourceforge.net/
10 http://www.mcgrewsecurity.com/2010/07/09/pcapline-py-and-the-anns-aurora-network-forensics-challenge/
Recipe 8-5: Collecting Network Logs with INetSim via Python
You can find supporting material for this recipe on the companion DVD.
Recipe 7-3 discussed how to install and configure INetSim so that you can contain network traffic within an isolated environment. The following code from analysis.py shows a simple way to start and stop INetSim during each round of automation so that it stores the log files in a malware-specific directory.
# set this to the path of inetsim on your machine
inetsim = '/data/inetsim/inetsim'
class INetSim:
def __init__(self, outdir):
self.outdir = outdir
self.proc = None
if os.name != "posix":
raise 'InetSim is only available on Posix systems'
if not os.path.isfile(inetsim):
raise 'Cannot find inetsim in ' + inetsim
def start(self):
self.proc = subprocess.Popen(
[
inetsim,
'--log-dir', self.outdir,
'--report-dir', self.outdir,
],
cwd=os.path.dirname(inetsim),
stdout=subprocess.PIPE,
stdin=subprocess.PIPE
)
def stop(self):
if self.proc != None and self.proc.poll() == None:
self.proc.terminate()
def read(self):
outp = ''
svclog = self.outdir + '/service.log'
if os.path.isfile(svclog):
outp += open(svclog).read()
for f in glob.glob(self.outdir + '/report.*.txt'):
outp += open(f).read()
return outp
The INetSim class supports the following methods:
· INetSim(outdir): Create an instance of the class that writes service logs and debug logs to the directory Specified by outdir.
· INetSim.start(): Begin the Internet simulation suite.
· INetSim.stop(): Stop the Internet simulation suite.
· INetSim.read(): Gather the service logs from outdir and print the results for reports.
Before using the INetSim class, you can test its functionality in a Python shell. Of course, you’ll need to already have INetSim installed and configured (see Recipe 7-3). The following commands show how to begin the simulation suite and save logs to /auto/reports. The amount of time between when you start and stop the simulation is up to you.
$ sudo python2.6
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
>>> from analysis import INetSim
>>> net = INetSim("/auto/reports")
>>> net.start()
>>> net.stop()
>>> print net.read()
[redirect 3757] [192.168.1.99:1197] Redirecting tcp connections \
from host '192.168.1.99' (00:0c:29:1d:f8:40), \
destination changed from '72.246.30.26:80' to '192.168.1.127:80'.
[http 80/tcp 3806] [192.168.1.99:1197] connect
[http 80/tcp 3806] [192.168.1.99:1197] recv: GET / HTTP/1.1
[http 80/tcp 3806] [192.168.1.99:1197] recv: Host: msn.foxsports.com
[REMOVED]
As you can see, the output of the commands show that 192.168.1.99 (the IP address of our VM) attempted to contact msn.foxsports.com. However, INetSim redirected the HTTP request to 192.168.1.127:80 (the IP address of the server running INetSim). Using simulated Internet is the safest way to see network traffic from the malware and get actual responses without putting your system at risk by letting it communicate with the real Internet. In some cases you may have to use a simulation suite to capture network activity (for example, when the real servers are offline or unreachable). The example in Recipe 8-7 shows an automation script that implements the INetSim class.
Recipe 8-6: Analyzing Memory Dumps with Volatility
You can find supporting material for this recipe on the companion DVD.
You can automate Volatility to analyze memory dumps that you captured from virtual or physical machines. This section doesn’t go deep into memory analysis because that’s covered extensively in the final four chapters of this book. Anything discussed in those four chapters can be automated. The following code from analysis.py shows a simple wrapper around some basic Volatility commands that you can use to get started.
# path to volatility on your machine
volatility = '/auto/volatility/volatility'
# path to python on your machine
python = '/usr/bin/python'
class Volatility:
def __init__(self, mem_file):
self.mem_file = mem_file
def run_cmd(self, cmd, args=[]):
pargs = [python, volatility, cmd, '-f', self.mem_file]
if len(args):
pargs.extend(args)
proc = subprocess.Popen(pargs, stdout=subprocess.PIPE)
return proc.communicate()[0]
def pslist(self):
return self.run_cmd('pslist')
def sockets(self):
return self.run_cmd('sockets')
def conns(self):
return self.run_cmd('connections')
def malfind(self, rules, outdir='.tmp'):
args = ['-d', outdir]
if os.path.isfile(rules):
args.extend(['-y', rules])
return self.run_cmd('malfind2', args)
def hooks(self, outdir='.tmp'):
args = ['-d', outdir]
return self.run_cmd('apihooks', args)
The Volatility class supports the following methods:
· Volatility(mem_file): Creates an instance of the class that analyzes the memory file specified by mem_file.
· Volatility.pslist(): Prints the list of active processes from the memory dump.
· Volatility.sockets(): Prints the list of network socket objects in the memory dump.
· Volatility.conns(): Prints the list of connection objects in the memory dump.
· Volatility.malfind(rules, outdir): Scans the memory dump for hidden and injected code. Use the YARA signatures in the rules file and save any malicious memory segments to the directory specified by outdir.
· Volatility.hooks(outdir): Scans the memory dump for API hooks installed by rootkits; saves the memory segment containing the rootkit code to a directory named outdir.
As with the other modules you’ve learned about in this chapter, you should test the Volatility class before using it in your automation scripts. The following commands show how to print the processes and connections from a memory dump you have saved in /data/WinXP.vmem.
$ sudo python2.6
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
>>> from analysis import Volatility
>>> vol = Volatility("/data/WinXP.vmem")
>>> print vol.pslist()
Name Pid PPid Time
System 4 0 Thu Jan 01 00:00:00 1970
smss.exe 612 4 Wed Dec 09 20:29:49 2009
csrss.exe 660 612 Wed Dec 09 20:29:50 2009
winlogon.exe 684 612 Wed Dec 09 20:29:50 2009
services.exe 728 684 Wed Dec 09 20:29:50 2009
lsass.exe 740 684 Wed Dec 09 20:29:50 2009
[REMOVED]
>>> print vol.conns()
Local Address Remote Address Pid
192.168.104.129:1054 96.6.124.82:80 1376
192.168.104.129:1053 96.6.124.82:80 1888
Recipe 8-7 shows another example of how to implement the Volatility class into your automation scripts.
Recipe 8-7: Putting all the Sandbox Pieces Together
You can find supporting material for this recipe on the companion DVD.
The automation APIs presented thus far in the chapter are written to be as flexible as possible so that they work on multiple host operating systems. In Recipe 8-1 we presented a script for VirtualBox and showed how to use it on a Mac OS X host. In this recipe, we present a script for VMware and show how to use it on a Linux host. We also leverage the PEScanner API from Recipe 3-8 and the VirusTotal API from Recipe 4-4 to perform some static analysis of the malware before executing it in the VM. The following code from myvmware.py, which is on the DVD that accompanies the book, displays how all of the components work together:
#!/usr/bin/python
from vmauto import VMwareAuto
import os, sys, time, analysis
import hashlib, shutil
from avsubmit import VirusTotal
from pescanner import PEScanner
# path to where report data will be stored
# the directory must exist, but a subdirectory
# will be created with the md5 of your malware sample
report_path = "/auto/reports"
# name of the clean snapshot
snapname = 'cleanimg'
# credentials for the user account on the guest VM
# that you will use to execute malware
user = 'Administrator'
passwd = 'password'
# ip address for the guest (assuming you know it
# and its static. used to scan with nmap)
guest_ip = '192.168.1.99'
# path to your vmware guest's VMX configuration file
guest_vmx = '/auto/MalwareAnalysis/WinXP.vmx'
def printhdr(name):
print '#' * 75
print '# ' + name
print '#' * 75
def analyze(vm, sample, rdir, inetsim):
# scan the sample with the PEScanner module
printhdr('Submission Details')
pescan = PEScanner([sample])
pescan.collect()
# submit the sample to VT and print results
printhdr('Antivirus Results')
vt = VirusTotal(sample)
detects = vt.submit()
for key,val in detects.items():
print " %s => %s" % (key, val)
# revert the VM to its clean snapshot
vm.revert(snapname)
vm.start()
time.sleep(15)
# set the credentials for tasks in the guest VM
vm.setuser(user, passwd)
# copy the malware sample to the VM's hard drive
dst = 'C:\\%s' % os.path.basename(sample)
vm.copytovm(sample, dst)
# start a packet capture on the host
pcap = analysis.TShark(rdir + '/file.pcap')
pcap.start('eth0', guest_ip)
# start INetSim for simulated Internet.
if inetsim:
inet = analysis.INetSim(rdir)
inet.start()
# execute the malware in the guest VM, let it run
# for one minute
vm.winexec(dst)
time.sleep(60)
# take a screen shot of the guest VM's desktop
vm.scrshot(rdir + '/shot.bmp')
# suspend the VM
vm.suspend()
# stop INetSim and print the captured logfiles
if inetsim:
inet.stop()
logs = inet.read()
if len(logs):
printhdr('Inetsim Logs')
print logs
# stop TShark and print the traffic statistics
printhdr('Network Traffic')
pcap.stop()
print pcap.read()
printhdr('Memory Analysis')
vol = analysis.Volatility(vm.findmem())
print vol.pslist()
print vol.conns()
print vol.sockets()
print vol.hooks()
print vol.malfind('/auto/yara.rules', rdir + '/mal')
def main(argv):
if len(sys.argv) < 2:
print 'Usage: %s <file> [--inetsim]' % argv[0]
return
if sys.argv[len(sys.argv)-1] == "--inetsim":
inetsim = True
else:
inetsim = False
vm = VMwareAuto(guest_vmx)
if os.path.isfile(sys.argv[1]):
rdir = report_path + \
os.path.sep + \
hashlib.md5(open(sys.argv[1]).read()).hexdigest()
try:
os.mkdir(rdir)
except:
pass
analyze(vm, sys.argv[1], rdir, inetsim)
else:
print 'You must supply a file to analyze'
return
if __name__ == '__main__':
main(sys.argv)
To enable the use of simulated Internet when you execute malware with myvmware.py, you can call it like this:
$ python myvmware.py filename.exe --inetsim
To skip the use of INetSim and allow malware to connect to the real Internet sites, you can use the following command:
$ python myvmware.py filename.exe
Figure 8-4 shows the automation script in action. On the DVD that accompanies this book, you can find a video (8-7.mov) that narrates the steps for setting up and deploying the script.
Figure 8-4: Automating malware in VMware on Linux
The following output shows an example of the script’s results. For the sake of brevity and to prevent lines from wrapping on the page, we’ve truncated some of the fields.
$ python myvmware.py 1your_exe.exe
################################################################
# Submission Details
################################################################
The PEScanner API generates the following section of the report. It shows file metadata and indicates which (if any) PE header attributes are suspicious.
Meta-data
============================================================
File: 1your_exe.exe
Size: 21504 bytes
Type: MS-DOS executable PE for MS Windows (GUI)
MD5: faf4b8c32b3f43fbb8fcfd538c1bd86f
SHA1: 2847703773e04540dce5bc9ba9903e779672aca3
ssdeep: 384:Rftxm7JVyEK6PM7MirduoE6KBBb8h2nPQVh[REMOVED]
Date: 0x46C14B1A [Tue Aug 14 06:26:34 2007 UTC]
EP: 0x4040f3 (.text)
Resource entries
============================================================
Name RVA Size Type
------------------------------------------------------------
RT_ICON 0x7118 0x130 data
RT_ICON 0x7248 0x2e8 data
RT_GROUP_ICON 0x7530 0x22 MS Windows icon
RT_VERSION 0x7552 0x2ac data
Sections
============================================================
Name VirtAddr VirtSize RawSize Entropy
------------------------------------------------------------
.textbss 0x1000 0x3000 0x0 0.000000 [SUSPICIOUS]
.text 0x4000 0x700 0x800 4.276134
.rdata 0x5000 0x1be 0x200 4.060751
.data 0x6000 0x96 0x200 2.638882
.rsrc 0x7000 0x4191 0x4200 7.117988 [SUSPICIOUS]
.debug 0xc000 0x197 0x200 1.559745
The VirusTotal API generates the following section. It shows the vendors that detect the malware and the name of the malware family.
################################################################
# VirusTotal Results
################################################################
Prevx => Medium Risk Malware
DrWeb => Trojan.Advload.15
GData => Win32:Crypt-GIR
NOD32 => a variant of Win32/Kryptik.EGF
Avast => Win32:Crypt-GIR
Kaspersky => Packed.Win32.Krap.ao
Panda => Suspicious file
Sunbelt => Trojan.Win32.Generic.pak!cobra
AVG => Cryptic.IG
Microsoft => TrojanDownloader:Win32/Harnig.gen!P
The Volatility API generates the following section of the report. It shows the active processes on the machine after executing the malware. Notice how half of the processes started on December 9, 2009, and the rest started on May 26, 2010. December 9 is the date when a snapshot was taken of the VM that we used. May 26 is the date we performed the analysis. Thus, all processes that started on May 26 are artifacts of running the malware.
################################################################
# Memory - Process List
################################################################
Name Pid PPid Time
System 4 0 Thu Jan 01 00:00:00 1970
smss.exe 612 4 Wed Dec 09 20:29:49 2009
csrss.exe 660 612 Wed Dec 09 20:29:50 2009
winlogon.exe 684 612 Wed Dec 09 20:29:50 2009
services.exe 728 684 Wed Dec 09 20:29:50 2009
lsass.exe 740 684 Wed Dec 09 20:29:50 2009
vmacthlp.exe 896 728 Wed Dec 09 20:29:51 2009
svchost.exe 908 728 Wed Dec 09 20:29:51 2009
svchost.exe 992 728 Wed Dec 09 20:29:51 2009
svchost.exe 1084 728 Wed Dec 09 20:29:51 2009
svchost.exe 1132 728 Wed Dec 09 20:29:51 2009
svchost.exe 1192 728 Wed Dec 09 20:29:52 2009
spoolsv.exe 1460 728 Wed Dec 09 20:29:53 2009
explorer.exe 1736 1712 Wed Dec 09 20:29:58 2009
VMwareTray.exe 1828 1736 Wed Dec 09 20:29:59 2009
VMwareUser.exe 1836 1736 Wed Dec 09 20:29:59 2009
jusched.exe 1888 1736 Wed Dec 09 20:30:00 2009
jqs.exe 172 728 Wed Dec 09 20:30:10 2009
VMwareService.e 236 728 Wed Dec 09 20:30:10 2009
wscntfy.exe 1160 1084 Wed Dec 09 20:30:19 2009
alg.exe 1600 728 Wed Dec 09 20:30:19 2009
ivqntxmn.exe 300 1688 Wed May 26 14:26:58 2010
qjqfu.exe 1368 1688 Wed May 26 14:27:01 2010
rundll32.exe 212 300 Wed May 26 14:27:05 2010
bp6x25s.exe 148 216 Wed May 26 14:27:06 2010
nvsvc32.exe 1240 208 Wed May 26 14:27:14 2010
login.exe 1312 208 Wed May 26 14:27:14 2010
2271404242.exe 1144 1736 Wed May 26 14:27:15 2010
avp.exe 1336 208 Wed May 26 14:27:15 2010
IEXPLORE.EXE 1236 908 Wed May 26 14:27:15 2010
setup.exe 1420 552 Wed May 26 14:27:15 2010
avp32.exe 1016 208 Wed May 26 14:27:16 2010
taskmgr.exe 392 552 Wed May 26 14:27:16 2010
install.exe 1936 208 Wed May 26 14:27:17 2010
mdm.exe 1348 552 Wed May 26 14:27:18 2010
win32.exe 1524 1144 Wed May 26 14:27:21 2010
iexplarer.exe 1716 1144 Wed May 26 14:27:22 2010
hexdump.exe 1664 1144 Wed May 26 14:27:22 2010
wmiprvse.exe 1280 908 Wed May 26 14:27:24 2010
vdhtqtftssd.exe 308 808 Wed May 26 14:27:31 2010
cmd.exe 460 236 Wed May 26 14:27:46 2010
The Volatility API generates the next two sections (sockets and connections). Using the Pid column from the process list, you can link the sockets and connections to the process that created them.
################################################################
# Memory - Sockets
################################################################
Pid Port Proto Create Time
1236 1084 6 Wed May 26 14:27:18 2010
1192 1900 17 Wed May 26 02:19:09 2010
476 1061 6 Wed May 26 14:26:56 2010
4 139 6 Wed May 26 02:19:09 2010
740 500 17 Wed Dec 09 20:30:10 2009
1600 1028 6 Wed Dec 09 20:30:20 2009
300 1073 6 Wed May 26 14:27:07 2010
4 445 6 Wed Dec 09 20:29:47 2009
1240 1081 6 Wed May 26 14:27:15 2010
992 135 6 Wed Dec 09 20:29:51 2009
1888 1054 6 Wed May 26 14:26:54 2010
4 137 17 Wed May 26 02:19:09 2010
740 0 255 Wed Dec 09 20:30:10 2009
1084 123 17 Wed May 26 02:19:09 2010
4 138 17 Wed May 26 02:19:09 2010
1132 1041 17 Wed May 26 02:16:03 2010
1084 123 17 Wed May 26 02:19:09 2010
1132 1053 17 Wed May 26 14:26:54 2010
1236 1083 6 Wed May 26 14:27:18 2010
1192 1900 17 Wed May 26 02:19:09 2010
1236 1086 17 Wed May 26 14:27:27 2010
740 4500 17 Wed Dec 09 20:30:10 2009
172 5152 6 Wed Dec 09 20:30:10 2009
4 445 17 Wed Dec 09 20:29:47 2009
148 1076 6 Wed May 26 14:27:07 2010
1736 1080 6 Wed May 26 14:27:11 2010
################################################################
# Memory - Connections
################################################################
Local Address Remote Address Pid
192.168.1.99:1083 94.75.233.243:80 1236
192.168.1.99:1061 72.246.30.91:80 476
192.168.1.99:1084 94.75.233.243:80 1236
192.168.1.99:1076 94.75.233.243:80 148
192.168.1.99:1080 94.75.233.243:80 1736
192.168.1.99:1054 72.246.30.91:80 1888
192.168.1.99:1073 94.75.233.243:80 300
192.168.1.99:1081 85.17.239.20:80 1240
The Volatility API generates the following section on hidden and injected code. It prints the name of the infected process and details on what type of data exists in the memory range. For more information on using Volatility to find hidden and injected code, see Recipe 16-6.
################################################################
# Memory - Injected Code
################################################################
#
# svchost.exe (Pid: 1192)
#
[!] Range: 0x771b0000 - 0x77259fff (Tag: Vad , Protection: 0x7)
PE sections: [.text, .data, .rsrc, .reloc, ]
YARA rule: bankers
Description: Indicates banker / passwd stealer
57 00 69 00 6e 00 69 00 6e 00 65 00 74 00 43 00 W.i.n.i.n.e.t.C.
61 00 63 00 68 00 65 00 43 00 72 00 65 00 64 00 a.c.h.e.C.r.e.d.
#
# explorer.exe (Pid: 1736)
#
[!] Range: 0x02210000 - 0x02211fff (Tag: VadS, Protection: 0x6)
Hexdump:
e9 d9 01 00 00 4d 79 73 74 69 63 20 43 6f 6d 70 .....Mystic Comp
72 65 73 73 6f 72 00 e6 0e 00 00 4f 59 0f f1 00 ressor.....OY...
[!] Range: 0x5df10000 - 0x5df6ffff (Tag: Vad , Protection: 0x7)
PE sections: [.text, .data, .rsrc, .reloc, ]
YARA rule: autorun
Description: Indicates attempt to spread through autorun
Hit: [autorun]
5b 61 75 74 6f 72 75 6e 5d 0d 0a 4f 50 45 4e 3d [autorun]..OPEN=
73 65 74 75 70 53 4e 4b 2e 65 78 65 0d 0a 49 43 setupSNK.exe..IC
#
# IEXPLORE.EXE (Pid: 1236)
#
[!] Range: 0x00e00000 - 0x00e00fff (Tag: VadS, Protection: 0x6)
Hexdump:
8b ff 55 8b ec e9 f5 68 cb 70 00 00 00 00 00 00 ..U....h.p......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Disassembly:
0x00e00000 mov edi,edi
0x00e00002 push ebp
0x00e00003 mov ebp,esp
0x00e00005 jmp 0x71ab68fa
[!] Range: 0x00df0000 - 0x00df0fff (Tag: VadS, Protection: 0x6)
Hexdump:
8b ff 55 8b ec e9 6a 67 cc 70 00 00 00 00 00 00 ..U...jg.p......
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Disassembly:
0x00df0000 mov edi,edi
0x00df0002 push ebp
0x00df0003 mov ebp,esp
0x00df0005 jmp 0x71ab676f
#
# vdhtqtftssd.exe (Pid: 308)
#
[!] Range: 0x00400000 - 0x00478fff (Tag: Vad , Protection: 0x7)
PE sections: [.text, .rsrc, .reloc, ]
YARA rule: fakeav
Description: Indicates fake antivirus program
Hit: AntiVirus_Pro
41 6e 74 69 56 69 72 75 73 5f 50 72 6f 2e 65 78 AntiVirus_Pro.ex
65 22 2c 20 22 57 69 6e 33 32 2f 46 61 6b 65 41 e", "Win32/FakeA
[REMOVED]
The Volatility API generates the following section on hooked API functions. It shows that one of the malware components hooked the functions that Internet Explorer uses to send and receive data (most likely to inspect and/or steal information).
################################################################
# Memory - API Hooks
################################################################
Type Process PID Hooked Func From => To/Instruction
INLINE IEXPLORE.EXE 1236 WSARecv 0x71ab4cb5 => jmp 0xdd6597
INLINE IEXPLORE.EXE 1236 WSASend 0x71ab68fa => jmp 0xdd64fd
INLINE IEXPLORE.EXE 1236 closesocket 0x71ab3e2b => jmp 0xdd6691
INLINE IEXPLORE.EXE 1236 recv 0x71ab676f => jmp 0xdd6446
INLINE IEXPLORE.EXE 1236 send 0x71ab4c27 => jmp 0xdd63d3
[REMOVED]
The TShark API generates the following network traffic summary. It shows a breakdown of the conversations, protocols, and HTTP requests.
################################################################
# Network Traffic
################################################################
192.168.1.99 -> 8.8.8.8 DNS Standard query A aahydrogen.com
192.168.1.99 -> 8.8.8.8 DNS Standard query A bastocks.com
8.8.8.8 -> 192.168.1.99 DNS Standard query response A 195.2.252.156
192.168.1.99 -> 195.2.252.156 TCP 39827 > http [SYN] Seq=0 Len=0
192.168.1.99 -> 195.2.252.156 TCP 37449 > http [SYN] Seq=0 Len=0
[REMOVED]
===================================================================
Protocol Hierarchy Statistics
Filter: frame
frame frames:1094 bytes:619914
eth frames:1094 bytes:619914
ip frames:1093 bytes:619854
udp frames:25 bytes:2295
dns frames:18 bytes:1629
data frames:1 bytes:114
nbns frames:6 bytes:552
tcp frames:1068 bytes:617559
http frames:55 bytes:13790
data-text-lines frames:6 bytes:1727
tcp.segments frames:11 bytes:11873
http frames:11 bytes:11873
xml frames:4 bytes:4736
data-text-lines frames:7 bytes:7137
arp frames:1 bytes:60
===================================================================
IP Addresses value rate percent
-------------------------------------------------------------------
IP Addresses 1093 0.042051
192.168.1.99 1086 0.041782 99.36%
8.8.8.8 18 0.000693 1.65%
72.246.30.91 49 0.001885 4.48%
195.2.252.152 786 0.030240 71.91%
195.2.252.156 73 0.002809 6.68%
192.168.1.112 7 0.000269 0.64%
255.255.255.255 1 0.000038 0.09%
173.208.162.2 3 0.000115 0.27%
94.75.233.243 138 0.005309 12.63%
192.168.1.255 6 0.000231 0.55%
85.17.239.20 9 0.000346 0.82%
91.188.60.10 10 0.000385 0.91%
===================================================================
HTTP/Requests value rate percent
--------------------------------------------
HTTP Requests by HTTP Host 33 0.001342
aahydrogen.com 14 0.000569 42.42%
/ufwnltbz/wzdcjrp.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/fwelcx.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/oriqbjdp.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/yptozgozmu.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/hyfahpxiq.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/imwaic.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/fjnvpk.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/hypwhc.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/rvqxfn.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/kkemu.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/fwevpovto.php?adv=adv448 1 0.000041 7.14%
/ufwnltbz/gnemtrzxsn.php?adv=adv448 1 0.000041 7.14%
bastocks.com 7 0.000285 21.21%
/ufwnltbz/fwelcx.php?adv=adv448 1 0.000041 14.29%
/ufwnltbz/wzdcjrp.php?adv=adv448 1 0.000041 14.29%
/ufwnltbz/imwaic.php?adv=adv448 1 0.000041 14.29%
/ufwnltbz/fjnvpk.php?adv=adv448 1 0.000041 14.29%
/ufwnltbz/fwevpovto.php?adv=adv448 1 0.000041 14.29%
/ufwnltbz/gnemtrzxsn.php?adv=adv448 1 0.000041 14.29%
indll.info 1 0.000041 3.03%
/mn/mn.php?ver=H1 1 0.000041 100.00%
Miscellaneous Systems
This section describes some alternate ways of performing automated malware analysis. If you’re not interested in designing your own solution, the tools in the upcoming recipes (ZeroWine and Buster) may suite your needs because they are more or less preconfigured with the basic necessities for monitoring APIs, detecting changes to the file system and registry, and generating behavior reports.
Recipe 8-8: Automated Analysis with ZeroWine and QEMU
ZeroWine12 by Joxean Koret is an open-source malware sandbox distributed as a pre-built QEMU virtual machine running Debian. The Debian system includes a web interface where you can upload malware samples, which are then executed using Wine. Wine emulates Windows API calls and allows malware to interact with the file system, registry, and network as if it were on a real Windows machine. In debug mode, Wine can log API calls to produce records of the malware’s activity. Additional capabilities include detection of a few anti-emulator and antivirtualization tricks, strings output, and PE file header details.
ZeroWine Tryouts13 is maintained by Chae Jong Bin and based on the original ZeroWine package. It adds several new features to ZeroWine, including an updated QEMU image and the ability to handle PDF files, find previously analyzed reports via checksum, capture packets with tcpdump, and determine changes to the registry and file system.
Both projects can be set up quickly. Including the time it takes to download the package, you can probably get it up and running in less than 10 minutes.
The following steps describe how you can get started with ZeroWine Tryouts.
1. Install QEMU onto the host machine that you’ll use to run ZeroWine. Theoretically, you can use Windows or Mac OS X as a host because QEMU installs on both of those operating systems; however, we’ll continue to use the Ubuntu machine for demonstrations. To initiate the installation you can type the following:
$ sudo apt-get install qemu-kvm
2. Download and extract the archive that contains the pre-built QEMU virtual machine from the ZeroWine Tryouts SourceForge page.
3. Start the QEMU virtual machine using the provided startup script:
$ cat start-img.sh
#!/bin/sh
qemu –hda zerowine.img –boot c –m 1024 –redir tcp:8000::8000 \
–redir tcp:2022::22
$ ./start-img.sh
4. Some processors don’t support KVM (for example, Intel processors without VT technology), and as a result you may run into issues starting QEMU. If this happens, you need to either use a modified version of QEMU that doesn’t use KVM, or convert the QEMU image to a VMware image. If you choose the latter, you still need QEMU installed on your host to perform the conversion, like this:
$ qemu-img convert zerowine.img –O vmdk zerowine.vmdk
You can now open VMware and create a new virtual machine. During the setup procedure, click “use existing virtual disk file” and then select zerowine.vmdk.
5. Boot the virtual machine and log into the console. The usernames and passwords for the two preconfigured accounts are root/zerowine1 and malware/malware1. Use ifconfig to check the machine’s IP address and then visit it on port 8000 using a web browser. You should see the upload form as shown in Figure 8-5.
On the form, you can select how long to let the malware run before performing an analysis and how many seconds to wait before attempting to dump the process’s memory. ZeroWine uses Python ptrace to access the memory segments, which should give you an unpacked copy of the sample. Figure 8-6 shows the page that displays a sample’s results once the analysis is complete.
Figure 8-5: The web interface for ZeroWine Tryouts
Figure 8-6: Viewing the analysis results
Report
This section displays the results of running Wine in debug mode. It shows the API functions and parameters used by the malware during execution.
Call KERNEL32.ExpandEnvironmentStringsW(003548d0 \
L"%systemroot%\\system32\\drivers\\",00370420,00000104) \
ret=00352b02
trace:ntdll:NtOpenProcessTokenEx \
(0xffffffff,0x00000028,0x00000000,0x32fd68)
trace:ntdll:NtAdjustPrivilegesToken \
(0x48,0x00000000,0x32fd80,0x00000010,0x32fd70,0x32fd6c)
Call KERNEL32.VirtualAlloc(00000000,00000058,00003000,00000004) \
ret=00351653
Call KERNEL32.CreateFileW(00380000 \
L"C:\\windows\\system32\\drivers\\jzoucpymqng.sys", \
40000000,00000000,00000000,00000002,00000080,00000000) \
ret=00351772
File Headers
This section displays the results of file type identification (using TrID), packer identification (using PEiD), and PE/COFF header values including imports, exports, and resource directories (via pefile).
----------Imported symbols----------
[IMAGE_IMPORT_DESCRIPTOR]
OriginalFirstThunk: 0x1314
Characteristics: 0x1314
TimeDateStamp: 0x0 [Thu Jan 1 00:00:00 1970 UTC]
ForwarderChain: 0x0
Name: 0x1396
FirstThunk: 0x1000
KERNEL32.dll.RtlMoveMemory Hint[726]
KERNEL32.dll.GetLastError Hint[369]
KERNEL32.dll.GetProcAddress Hint[416]
KERNEL32.dll.VirtualAlloc Hint[897]
KERNEL32.dll.LoadLibraryA Hint[594]
KERNEL32.dll.GetModuleHandleA Hint[383]
File Strings
This section simply displays any human-readable strings extracted from the sample. If the sample was packed, you might not see many strings, but you can download the dumped process (as shown in Figure 8-6) and manually run strings on it if necessary.
Signatures
This section is a stripped-down version of the API logs that you have designated as suspicious. You can preconfigure a list of suspicious terms (as regular expressions) that match DLL names, API names, or any parameters to the APIs. To do so, look in the file /home/malware/zerowine/cgi-bin/calls.py. In the following example output from this section, you can see the API calls that were flagged using the default list of suspicious terms in the calls.py file.
Call user32.FindWindowA(003547b0 "____AVP.Root",00000000) \
ret=003528be
Call advapi32.RegOpenKeyA(80000002, \
00354720 \
"SOFTWARE\\Avira\\AntiVir PersonalEdition Classic",0032fd34) \
ret=003525be
Call KERNEL32.WinExec(00354820 \
"netsh firewall set allowedprogram \"services.exe\" enable",00000000)\
ret=00352ae3
Differences
This section shows differences to the file system and registry caused by the malware. Before running malware, ZeroWine creates a list of files that exist on the emulated Windows drive. It does this by saving the output of ls on the ~/.wine/drive_c and ~/.wine/drive_d directories. After running malware, ZeroWine uses ls again and then determines if any files were added or removed by using the diff command. Before the next analysis, the system extracts /home/malware/backup/backup.tar.gz and overwrites everything under ~/.wine, which restores the file system. In the following example output from this section, you can see that the malware created 15870.exe and jzoucpymqng.sys, then registered the .sys file as a service.
c:/users/malware/Temp/15870.exe
c:/windows/system32/drivers/jzoucpymqng.sys
--- /home/malware/.winebackup/system.reg 2010-03-23 18:18:32.00000000
+++ /home/malware/.wine/system.reg 2010-05-19 18:50:31.000000000 +0200
@@ -20227,0 +20231 @@
+"PendingFileRenameOperations"=str(7):
"\\??\\C:\\windows\\system32\\drivers\\jzoucpymqng.sys\0\0"
@@ -20287,0 +20292,6 @@
+[System\\CurrentControlSet\\Services\\jzoucpymqng.sys] 1274287827
+"ErrorControl"=dword:00000000
+"ImagePath"=str(2):
"\\??\\C:\\windows\\system32\\drivers\\jzoucpymqng.sys"
+"Start"=dword:00000002
+"Type"=dword:00000002
+
Packet Details
In the Wine environment, Windows networking APIs are fully functional. ZeroWine uses tcpdump to capture packets generated by the malware and then displays results on the web page using the –vvv option (extra verbose). You can also download the full pcap file from the analysis page, as shown in Figure 8-6.
ZeroWine and ZeroWine Tryouts can yield some useful information. They combine two interesting technologies (QEMU and Wine) and give you the ability to perform additional tasks with Python scripts. However, the malware is far away from its native environment on this sandboxing platform. You won’t get good results from kernel-level rootkits or be able to capture full system memory dumps.
12 http://sourceforge.net/projects/zerowine/
13 http://sourceforge.net/projects/zerowine-tryout/
Recipe 8-9: Automated Analysis with Sandboxie and Buster
Sandboxie14 is an application for Windows that runs programs in an isolated environment and prevents permanent changes to your computer. The tool is meant to allow secure web browsing and enhanced privacy, but many of its qualities make it suitable for malware analysis. This recipe shows how to use Sandboxie in conjunction with Buster Sandbox Analyzer,15 which provides automated analysis and reporting. Although Sandboxie should prevent changes to the system, we would still recommend running Sandboxie inside a virtual machine in the event a malware sample is able to escape the sandbox.
Sandboxie
The sandbox that Sandboxie creates is similar to a chroot jail on Unix. Programs running in the sandbox are allowed to create files and modify registry keys, but the changes are transparently redirected to a designated location. Here are some noteworthy items about the sandbox:
· Sandboxing the file system. The default sandbox for the Administrator user is a path on a disk, such as C:\Sandbox\Administrator\DefaultBox. If malware attempts to drop a file to C:\WINDOWS\system32\bad.exe, the sandbox will save the file to C:\Sandbox\Administrator\DefaultBox\drive\C\WINDOWS\system32\bad.exe. The same concept applies to files being written to any other path, including remote/networked drives and attempts to write directly to \\.\PhysicalDrive0.
· Sandboxing the registry. The sandbox intercepts attempts to modify the registry. It redirects changes to a registry hive file in the location C:\Sandbox\Administrator\DefaultBox\RegHive instead of using the live registry.
· Sandboxing the network. The sandbox can block Internet access by process name or file name. Alternately, you can use Sandboxie to block all access to the Internet while analyzing malware samples.
· Sandboxing memory and other resources. By dropping privileges on processes as they start, Sandboxie can prevent malware from loading kernel drivers, accessing the memory of another process, changing hardware configuration, and accessing windows that belong to another process.
Buster Sandbox Analyzer
Buster Sandbox Analyzer works on top of Sandboxie and allows manual or automated malware analysis. You can use Buster for the following purposes:
· Change detection. Detect changes to the file system, registry, and network (i.e., open ports) using the logs created by Sandboxie.
· API monitoring. Sandboxie has a feature that allows you to specify a DLL to inject into processes running in the sandbox. Buster leverages that feature, and includes a file named log_api.dll that performs the logging.
· Report generation. Buster includes several heuristics that can interpret Sandboxie’s logs for you and output a non-technical report on the malware’s behavior.
· System investigation. Buster includes a whole suite of utilities that you can use to investigate the system and/or components of the malware that you’re analyzing. It includes a memory explorer, a packet capture explorer, a PE file explorer, a process explorer, a file disassembler, a hash utility, a hex editor, a packer signature scanner, and a strings utility.
Using Sandboxie and Buster
Follow these steps to begin working with the tools:
1. Install Sandboxie and Buster Sandbox Analyzer on your virtual machine (using the download links at the beginning of this recipe). To install Buster, just extract the archive to a location on disk (C:\bsa is recommended).
2. Open the Sandboxie control panel and click Configuration⇒ Edit Configuration. Add the following two lines under the [DefaultBox] location in the Sandboxie.ini file:
InjectDll=c:\bsa\log_api.dll
OpenWinClass=TFormBSA
Figure 8-7 shows how to access the Sandboxie.ini file and how your final changes should appear.
Figure 8-7: Configuring Sandboxie to inject the API monitoring DLL
3. Double click BSA.EXE to open the Buster Sandbox Analyzer application. Enter the path to your sandbox folder, as shown in Figure 8-8, and click Start Analysis.
Figure 8-8: Setting up Buster Sandbox Analyzer
4. Use the Sandboxie control panel to execute the malware sample(s) you want to analyze. Any child processes created by malware will automatically be run in the same isolated sandbox. To select a process, click on the name of your sandbox and choose Run Sandboxed⇒ Run Any Program as shown in Figure 8-9.
5. Let the malware execute as long as you want. In Figure 8-10, you can see that the child processes (sup.exe, cmd.exe, and a_friend.exe) created by the malware were also trapped in the sandbox. One of the executables created a window disguised as Macromedia Flash Player. Furthermore, in Buster’s API logs, you can see that various other files were created on the system.
Figure 8-9: Choosing a process to run in the sandbox
Figure 8-10: Buster records API calls and Sandboxie traps new processes.
6. When you’re done executing the malware, click Sandbox DefaultBox⇒ Terminate Programs in the Sandboxie control panel and click Stop Analysis in the Buster application.
7. To view the reports, click Malware Analyzer in the Buster application (this will display a list of detected behaviors) or click Viewers ⇒ View Report. Figure 8-11 shows how the report appears.
Figure 8-11: Buster’s malware analysis report
As you can see, the report contains information on how to identify the malware sample (including file size, packer, and hashes), a list of the file system changes, and a list of the registry changes. The process and window information is not shown in Figure 8-11, but it is available at the bottom of the report.
The best part about using Sandboxie and Buster is that the system isn’t actually infected. You don’t need to revert your virtual machine to a clean state at this point (unless, of course, the malware escaped the sandbox). If you browse to the sandbox directory as shown in Figure 8-12, all of the dropped files are archived. In fact, you could create a Zip file of all the contents under C:\Sandbox\Administrator\DefaultBox\drive\C after each analysis, which would give you a quick way to collect all files created or modified by the malware.
It is also worth noting that Sandboxie is an excellent resource to use in conjunction with your browser when investigating potentially harmful websites. If your system is successfully exploited through vulnerabilities in your browser, you will be able to grab copies of any malware downloaded to the system. For more information on automating malware analysis with the tools described in this recipe, see the Buster Sandbox Analyzer post16 on the Sandboxie forums or the tutorial on the Raymond17 website.
Figure 8-12: Sandboxie retains all files created during the malware’s execution.
14 http://www.sandboxie.com/
15 http://bsa.isoftware.nl/
16 http://www.sandboxie.com/phpbb/viewtopic.php?t=6557
17 http://www.raymond.cc/blog/archives/2010/07/30/buster-sandbox-analyzer-makes-sandboxie-stronger/