Volatility 3 Memory Forensics: Practical Guide

In the 2024 BlackCat ransomware campaign, investigators recovered attacker credentials and injected shellcode directly from RAM dumps — artifacts that never touched disk. Tools like Volatility 3 made that possible. If you’re responding to a live compromise or analyzing a suspicious endpoint, memory forensics is often the only place the truth lives.

Setting Up Volatility 3 and Taking Your First Look

Volatility 3 is an open-source memory forensics framework. Unlike its predecessor, it no longer requires pre-built profiles — it downloads symbol tables on demand, which removes a huge friction point. Install it with:

git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
pip install -r requirements.txt

Assume you’ve acquired a memory image from a Windows 10 endpoint named CORP-WKS-047 (IP: 192.0.2.47). The image file is corp-wks-047.mem. Start with process enumeration:

python3 vol.py -f corp-wks-047.mem windows.pslist

PID   PPID  ImageFileName        Offset             Threads  Handles  CreateTime
----  ----  -------------------  -----------------  -------  -------  --------------------
4     0     System               0x8a0d8040         142      -        2026-07-13 08:12:01
624   4     smss.exe             0x9e1bc080         2        -        2026-07-13 08:12:03
812   604   csrss.exe            0x9f3a1300         9        -        2026-07-13 08:12:05
1056  1040  explorer.exe         0xa1bc3080         42       -        2026-07-13 08:14:22
3812  1056  powershell.exe       0xa3cd4200         8        -        2026-07-13 09:47:13
3901  3812  svchost.exe          0xa4de5100         3        -        2026-07-13 09:47:15
4102  3901  cmd.exe              0xa5ef6080         2        -        2026-07-13 09:47:18

Two things jump immediately. First, svchost.exe (PID 3901) has powershell.exe as its parent — that’s backwards. Legitimate svchost processes spawn from services.exe, not PowerShell. Second, a cmd.exe child of that suspicious svchost is a classic post-exploitation pattern. You’re looking at a likely process injection chain.

The next move is to examine the parent-child relationships more tightly with windows.pstree, then pivot to the command lines that were actually executed.

Extracting Command Lines and Network Connections

Command-line arguments live in memory even after a process finishes. Pull them for the suspicious cluster:

python3 vol.py -f corp-wks-047.mem windows.cmdline --pid 3812 3901 4102

PID   Process          Args
----  ---------------  ----------------------------------------------------------
3812  powershell.exe   powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC...
3901  svchost.exe      C:\Windows\System32\svchost.exe
4102  cmd.exe          cmd.exe /c whoami && net user /domain > C:\Users\jharris\AppData\Local\Temp\o.txt

The base64-encoded -enc flag on PowerShell is an immediate red flag — attackers use it to obfuscate payloads. Decode that blob with base64 -d or CyberChef and you’ll likely find a download cradle or reflective loader. The cmd.exe line confirms the attacker ran whoami and dumped domain user info to a temp file — classic initial reconnaissance after landing a shell.

Now check what network connections that PowerShell process had open:

python3 vol.py -f corp-wks-047.mem windows.netstat

Offset      Proto  LocalAddr        LocalPort  ForeignAddr      ForeignPort  State        PID   Owner
----------  -----  ---------------  ---------  ---------------  -----------  -----------  ----  ---------------
0xa3cd4200  TCPv4  192.0.2.47       49823      192.0.2.199      443          ESTABLISHED  3812  powershell.exe
0xa1bc3080  TCPv4  192.0.2.47       49701      192.0.2.1        80           CLOSE_WAIT   1056  explorer.exe

PowerShell holding an ESTABLISHED connection on port 443 to 192.0.2.199 is your C2 channel. Feed that IP into your threat intel platform immediately. The CLOSE_WAIT on explorer.exe is probably benign web traffic — ignore it for now and focus on the live beacon.

Dumping Injected Code for Malware Analysis

Process injection leaves shellcode or a PE file mapped into a victim process’s memory space without a corresponding file on disk. Volatility’s windows.malfind plugin flags regions that are executable, private, and contain suspicious headers:

python3 vol.py -f corp-wks-047.mem windows.malfind --pid 3901

PID   Process     Start       End         VadTag  Protection         Hexdump
----  ----------  ----------  ----------  ------  -----------------  -------------------------------------------
3901  svchost.exe 0x00400000  0x00401fff  VadS    PAGE_EXECUTE_RW    4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff ...
3901  svchost.exe 0x00c30000  0x00c31fff  VadS    PAGE_EXECUTE_RW    fc 48 83 e4 f0 e8 c0 00 00 00 41 51 41 50 ...

The bytes 4d 5a are the MZ header — that’s a Windows PE file mapped directly into svchost’s address space. No file on disk, no AV signature hit during execution. The second region starts with fc 48 83 e4 f0, a classic x64 shellcode prologue used by Cobalt Strike and Metasploit.

Dump both regions to disk for static and dynamic analysis:

python3 vol.py -f corp-wks-047.mem windows.dumpfiles --pid 3901 --virtaddr 0x00400000 -o ./dumps/

Submit the dumped files to a sandbox or run them through strings, YARA, and pe-sieve. The injected PE will often contain the C2 address hardcoded in plaintext or a config blob you can decrypt.

What To Do Now

Take a memory image from any Windows endpoint in your lab environment right now using WinPmem (winpmem_mini_x64.exe acquire mem.raw), then run windows.pslist and windows.malfind against it with Volatility 3. You’ll immediately see what a clean baseline looks like — so when a real incident lands, you’ll know exactly what looks wrong.