One of the skills I have been learning over the past year and a half or so is memory analysis.
For those of you that don't know the Volatility's Google Code page has made quite a few memory samples available for test analysis. I stumbled upon them this evening, and I figured I'd try to tear one apart for an hour or so, and see where that got me.
The sample I decided to begin with, at random, was the one titled R2D2 (cool sounding name)
For my analysis I used Volatility 2.2 and SANS' Ubuntu SIFT Workstation VM.
Personally I don't like to look at long command lines, so the first order of business during memory analysis is to set up my Volatility environment variables (VOLATILITY_LOCATION & VOLATILITY_PROFILE). Initially the profile (OS/Service Pack/Architecture) is not known, so I settle for setting the location with the following command:
Once the location is set we can start using Volatility! The great news is that Volatility already knows what image we want to analyze because of the variable we just set. The first plugin that should be run during memory analysis is imageinfo. imageinfo provides us with the image's profile, which is a cruicial piece of information when using Volatility. Specifying an image tells Volatility what data structures to expect when parsing the image. To execute the imageinfo plugin you simply type:
Now that we have found the suggested profile we can specify our VOLATILITY_PROFILE environment variable:
Ok, we have handled all the necessary setup, and now it is time to roll up our sleeves and dig into some R2D2 memory analysis. I like to start my analysis looking for low hanging fruit (processes, network connections, services, and drivers). These artifacts are the most tangible artifacts, and we tend to have the most experience with them. I began with the pstree plugin to see a hierarchical view of the processes relative to their parent process:
This sample appears to have no hidden processes.
It is always a good idea to see what network traffic was occurring at the time of the memory capture. The connscan plugin will parse connection information from the image.
Using the output of pstree we see that cmd.exe is a child process of explorer.exe, and it might be nice to see what commands were issued to that cmd shell. One cool plugin is the cmdscan (or consoles for Windows 7 and Server 2008). The cmdscan plugin parses the command history buffer located in csrss.exe (or conhost.exe on Windows 7 and Server 2008), and returns any commands that remain in the memory buffer. Below is the command line usage for the cmdscan:
To enumerate that service information we can check the HKLM\SYSTEM\ControlSet001\Services registry key for the "malware" service's registration details. We have to first find the virtual memory address of the System hive, which we can do using the hivelist plugin.
Once we have the virtual address (0xe1018388) we can enumerate the key ControlSet001\Services\malware using the printkey plugin.
Now we need to learn more about this apparent driver, and maybe even grab a copy of it for ourselves. Using Volatility's svcscan we can gather more information about the "malware" service.
We can perform rudimentary analysis of the driver using the strings utility.
Below is an example of view the ascii strings contained within the malicious file.
NOTE: In the ascii strings output of the malicious driver (winsys32.sys) we find references to the malicious module (mfc42ul.dll).
We perform some quick triage of the dll and notice some strings that indicate HTTP functionality, and we also see a string "C3P0-r2d2-POE" which appears to be the string that got this malware its name.
If anyone has additional details I missed, or has any feedback to improve my methodology it would be greatly appreciated.