Volatility3 (Linux)
- Shone Pious
- Jul 4, 2023
- 3 min read
Updated: Sep 29, 2023
In this blog:
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.
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.
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.
Volatility_2.6_lin64_standalone.zip is the file we just downloaded.
Type ➡️
unzip volatility_2.6_lin64_standalone.zip 
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
You can view the volatility manual by typing ➡️
./volatility -h
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
Usage
Type ➡️
./volatility -f capture01.bin imageinfoThe -f flag specifies the presence of a file, in this case ‘capture01.bin’, and imageinfo identifies information about the image.
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 pstree returns all the processes in tree form with parent and child processes clearly visible.
Type ➡️
./volatility -f capture01.bin pstree
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 
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 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
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
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 capture01.bin memdump -p 1896 –dump-dir
The file will be saved in the directory with a .dmp extension.
You can now access this file and find out memory information for the specific port and conduct further analysis.
What's next?
Comentarios