Malware Analysis | Part 1
How to use a number of tools to analyze a memory image file from an infected windows machine
By: David Dodd
Jul. 22, 2014 09:30 AM
Having your network environment protected with the latest virus protection, control what software is installed and allowed to run, restrict ingress and egress network access, protect web browsing, limit user account access, update security patches, change management practices, etc. All these efforts are critical to follow in the corporate environment but all will fall short if you don't have the proper monitoring in place to detect badness on your network and to respond quickly and effectively when it happens. When your network has the proper monitoring in place and knowledgeable engineers to monitor for outbreaks you will begin to have better visibility of how network traffic flows in your environment. When you understand how traffic flows on your network you can respond better when badness happens.
I will demonstrate how to use a number of tools to analyze a memory image file from an infected windows machine. I will demonstrate how to acquire a memory image from a windows machine that is currently running will malware infection and the process of memory analysis using various tools.
To gather an image file from an infected machine can be performed a number of ways. If you have an enterprise version of EnCase you can acquire evidence very fast and from various devices such as laptop, desktop, and mobile devices like smartphones and tablets. For most of us our IT budget is limited and this option is not viable. Using something like F-Response TACTICAL is a solution and requires only two usb sticks. One is labeled TACTICAL Subject and the other is TACTICAL Examiner, you put the Examiner one in the box you are researching malware. Next you put the Subject on the box that is infected with Malware. Below I demonstrate how this is performed with the subject on a windows box (infected with malware) and the examiner installed on a Linux platform (SANS SIFT workstation) to acquire the image.
Once the usb stick is loaded on the windows box install the program so it can listen on its external interface (see Figure #1).
Running the subject program on the infected windows box, remember to enable physical memory
On your SIFT workstation insert the usb stick examiner, make sure it shows up as loaded on your workstation (See Figure #2). Next execute the program f-response-tacex-lin.exe using the following syntax (see Figure #3). Notice that it connects to the following:
Make sure the examiner usb is loaded on the SIFT workstation
Perform the connection between the SIFT workstation and the infected windows box
Next we are going to login to iqn.2008-02.com.f-response.cr0wn-d00e37654:disk-0 with the following command (see Figure #4):
# iscsiadm -m node -targetname=iqn.2008-02.com.f-response.cr0wn-d00e37654:disk-0 --login
Successfully connected to windows box at 192.168.1.129
The iscsiadm command is an open-iscsi administration utility that allows discovery and login to iSCSI targets, as well as access and management of the open-iscsi database. The -m specify the mode which is node it can also be defined as: discoverydb, fw, host iface or session. With the mode selected as node we use the -targetname= and specify the location of the target drive.
After successfully connecting to the remote machine run fdisk -l and see our new device located at /dev/sdd1 (see Figure #5)
Results after running fdisk -l
Next we will mount the partition /dev/sdd1 which is located in the screenshot above (Figure #5) using the following mount command.
# mount -o ro,show_sys_files,streams_interface=windows /dev/sdd1 /mnt/windows_mount
Using the mount command with the -o option: ro - mount the file system read-only, show_sys_files - show all system files as normal files, streams_interface=windows - this option controls how named data streams in WIMfiles are made available with "windows" the named data stream. This will mount the memory from our windows box to /mnt/windows_mount. After changing into that directory and list files you will see the following (see Figure #6)
List of files after mounting the memory from our target windows box following by login to the pmem location
Now we need to login to the process memory of the target which is the pmem location (see Figure #3 ‘F-Response Target = iqn.2008-02.com.f-response.cr0wn-d00e37654:pmem'). We will use the iscsiadm open-iscsi administration utility to perform this task with the following command:
# iscsiadm -m node -targetname=iqn.2008-02.com.f-response.cr0wn-d00e37654:pmem -login
Again we are using the isciadm utility specifying the node with targetname of where the pmem file is located. Now we will run fdisk -l and see the partition tables (see Figure #7).
Results after running fdisk -l notice the HPFS/NTFS system at /dev/sdd1. This is the result after login to the pmem location.
Now we can image the remote systems memory using dc3dd which was developed by Jesse Komblum at the DoD Cyber Crime Center. Dc3dd is similar to dd but allows us to use for forensic work, allowing you to take hashes and split an image all from one command. Open up a terminal and type the following:
# dc3dd if=/dev/sde of=/cases/remote-system-memory8.img progress=on hash=md5 hashlog=/cases/remote-system-memory8.md5
Here is a breakdown of the command:
This will do a forensic copy of the windows memory file to your computer; you can see a screenshot of the progress (see Figure #8).
Performing a forensic copy of the windows memory file using dc3dd
Now that we have an image file of the windows memory we can analysis for existence of malware. There are a couple of tools that you can use one is for the windows platform called Redline by Mandiant which I will be going over in greater detail later. The second tool which is open source is Volatility implemented in Python for the extraction of digital artifacts from volatile memory (RAM) samples. I will be discussing both in very limited bases in this month's article.
If the memory image was acquired from an unknown system and although this was a closed lab environment and I know what system it came from you will need to identify the operation system using Volatility (see Figure #9).
Using Volatility to identify what operation system the dump came from
We use the imageinfo plug-in for Volatility to find out the operation system the memory dump belongs to. Here we see in the suggested profile portion of the output it is a WinXP SP2x86 system, you will need this information to perform more work using Volatility on this memory image file.
To look at the running processes we use the following command:
$ vol.py -profile=WinXPSP2x86 pslist -f remote-system-memory8.img
You can also use the psscan plugin to scan the memory image for EPROCESS blocks with the following command:
$ vol.py -profile=WinXPSP2x86 psscan -f remote-system-memory8.img
Use the psscan to enumerate processes using pool tag scanning that can find processes that previously terminated (inactive) and processes that have been hidden or unlinked by a rootkit (see Figure #10).
Volatility with the psscan invoked
Now for a quick view of Mandiant Redline application we copy the windows memory images off our SANS Investigate Forensic Toolkit (SIFT) and on to a separate Windows workstation where you have Mandiant Redline installed. Next you will analysis your memory image with Redline (see Figure #11).
Loading memory image to be analyzed by Mandiant Redline followed by choosing ‘I am Reviewing a Full Live Response or Memory Image'.
Mandiant Redline is a free tool that provides host investigative capabilities to users and finds signs of malicious activity through memory and file analysis to develop a threat assessment profile. After I infected the test windows box with a known malware variant and allowed the system to react the machine wanted to restart at that moment I acquired a memory image and loaded it into Redline. I then allowed the machine to reboot and took another memory image. The total processes that are running on the system are in Figures #12 (left before reboot & right after reboot).
Total numbers of processes running after installing of malware then list of processes running after reboot
After comparing the two different lists we see that after reboot we have new processes running (jh MRI Score 61 PID - 38533 and svchost.exe MRI Score 61 PID - 1560). MRI Score is the Redline analyzes of each process and memory section to calculate a Malware Risk Index (MRI) score for each process.
Next month I will dive deeper into further information you can learn from analysis of memory images using both Mandiant Redline and Volatility.
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week