Jump to content
Nytro

Volatility Workflow for Basic Incident Response

Recommended Posts

Volatility Workflow for Basic Incident Response

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.

dumpit-ex.png

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.

vol1.png

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

vol2.png

vol3.png

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

vol4.png

vol5.png

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

vol9.png

After collecting this data we will scan it using known IOC’s. In this case I used ClamAV, Loki, and SparkCore (In order below). Each of these were able to pick up on the malicious running code.

vol6.png

vol7.png

vol8.png

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:

https://volatility-labs.blogspot.com/2016/08/automating-detection-of-known-malware.html

https://downloads.volatilityfoundation.org//releases/2.4/CheatSheet_v2.4.pdf

https://unminioncurioso.blogspot.com/2019/02/dfir-choose-your-weapon-well-calculate.html

Finding Metasploit’s Meterpreter Traces With Memory Forensics

 

 

Sursa: https://laskowski-tech.com/2019/02/18/volatility-workflow-for-basic-incident-response/

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...