Memory Games - Volatility

I had a brief introduction to memory forensics, or rather I was pushed into exploring the topic after an interesting conversation with Micrmsoft's own Allison Nixon.

Allison had come across a malware sample that was thwarting VM runtime execution and static code analysis. It was evident after IDA began to loop on a large block of code that this particular sample was packed. This was confirmed with a quick strings search. Besides the Visual Basic ASCII strings, there was no means by which to analyze this sample without patching out the encryption function. Unfortunately, neither of us is at a point where we can handle that just yet so we threw some ideas around. Prior to roping me in, while closely observing the sample (Redacted), she discovered the means by which the VM detection was functioning. After removing the registry entry that was observed (more info to come in a blog from Allison) the sample successfully executed and the VM was infected!

With the sample active in a controlled environment, I suggested that a memory snapshot of the VM environment could be used to carve a copy of the unencrypted sample for local static analysis. This would allow us to bypass the encryption function of the original sample! The awesome thing about VM environments, and VMware Workstation (http://www.vmware.com/products/workstation/) in particular, is the ability to create snapshots which include a ".vmem" file. This file format is very similar to using dd (http://www.forensicswiki.org/wiki/Tools:Memory_Imaging) to dump RAM from a live system, and thus, the open source Volatility Framework (https://www.volatilesystems.com/default/volatility). After creating taking a snapshot of the infected VM to generate the .vmem file I needed, I fired up SIFT (Freely provided by SANS here) to begin my search for the nastiness.



After mounting the shared folder with the memory sample as read only and sharing it with the SIFT VM, it was time to confirm the correct profile necessary for analyzing this particular memory sample:

There's a fair amount of information here, but of primary importance is the "Suggested Profiles" field. This field identifies the appropriate profile to utilize for examining volatile memory samples. In this case, Windows XP SP3 32bit (x86) was utilized as the infected host, and we can see that reflected in the screenshot above. Armed with that information, we can now dive into the memory sample. First up, a listing of processes.

I have opted to use the psscan plugin to enumerate processes by using pool tag scanning. According to MSDN: "The pool tag is a mechanism for identifying the driver or other part of the kernel allocated to a particular portion of memory (Source)." Processes that have been terminated or hidden can be identified by using this method. This particular sample doesn't appear to hide itself very well, as we see that the second listed process (PID 3884) looks a bit unusual (name redacted). Of additional concern is PID 3896 which was identified  as suspicious while the infection process was observed. From here on out, our primary concern will be the investigation of  PID 3884, as it appears to be the same executable that we were unable to perform static analysis upon.

Before we dive more in depth, lets see if there are open internet connections (all protocols) associated with PID 3884 by using the sockscan plugin. Looks like that is a no, at least at the time the snapshot was taken. Volatility has numerous commands to detect network activity, but in this particular instance, they are unnecessary.

Sample output from command: vol.py -f Desktop/VMware-Shared-Drive/D2/D2-Snapshot5.vmem dlllist -p 3884 --profile=WinXPSP3x86

Next, lets try and get a little more information about PID 3884 by looking at the process's loaded DLLs using dlllist. From the snippet above we see a number of loaded DLLs. including "urlmon.dll" and "mswsock.dll" which suggest this sample does have the ability to communicate. However, we didn't see any network connectivity via the sockscan plugin. I suspect that at the time this .vmem file was generated, there wasn't any network connectivity (it was isolated from the internet, with no emulation) and thus internal connectivity checks failed.

Finally, lets extract PID 3884 as an .exe, which was our original goal. By simply specifying the PID (-p) and an output location, Volatility dumps a process's executable and names it according to the PID it was sourced from. The new executable has a new hash value (as would be expected): 

Lets check VirusTotal before we go any further.

Now to compare it against the original file.

That is a pretty substantial difference in detection! The original sample, if identified, is labelled as a dropper component. However, the sample extracted from memory is identified by numerous vendors as a variant of Vobfus aka. W32/Autorun and Changeup. Pretty cool! It looks like we have successfully extracted a sample and worked around its protection mechanism by utilizing the Volatility framework. We also got a bit of additional information from the dlllist plugin as static analysis of the original file was unable to enumerate the PE Imports!