Volatility

 

In this blog:

• What is Volatility?
• Installation. 
• Usage.

What is Volatility?

Volatility is an open-source memory forensics framework for malware analysis and incident response.

 

It allows investigators to parse memory dumps and extract information about a target system that the memory was taken from.

 

Since data in memory is highly volatile, a live memory dump contains information which would be lost when the computer is shutdown; which is where volatility comes in.

 

Volatility requires Python3.7.0 or later.

 

Can be installed with setup.py.

Requirements for Volatility. Click to see more.

Installation

Click here to check out the GitHub page where you can download it ➡️

https://www.volatilityfoundation.org/releases.

 

Download the Linux standalone executables from this link.

Download page for Volatility.

Once the zip file has downloaded, open it or cd into the directory through the terminal. It will be easier to proceed through terminal from here.

 

CD into the Downloads folder as this is where the file will be downloaded into.

 

Typing ls will show us the contents of the Downloads folder.

 

I have a capture01.bin file which is the memory dump that I will be analysing. 

Directory showing downloaded ZIP file.

Volatility_2.6_lin64_standalone.zip is the file we just downloaded.

Type unzip volatility_2.6_lin64_standalone.zip

Unzipping ZIP file.

When you cd into the new file that appears after unzipping (shown in the screenshot below), you will see the name volatility_2.6_lin64_standalone.

 

This is the executable which we will be using to interact with the memory dump. 

Now since we will need to type out this name many times, it will be easier to rename it to something smaller like simply volatility. 

Do this by typing mv volatility_2.6_lin64_standalone volatility.

Changing the file name to make it easier to refer to.

You can view the Volatility manual by typing ./volatility -h.

Help page for Volatility.

My memory dump file was in the Downloads folder and for volatility to work, the dump fill must be in the same folder as the tool. So, to move it, I typed ➡️

 

mv capture01.bin volatility_2.6_lin64_standalone volatility.

Move capture file to same directory as Volatility.

Usage

Type ./volatility -f capture01.bin imageinfo.

 

The -f flag specifies the presence of a file, in this case ‘capture01.bin’, and imageinfo identifies information about the image. 

Finding image information with Volatility.

The result shows that the memory dump was of a WinXPSP2x86 operating system based on a scan of the KDBG (Kernel Debugging Block).

 

The KDBG is used by the operating system for debugging purposes and is unique enough across different OS versions to have its own signature. 

Running the pslist command on the capture file returns a list of processes that were running on the host OS at the time of the live RAM capture.

 

Type ./volatility -f capture01.bin --profile WinXPSP2x86 pslist. 

Running pslist on Volatility.

Running pstree returns all the processes in tree form with parent and child processes clearly visible.

 

Type ./volatility -f capture01.bin pstree.

Running pstree on Volatility.

Rather than relying on the linked process list, psscan displays _EPROCESS objects (structure used by Windows to represent processes).

 

This means psscan can find terminated processes as well as unlinked (hidden) processes.

 

Type ./volatility -f capture01.bin psscan.

Running pstree on Volatility.

The plugin psxview uses seven different methods to enumerate running processes – Process object scanning, Thread scanning, CSRSS Handle table, PspCid table, session processes, desktop threads and active process linked list. This makes it less likely for a process to hide from this plugin.

A shown below, the highlighted processes come out as False in the first two columns (pslist and psscan) which indicates that they are hidden processes.

 

Type ./volatility -f capture01.bin psxview.

Running psxview on Volatility.

Running connscan on the capture file scans the capture for UDP/TCP connections (Windows XP only). Other operating systems have the netscan command instead.

 

As shown in the screen shot, the PID 1696 (the network listener from the last screen shot) has a remote connection pointing to 192.168.101.1 – suspicious.

 

Type ./volatility -f capture01.bin connscan.

Running connscan on Volatility.

The sockscan plugin lists open sockets on the machine. Here we can see that PID 1696 (the network listener) is open and listening on port 31337.    

 

Type ./volatility -f capture01.bin sockscan.

Running sockscan on Volatility.

The memdump plugin dumps the addressable memory for a given process and since we are suspicious about PID 1896 (the hidden network listener), we can pass the PID through as an argument and volatility will write out the memory dump to a filename of your choice (for simplicity I named it 1896) and you can specify what location to save it in.

Type ./volatility -f captre01.bin memdump -p 1896 –dump-dir.

Running memdump on a specified port.

The file will be saved in the directory with a .dmp extension. 

Directory showing dump file.

You can now access this file and find out memory information for the specific port and conduct further analysis.