Volatility#

Volatility is a memory analysis tool used to extract data from memory files (captured previously). It is built in Python3 and run from the command line. For this page we are using Volatility3, however v2 is still used in the wild as not all of the v2 features are available in v3. Installation instructions can be found here: volatilityfoundation/volatility

As you’re aware (from previous chapters), we should be reading data from a captured memory file. The standard process for execution is vol.py -f [memory file] [plugin] [plugin options]

Plugins#

Volatility uses plugins to extract data. These plugins are OS specific and follow a standard format. To use the ‘info’ plugin example:

windows.info -> The .info plugin for the Windows environment
mac.info -> The .info plugin for the MacOS environment
linux.info -> The .info plugin fo standard Linux environments

These are only the OS specific plugins, but there are others which are not so specific. Some of these are below.

Common Plugins#

The list below is what I have found useful (and what it is useful for). It is not a complete list by any means, simply those that I have focused on previously.

  • windows.pslist : This plugin extracts the details of the processes running on the device at capture time. It only shows those linked so there may be processes hidden which are not shown.

  • windows.psscan : Similar to pslist, this plugin shows running processes. It lists everything using the _Eprocess data structure, so it can show some hidden processes. Unfortunately it can also give false positives.

  • windows.pstree : This plugin shows the pslist extract in a ‘tree’ structure, which allows you to see the parent/child relationships. As with all 3 of the process lists, they are most valuable when you know what is expected. Refer to the WindowsProcess chapter for further information on this.

  • windows.netstat : as with the windows command of same name, this shows active network connections. It’s not really reliable on older OSs though. Bulk-extractor (in Kali) should be used for pcap files in this case.

  • windows.dlllist : so many Ls… This module lists the loaded .dll files. It should really be used during late stage investigation as there will be a lot of files listed.

    • I’ve found this one helpful before

  • windows.malfind : this module shows processes with no memory mapped on disk (file-less malware), or processes with the RWE / RX bit set. RWE is remote wakeup enabled and RX is read-execute. Both of these have legitimate usage, but a good indicators with other evidence.

  • yarascan.yarascan : Runs your yara rules against the memory dump. The rules file needs to be passed as an arguement

    • Full disclosure, I’ve never made this work for me. May be a layer 8 issue.

  • windows.ssdt : The Windows System Service Descriptor Table. Windows uses this to look up system functions and SSDT hooks can modify these functions to point elsewhere. Theres a lot of ‘normal’ here, so this is a more advanced module where you should either be comparing to a baseline of know what you’re looking at.

  • windows.modules : the list of loaded kernel modules. Modules can be missed if they are hidden or idle

  • windows.driverscan : Normally this one has no output.

  • windows.memmap : dumps the memory of a process, so you’ll need to know which one to dump. Pass –pid and the process number, –dump and -o to specify the directory to store the output. You’ll get quite a few files.

    • running strings against the output is a helpful next step

  • windows.handles : dumps the mutex list

    • You’ll want to grep the output

  • windows.filescan : lists the loaded files

    • And again, grep is your friend

I’ve also seen references to modscan, driverirp, callbacks, idt, apihooks, moddump , cmdline & svcscan but havent used them. Leaving them here for next time.