Hunting Malware with Memory Analysis

Jeremy Scott

December 13, 2012 - Posted by Jeremy Scott to Security Insight

Memory analysis is extremely important in incident response, malware analysis and reverse engineering to examine memory of the infected system to extract artifacts relevant to the malicious program. Memory analysis has gained popularity in the context of reverse-engineering malware. Memory analysis can help identify malicious code and explain how the specimen was used on the suspect system.

When performing memory analysis on the suspect system, I try to answer some simple questions in an attempt to identify malicious code:

  • What processes were running on the suspect system at the time memory image was taken?

  • What artifacts of previous processes existed?

  • Are there any active or previous network connections?

  • What is the purpose and intent of the suspected file?

  • Are there any suspicious DLL modules?

  • Are there any suspicious URLs or IP addresses associated with a process?

  • Are there any suspicious files associated with a process?

  • Are there any suspicious strings associated with a particular process?

  • Are there any suspicious files present? Can you extract them?

In this article, we will be performing the memory analysis using the completely open collection of tools called Volatility. Volatility's versatility through the various plugins and ease of use for obtaining basic forensic information for memory image files makes it an invaluable tool in the malware analyst toolbox. While there are other commercially available tools for memory analysis, Volatility is my tool of choice when a memory image file is available.

Assuming we have already done the memory acquisition of the suspect system, the first step is to identify the image file. While you might already know this information, especially if you are the one that performed the memory acquisition, identifying the profile is important when certain plugins may be OS dependent.

describe the image
Figure 1: ImageInfo

The important information that will be used during the rest of the analysis will be the suggested profile: WinXPSP2x86.

To answer the question of what processes were running on the suspect system at the time of the memory acquisition, we will use pslist to list the processes.

describe the image
Figure 2: PSList

As we can see, there were quite a few processes running on the suspect system. At first glance there doesn’t appear to be anything suspicious. However, explorer.exe (PID 1752) has a parent process ID (PPID 1696) that is not listed and has spawned a few other processes. Looking at the PPID column for PID 1752 you can see the processes that were spawned from explorer.exe. The processes that were spawned by explorer.exe are suspicious to me because of the functionality of those processes and there's no need for explorer.exe to need that functionality. Based on this information, we will target explorer.exe for analysis.

Let’s look at the network connections that existed on the suspect system. The connections and connscan commands will identify the active and previous network connections, respectively.

describe the image
Figure 3: Connections

While there were no active connections at the time of the memory acquisition, we can see in the connscan output that several connections were made that are associated with PID 1752. This is odd behavior for explorer.exe. There is no reason for explorer.exe to make network connections to a remote IP. A quick whois of the IP addresses returns:

OrgName: eNET Inc.
Address: 3000 East Dublin Granville Rd.
City: Columbus
StateProv:  OH

OrgName: Internet Services, Inc.
Address: 315 Capitol
Address: Suite 205
City: Houston
StateProv: TX

This in and of itself is not necessarily an indicator of some malicious, but it is still suspicious. Further digging using something like and may yield additional information if the IP addresses are associated with known malicious activity.

Additionally, running sockets and sockscan will show any listening sockets that may have been initiated by a running process.  As suspected, explorer.exe PID 1752 is listed.

describe the image
Figure 4: Sockets

Since we can conclude that explorer.exe (PID 1752) is suspicious, we will start digging into that process to determine the purpose and intent of the process and find any associated files that can give us an indicator of what the malicious code may be.

By using the malfind plugin, we scan the memory image file or a specified process for suspicious executables that might be malware. In this case, running malfind against PID 1752 yields two suspect processes.

describe the image
Figure 5: Malfind

Memory sections marked as Page_Execute_ReadWrite, which allows a piece of code to run and write itself, are indicative of code injection and are easy to identify. Code injection is a very common technique for malware to maintain persistence and ensure that the malicious code continues to run. We’ll actually dump those processes for further analysis using the –D option.

We can see that malfind found two Dynamic Linked Libraries (DLLs).

describe the image
Figure 6: Dumped DLLs

At this point, we could actually take the DLLs that we found and submit them or the md5 hash to to see if it could identify the malware for us. VirusTotal is a free online service that analyzes suspicious files and URLs and provides detection of malware using multiple malware scanning engines. For example:

File Name: process.0x818f5cd0.0x3380000.dmp
Detect Ratio: 6 / 44
Analysis Date: 2012-11-04 21:12:57 UTC

Avast: Win32:Malware-gen
Microsoft: Backdoor:Win32/Caphaw.A
GData: Win32:Malware-gen
VBA32: Trojan.Agent.ovo
Rising: Backdoor.Caphaw!4301
Ikarus: Trojan-Downloader.Win32.Small


File Name: process.0x818f5cd0.0x36e0000.dmp
Detect Ratio: 17 / 44
Analysis Date: 2012-11-04 21:08:11 UTC

MicroWorld-eScan: Trojan.Generic.7997694
nProtect: Trojan.Generic.7997694
TrendMicro-HouseCall: TROJ_GEN.R47CDK1
Avast: Win32:Malware-gen
BitDefender: Trojan.Generic.7997694
F-Secure: Trojan.Generic.7997694
VIPRE: Trojan.Win32.Generic!BT
AntiVir: BDS/Caphaw.A.150
TrendMicro: TROJ_GEN.R47CDK1
Microsoft: Backdoor:Win32/Caphaw.A
GData: Trojan.Generic.7997694
VBA32: Trojan.Agent.ovo
ESET-NOD32: probably a variant of Win32/Agent.COSXJPL
Rising: Backdoor.Caphaw!4301
Ikarus: Trojan-Downloader.Win32.Small
Fortinet: W32/Agent.COSXJPL
Panda: Trj/CI.A


However, let’s continue to use Volatility to see what other information we can find out about the explorer.exe process.

The handles plugin will enumerate the mutant objects for the explorer.exe processes using the –t Mutant option to narrow the search to just the mutant objects. Mutant objects or mutexes as they are more commonly known are global objects that coordinate multiple processes and threads. Mutexes are mainly used to control access to shared resources, and are often used by malware.

describe the image
Figure 7: Mutexes

By using some of the mutex objects in Google queries, we may be able to identify objects that have been seen in other malware or previous malware reports.

Next, we can dump the Virtual Address Descriptor using the vaddump plugin and examine the dumped sections with the strings command. Strings are the plaintext found within the code.

describe the image
Figure 8: VADDump

The following images show some of the interesting strings that I found which contained network connection information complete with host domain.

describe the image
Figure 9: Connection Strings 1

describe the image
Figure 10: Connection Strings 2

This image shows that the malicious code running on our suspect system is in fact the Shylock Trojan.

describe the image
Figure 11: Shylock

So, in this quick analysis, we have been able to utilize Volatility to quickly extract key information about the running suspicious explorer.exe process. This also equips us to further analyze this process as well as other associated processes.

Memory analysis is a powerful technique, and with a tool like Volatility it is possible to find and extract the forensic artifacts from the memory. There is much more that we can do with this memory image. For example, you can use apihooks and then drop into volshell for further analysis to include disassembling the process. As a matter of fact, in this blog, we have only begun to scratch the surface on what you can do when you are hunting malware with memory analysis.

Read more on Solutionary Minds about:

Voted one of the Best Computer Security Blogs 2016
NTT Security (US), Inc. (formerly Solutionary) is a security consulting and managed security services provider. The NTT Security blog is a place for IT professionals to both learn and talk about the latest in IT security and compliance.

Get the NTT Security Blog delivered to your inbox!

Enter your Email:

(We will not share your email or use it for anything else.)