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.