Practical Memory Forensics with Volatility 2 & 3 (Windows and Linux) Cheat-Sheet

By Abdel Aleem — A concise, practical guide to the most useful Volatility commands and how to use them for hunting, detection and triage on Windows and Linux memory images.

Why memory forensics matters

Physical and live memory are a forensic goldmine: running processes, network connections, injected code, credentials, and even command history can live only in RAM. Memory forensics lets you reconstruct attacker activity that disk forensics alone will miss fileless malware, kernel rootkits, process injection, and volatile artifacts like in-memory C2.

Volatility 2 (legacy, profile-based, stable on many Windows cases) and Volatility 3 (modern, Python 3, improved cross-platform and plugin model) are the two tools you will commonly use. Below is a practical guide commands you’ll run during triage, what they reveal, and quick hunting/detection notes.

Quick comparison: Volatility 2 vs Volatility 3

Volatility 2

• Profile-based (--profile=<PROFILE>).
• Mature; many legacy workflows and Windows plugins.
• Often used when analysts already have known profiles or prefer Windows-specific plugins.

Volatility 3

• Python 3, plugin architecture with symbol tables (no --profile required).
• Better cross-platform support (Windows + Linux + macOS).
• Improved memory model and active development; some Volatility-2 plugins are reimplemented differently.

Use Volatility 2 when you need older, well-known Windows plugins and you have the profile. Use Volatility 3 for cross-platform work, better automatic identification, and newer plugins.

Volatility 3 Tool:

python3 vol.py -f <imagepath> windows.info

identify info for the image

python3 vol.py -f <imagepath> windows.pstree

to see all the process, equivalent of the process of the processes list in task manger

python3 vol.py -f <imagepath> windows.psscan

to see all the process but in the structure it is more powerful even if there is no parent or child, and we can identify even hidden process (good for root kit)

— -

Volatility Hunting and Detection Capabilities:

python3 vol.py -f <imagepath> windows.malfind

find hidden or injected code/DLLs in user mode memory

This plugin will attempt to identify injected processes and their PIDs along with the offset address and a Hex, Ascii, and Disassembly view of the infected area. The plugin works by scanning the heap and identifying processes that have the executable bit set **RWE or RX** and/or no memory-mapped file on disk (file-less malware)

python3 vol.py -f <imagepath> windows.yarascan — yara-file <path to the yara file>

will search for strings, patterns, and compound rules against a rule set. You can either use a YARA file as an argument or list rules within the command line.

python3 vol.py -f <imagepath> windows.yarascan — yara-rule=”The string you want to search”

— -

Advanced Memory Forensics:

python3 vol.py -f <imagepath> windows.ssdt

will search for hooking and output its results. Hooking can be used by legitimate applications, so it is up to you as the analyst to identify what is evil. As a brief overview of what SSDT hooking is: SSDT stands for System Service Descriptor Table; the Windows kernel uses this table to look up system functions. An adversary can hook into this table and modify pointers to point to a location the rootkit controls.

There can be hundreds of table entries that ssdt will dump; you will then have to analyze the output further or compare against a baseline. A suggestion is to use this plugin after investigating the initial compromise and working off it as part of your lead investigation.

python3 vol.py -f <imagepath> windows.modules

Will scan for drivers present on the system at the time of extraction. This plugin can help to identify driver files in the kernel that the modules plugin might have missed or were hidden.

— -

python3 vol.py -f <imagepath> windows.netscan

For connection and sockets

python3 vol.py -f <imagepath> windows.filescan

Scans for file objects present in a particular windows memory image

python3 vol.py -f “/path/to/file” windows.registry.hivelist

To locate the virtual address for registry hives

python3 vol.py -f “/path/to/file” windows.registry.printkey

python3 vol.py -f “/path/to/file” windows.registry.printkey ‑‑key “Software\Microsoft\Windows\CurrentVersion”

To print specific hive key

vol.exe -f <imagepath> — profile <Winprofile> -g <KDBG address> svcscan

It will show (Service Name — Display Name — Binary Path)

python3 vol.py -f “/path/to/file” windows.dlllist

This plugin will list all DLLs associated with processes at the time of extraction. This can be especially useful once you have done further analysis and can filter output to a specific DLL that might be an indicator for a specific type of malware you believe to be present on the system.

python3 vol.py -f “/path/to/file” windows.dlllist ‑‑pid <PID>

To get specific process and DLL related

python3 vol.py -f “/path/to/file” windows.dlllist | Select-String “name of the dll.dll” -Context 50,0

python3 vol.py -f “/path/to/file” -o “/path/to/dir” windows.dumpfiles — physaddr <PID>

“PROCDUMP” Dumps exe and associated DLLs

vol.py -f “/path/to/file” windows.cmdline

To know the command line name

vol.py -f “/path/to/file” -o “/path/to/dir” windows.memmap.Memmap — dump — pid <PID>

“MEMDUMP” to dump process or file from memory

python3 vol.py -f <imagepath> windows.cmdline.CmdLine

Command line

consoles

It is not only prints the commands attackers typed, but it collects the entire screen buffer (input and output). For instance, instead of just seeing “dir”, you will see exactly what the attacker saw, including all files and directories listed by the “dir” command.

Volatility 2 Tool:

Note: using the Win standalone version

vol.exe — info

To see all the plugins

vol.exe -f <imagepath> imageinfo

Identifying the operating system, service pack, the time zone, and hardware architecture (32 or 64-bit) of the subject system

vol.exe -f <imagepath> — profile==<Winprofile> kdbgscan

More informations

Imageinfo: the address of the KDBG, a data structure used for debugging purposes if the system crashes. It's also used to keep track of information about the system, like running processes. The KDBG is unique for each operating system and can fingerprint the target system.

kdbgscan: the imageinfo plugin is not very good at scanning the subject dump and locating the KDBG signature because of the way it works. It scans the dump for all possible KDBG signatures (a KDBG signature is nothing but a hex string like 4b 44 42 47 40 03) and stops after hitting the first match, and will not scan the remaining content of the dump.
Sometimes, particularly large dump files, the dump may have content identical to the KDBG signatures (false positives). If the imageinfo plugin scan hits one of these false positive matches first, it will incorrectly report the target profile, ruining the whole analysis process.
The kdbgscan plugin exists to solve this problem by scanning the entire dump (it does not stop at the first hit) and extracting all possible KDBG signatures. The plugin output lists all identified KDBGs signatures offsets (i.e., memory addresses) and the suggested profile for each identified KDBG signature.

vol.exe -f <imagepath> — profile <Winprofile> -g <KDBG address> pslist

To get list of the process

vol.exe -f <imagepath> — profile <Winprofile> pstree

To get list of the process and the Hidden

psxview // Compares pstree and psscan, which is useful because if there’s a difference in the output, it means there’s a process running in kernel mode that isn’t visible but exists only in VOLATILITY 2, not 3.

vol.exe -f <imagepath> — profile <Winprofile> -g <KDBG address> getsids –o <offset/address you have from PSXVIEW>

The GETSIDS Volatility plugin extracts and display the security identifiers (SIDs) of all user accounts that have started a process. When a user starts a process, the process inherits the user’s SID through the Process Environment Block (PEB). The GETSIDS plugin scans the PEBs of all running processes in a memory dump and identifies the SIDs of the users who started them, providing a way to map processes to the users who started them.

By analyzing the SIDs associated with a process, you can determine whether the process is associated with a legitimate user account or an attacker who may have gained unauthorized access to the system.

In addition, system processes (e.g., system.exe, lsass.exe, and svchost.exe) are expected to run with system accounts’ privileges (i.e., SID). Attackers may create a malicious process and name it after well-known system processes to avoid detection. Thus, seeing a system-like process started by a standard user account (usually a compromised account) is abnormal.

vol.exe -f <imagepath> — profile <Winprofile> netscan

To get the Ip address

vol.exe -f <imagepath> — profile <Winprofile> dlllist

DLL

vol.exe -f <imagepath> — profile <Winprofile> cmdline

To see thew command lines

vol.exe -f <imagepath> — profile <Winprofile> cmdline –p <number of ID>

To see the command lines

vol.exe -f <imagepath> — profile <Winprofile> consoles

The consoles plugin finds commands that attackers typed into cmd.exe or executed via backdoors. However, instead of scanning for COMMAND_HISTORY, this plugin scans for CONSOLE_INFORMATION. The major advantage to this plugin is it not only prints the commands attackers typed, but also it collects the entire screen buffer (input and output). For instance, instead of just seeing “dir”, you will see exactly what the attacker saw, including all files and directories listed by the “dir” command.

vol.exe -f <imagepath> — profile <Winprofile> filescan

Scans for file objects

vol.exe -f <imagepath> — profile <Winprofile> filescan | grep -i “The file name”

Scans for specific file to get the Offset and then we dump it

vol.exe -f <imagepath> — profile <Winprofile> malfind

Find hidden or injected code

vol.exe -f <imagepath> — profile <Winprofile> malfind — pid <Process ID> -D <Location To Dump>

To dump the process into your machine

vol.exe -f <imagepath> — profile <Winprofile> memdump — pid <Process ID> -D <Location To Dump>

To dump the process into your machine

vol.exe -f <imagepath> — profile <Winprofile> procdump -p <PID> ‑‑dump-dir=“/path/to/dir”

procdump

vol.exe -f <imagepath> — profile <Winprofile> ldrmodules -p <Process ID>

The ldrmodules plugin can be used to list the loaded modules (DLLs) in a process, and it can be used to detect unlinked/hidden DLLs.

Note: If all these columns are False, it may indicate the presence of a rootkit or other malicious software that is trying to hide its presence.

vol.exe -f <imagepath> — profile <Winprofile> dumpfiles -Q <The Offset> -D <Location To Dump> <the name of the file and extension>

Dump a file

vol.exe -f <imagepath> — profile <Winprofile> hashdump

Scans for file objects

vol.exe -f <imagepath> — profile <Winprofile> envars

To get the enviroments

vol.exe -f <imagepath> — profile==<Winprofile> dumpregistry -D .

To dump registry

vol.exe -f <imagepath> — profile <Winprofile> shimcache

What applications ran and at what time

vol.exe -f <imagepath> — profile <Winprofile> mftparser

Scan for & parses potential MFT entries

Memory forensics on Linux

python3 vol.py — help | grep -i linux.

Plug-ins that can be used for Linux memory forensics

python3 vol.py -f <memory_dump> banner

Displays the operating system, version, and other basic information from the memory dump file

python3 vol.py -f <memory_dump> linux.pslist

Displays a list of processes running on the system

python3 vol.py -f <memory_dump> linux.pstree

Displays the tree structure of processes, showing parent and child relationships

python3 vol.py -f <memory_dump> linux.psscan

Lists all processes in memory. Unlike Pslist, it also lists processes that have been killed but still have traces in memory

python3 vol.py -f <memory_dump> linux.bash

Displays the bash commands and history that are executed on Linux systems

python3 vol.py -f <memory_dump> linux.lsof

Lists open file objects on Linux systems

python3 vol.py -f <memory_dump> linux.lsmod

Lists installed Linux kernel modules

python3 vol.py -f <memory_dump> linux.sockstat

Lists all network connections for all processes

python3 vol.py -f <memory_dump> linux.vmayarascan — yara-rules “/path/to/yara_rules.yar”

Allows you to search Linux memory dumps using YARA rules

python3 vol.py -f <memory_dump> linux.psaux

The commands executed on the system are analyzed one by one, and if there are abnormal or suspicious commands, the forensics process proceeds for those commands

Practical workflow / checklist for triage

1. Identify image & OS: windows.info / banner.
2. Process triage: pstree → psscan → compare.
3. Network triage: netscan.
4. Suspicious processes → dlllist, memmap, dumpfiles, malfind.
5. YARA scan suspicious dumps.
6. Kernel check (if warranted): ssdt, modules.
7. Command history: consoles, cmdline, linux.bash.

If you found this guide helpful, feel free to follow me for more