Recently I found myself needing to do some investigations of full memory dumps. This was a pretty untried arena for me, even if it has been on my radar to learn for a while. After a bit of blindly stumbling around I found this article from Volatility-Labs which grounded me and gave me a good starting point to assess a memory dump. So take a peak, certainly there are much deeper techniques for malware analysis from memory, but this process should allow for basic analysis of any memory dump.
First of course we need to collect a memory dump. There are many different tools for this if you want a write up on many of the options check out this article from Marcos Fuentes Martínez comparing acquisition tools. For my testing I chose to use DumpIt from Comae.
With the executable loaded to a flash drive I attached it to the system to investigate. Here I used it with the /T flag to copy the memory in a RAW format.
.\DumpIt.exe /T RAW
After the memory is acquired and taken to the analysis system, the first thing we need to find out is that memory profile we need to use so that our tools known how to read the dump. In this case I will be using the open source tool Volatility to query and analyze the dump. I recommend downloading the standalone executable from their download page to avoid dependency issues. For Volatility the command to run is imageinfo, this should run for a while and then output recommended memory profiles.
Now with a profile in hand we can query some data that any System Admin should be familiar with, running processes and networking activity.
–profile: sets volatility to know how to process the memory dump
-f: designates the file for volatility to ingest (the raw memory file)
pslist: list running processes
netscan: network activity, similar to a netstat on many OS’s
Looking at this data out analyst may be able to notice some oddities, or be able to check with a baseline or the system owner for a list of known good activity from the system. (8443 anyone?)
After querying and inspecting the live data lets take stock of the loaded executables. To do this we will dump all DLL’s and loaded modules.
Here we will use the -D flag to dump the files to an output directory.
dlldump: dump loaded dlls
moddump: dump loaded modules
Next we will use the volatility module malfind to look for code injection in running processes and also dump this to an output directory.
malfind: look for injected shellcode
So now our front line incident responder can confirm that the system has malicious code present in memory and can escalate the case appropriately. Have questions hit me up on twitter @laskow26, and references below: