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 blog post, 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.

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.

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.

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:

  • NetName: ENET-XLHOST
  • OrgName: eNET Inc.
  • OrgId: ENET
  • Address: 3000 East Dublin Granville Rd.
  • City: Columbus
  • StateProv:  OH

  • OrgName: Internet Services, Inc.
  • OrgId: TPCM
  • 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 spamhaus.organd 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.

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.

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).

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. VirusTotalis 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.

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.

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

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

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 post, we have only begun to scratch the surface on what you can do when you are hunting malware with memory analysis. Look out for my future post on more memory fun.