Thursday, August 15, 2013

R2D2 Memory Sample Analysis


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


Setup
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:



Analysis
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:


Initially nothing stuck out from the process tree, so I moved on to psxview.  The psxview plugin queries process data structures using 4 or 5 different methods.  The output contains a list of processes, and tells the analyst whether each method was successful in detecting the process or not.  For example, if a process is found using the pslist method (follows the linked list from one EPROCESS structure to another), but not using the psscan method (search for EPROCESS structures regardless of linked list), then it is a good indication the system has been manipulated (possibly by a rootkit using DKOM techniques).  You can use the psxview plugin like so:


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.


It appears there was an established connection from the localhost on local port 1026 to 172.16.98.1 on port 6666.  This connection was established by PID 1956 or explorer.exe (correlated from pstree output).  This connection is suspicious because explorer.exe does not typically make network connections, so this connection lets us know that explorer.exe is probably our process of interest.

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:


In the command history buffer were two commands "sc query malwar" and "sc query malware" (Just what we were looking for!).  It appears the attacker was checking on the registration details for a service named malware.  At this point the service name is a good indicator of malicious activity, but I've seen some pretty strange things in the past.

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.


Looking at the malware service we notice the service's image path was C:\WINDOWS\system32\drivers\winsys32.sys with a start type of 1 which according to Microsoft "represents a driver to be loaded at kernel initialization", or what appears to be the persistence mechanism.

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.


The results show that the driver associated with this service is recognized as \driver\malware.  We can now work toward grabbing a copy of the running driver.  We must execute a driverscan to access the starting memory address of the driver.


Once the address is obtained (0xf9eb4000) we can use moddump to dump the driver at the address specified using the  -b parameter.


We now have a copy of the suspected malicious driver (winsys32.sys), which we can pass to Virus Total (if we think it has been seen before) or our reverse engineers.  I submitted the driver to Virus Total, and it was flagged by 14/35 anti-virus programs as the R2D2 backdoor.


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.


Earlier we found a suspicious network connection coming from explorer.exe.  We know explorer.exe to be a legitimate process, so we may want to look for dll injection as a possible avenue of infection. We can list explorer.exe's loaded modules using the dlllist plugin.


One module (mfc42ul.dll) seems to stand out because its virtual address is so different than other modules (0x10000000 vs 0x70000000).  I am unsure if this is a valid indicator of dll injection or just a coincidence, but I submitted the module to Virus Total, and the dll was flagged as being associated with the same R2D2 backdoor.




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.



That wraps up my analysis of the R2D2 backdoor.  Upon completion of my analysis, I stumbled upon evild3ad's blog post documenting his analysis of the same sample.  Please check it out!

If anyone has additional details I missed, or has any feedback to improve my methodology it would be greatly appreciated.


- Invoke-IR - By Jared Atkinson -