Analyze Malicious Activity in Memory Using Volatility

Objective

  • Analyze a memory snapshot from a suspected incident

  • Use Volatility to find and correlate suspicious activity in memory

Scenario

The Incident Response Team from your company provided you with a memory snapshot from a machine that was believed to be infected with a virus. Your job is to analyze the memory snapshot and determine if the machine was infected. Locate several unique things that can be used as an Indicator of Compromise.

Scenario

The Incident Response Team believes a variant of the Zeus malware has infected several computers on the company network. Analyze the file zeus.vmem for indicators of compromise.

  1. Unzip Memory Snapshot

    First, unzip the zeus memory capture that has been provided. You will need to change the directory into the \Desktop\Lab Samples folder and then unzip the zeus.vmem.zip. To do this, enter the following commands:

    cd Desktop/Lab\ Samples/

    unzip zeus.vmem.zip

    In Linux you can use the [Tab] button on your keyboard to perform completions to items you are typing into the command line. This can help minimize typos when you're in the command line. Plus, this trick can be used as a shortcut for almost anything you type into the command line, be it commands or locations of files.

    Screenshot

  2. Look for Network Connections

    Now look at the connections that were active by using the following command:

    volatility -f zeus.vmem connscan

    If the output looks like the image below, reference step 3. Otherwise, skip to step 4.

    Screenshot

    The Volatility Framework is an open source memory forensics analysis platform. It can extract digital artifacts from volatile memory (RAM) samples as the system is being used. Volatility supports memory dumps from most operating systems, be they from Windows, Linux, OSX or Android devices. Support for variants of Windows (8, 8.1, Server 2012, 2012 R2), and OSX 10.9 (Maverick) is either already in development or should be soon.

  3. Fix Volatility Edit Box Error

    You may come across an editbox error. This error can occur in the future when working with various distributions that have Volatility loaded. If you did not get an error when you ran the program, skip this step. If you did an Edit Box error, enter the following command:

    sudo rm /usr/lib/python2.7/dist-packages/volatility/plugins/editbox.py

    This command removes the offending python script that throws the error observed in the previous step.

    Screenshot

  4. Look for Network Connections

    Make sure you are still in the /Desktop/Lab Samples directory and run Volatility again on the memory capture if needed:

    No need to run this again if you skipped to this from step 2.

    volatility -f zeus.vmem connscan

    What do you see here?

    There is a connection to port 80 on a remote IP address. Could be bad or benign. In the next step, we will continue to investigate. Take note of the pids for these connections and the remote IP address shown.

    To find connection structures use the connscan argument. This will find artifacts from connections that were active while system memory was being captured.

    Screenshot

  5. Look at Active Processes in Memory Snap

    Use Volatility to look at what processes were running at the time the memory snapshot was taken. to do this, enter the following command:

    volatility -f zeus.vmem pslist

    Do you see anything that seems strange or out of place?

    What is strange is that we see multiple instances of svchost.exe

    Screenshot

  6. Correlate Process ID to Running Process

    Next, determine what specific process was associated with the connection to port 80. You noted that the process ID was 856. We'll run the pslist command again and only look for the string 856:

    volatility -f zeus.vmem pslist | grep 856

    We see that process ID 856 shows an instance of svchost.exe running.

    In Windows, svchost.exe is a generic host process name for services that run from DLLs. In modern implementations of Windows, DLLs cannot be launched directly from Windows itself, they must be called by an executable. Each of these svchost.exe instances are running in order to allow Windows to work with a specifically tied DLL.

    Screenshot

  7. Extract Suspicious Process

    The svchost.exe process made a connection to what seemed to be a possible web server. After doing a little online research on the IP address to this mystery server, you find that it is on various blacklist sites and that the IP is registered in Moldova. Given this information, the process should be extracted into an executable and investigated further. To do this, enter the following command using Process Dump.

    volatility -d -f zeus.vmem procdump -v -p 856 -D /tmp

    IP blacklists are lists of IP addresses that have been reported as being involved in shady to outright malicious activity. Smart admins check these lists from time to time in order to formulate their own custom ACLs to protect their networks. Online you can find blacklists dedicated to blocking botnets, malware and phishing campaigns (among other things).

    In the command line we used the -d parameter to run Volatility in debug mode. This will allow us to look for any errors during the dumping process.

    Screenshot

  8. Extract Suspicious Strings from Memory Image

    While waiting for the company reverse engineer to analyze the executable file (executable.856.exe) that was dumped in /tmp during the last step, you decide to look for any interesting strings in the memory image. To do this, enter the following command:

    strings zeus.vmem > zeus-out.txt

    Minimize your terminal window, double click on the Lab Samples folder on your desktop, then double click on zeus-out.txt to view the file. After viewing, close the file and maximize your terminal window again to continue the lab.

    Screenshot

  9. Extract Suspicious Strings from Memory Image

    Remember the IP address of the remote server we saw earlier (193.104.41.75)? We should pair down the strings a bit and look for instances where that IP address may have been embedded in the executable. It may actually serve to review a couple of lines before and a couple more lines after every instance of the first two octets of that IP address:

    strings zeus-out.txt | grep -B2 -A2 "193.104"

    What do you see? A URL of 193.104.41.75/cbd/75.bro comes up. It turns out, this URL is associated with the Zeus Trojan.

  10. Extract Suspicious Strings from Memory

    Let's see if the word zeus occurs anywhere in memory by entering the following command:

    strings zeus-out.txt | grep -B2 -A2 zeus

    This search turns up some interesting artifacts to include a zip file and an executable file.

  11. Process Interaction with System

    The svchost.exe process seems the most promising lead we have at the moment. We should investigate how it was interacting with the operating system and other system components. Enter the following command and analyze their output and save it to a file:

    volatility -f zeus.vmem handles -p 856 > pid856handles.txt

    Next, view the file:

    less pid856handles.txt

    To page through the document, looking for anything that seems strange or is associated with the Zeus Trojan, press the Spacebar. After some investigation, a mutant named _AVIRA_2108 is found which is definitively linked to the Zeus trojan. Once you have found _AVIRA_2108 press the Q key to exit out of the less process. If you're having trouble finding AVIRA_2108, try piping the previous command to grep, in order to search for it specifically:

    less pid856handles.txt | grep AVIRA_2108

    A mutant, or mutex (short for mutual exclusion) as it is sometimes called, is a process handle. A mutant is legitimately used as a locking mechanism to serialize access to a single memory resource on the system. The process of making each thread wait its turn for ownership of a mutant object prevents multiple threads (or by extension processes) from writing to a specific memory space at the same time. After writing to the shared memory, the owning thread will then release the mutant object so another thread to come along and write to memory in an orderly fashion.

  12. Searching for Code Injection

    Now look for evidence of code injection. According to our research we know that the Zeus trojan injects its code into winlogon.exe. Use the malfind plugin to find evidence of injected code, then grep for winlogon to see if it's included in the result and to find what process ID it is. To do this, enter the following command:

    volatility -f zeus.vmem malfind | grep winlogon

    We find several instances of winlogon with evidence of code injection.

  13. Looking for File Handles in Memory

    After all of the evidence is collected, you are reasonably certain that this computer was infected with the Zeus trojan.

    Now, search in memory for file handles to see if any exist that match our research on Zeus Indicators of Compromise. One such filename to look for would be sdra64.exe. It is the name of the Zeus bot executable that is written to the hard drive. Let's look for that by entering the following command:

    volatility -f zeus.vmem filescan | grep sdra64

    This executable is present.

Congratulations.

Last updated