In 2024, the BlackByte ransomware group was caught injecting shellcode directly into legitimate Windows processes — leaving almost no trace on disk. Investigators only caught it by analyzing a full RAM dump. That's the power of memory forensics, and Volatility 3 is the tool most responders reach for first.
This guide skips the theory. You'll see real commands, real-looking output, and exactly what to do with it.
Setting Up Volatility 3 and Taking Your First Look
Volatility 3 is an open-source framework for extracting forensic artifacts from memory dumps. Unlike its predecessor, it doesn't require symbol profiles — it pulls Windows kernel symbols automatically from Microsoft's public symbol server.
Install it fast:
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
pip3 install -r requirements.txtYou have a memory dump called WORKSTATION-04.raw pulled from a suspected compromised host at 192.0.2.47. Start with windows.pslist to enumerate running processes:
python3 vol.py -f WORKSTATION-04.raw windows.pslist
PID PPID ImageFileName Offset Threads Handles CreateTime
4 0 System 0x... 142 - 2026-10-18 09:01:02
688 4 smss.exe 0x... 2 - 2026-10-18 09:01:03
772 664 csrss.exe 0x... 10 - 2026-10-18 09:01:05
1284 664 winlogon.exe 0x... 4 - 2026-10-18 09:01:05
2948 1480 explorer.exe 0x... 42 - 2026-10-18 09:14:33
3612 2948 svchost.exe 0x... 3 - 2026-10-19 23:47:11
3881 3612 cmd.exe 0x... 1 - 2026-10-19 23:47:15
3902 3881 powershell.exe 0x... 6 - 2026-10-19 23:47:16Most of this looks normal. But notice svchost.exe with PID 3612 — its parent is explorer.exe (PID 2948). Legitimate svchost.exe processes are always spawned by services.exe, not Explorer. That's your first red flag. The chain explorer.exe → svchost.exe → cmd.exe → powershell.exe screams process injection or a malicious dropper pretending to be a system binary.
Your next move: dig into that svchost.exe and its memory regions.
Hunting Injected Code and Suspicious Memory
Run windows.malfind — Volatility's built-in plugin for detecting memory regions that have executable permissions but no backing file on disk. That pattern is a classic sign of injected shellcode or a reflectively loaded DLL.
python3 vol.py -f WORKSTATION-04.raw windows.malfind --pid 3612
PID Process Start End Tag Protection Hexdump
3612 svchost.exe 0x1d0000 0x1d1fff VadS PAGE_EXECUTE_READWRITE
4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ......
..................................................
Disassembly:
0x1d0000 4d 5a dec ebp
0x1d0002 90 nop
0x1d0003 ... ...The MZ header at the start of that region is the magic bytes for a Windows PE (portable executable) file. A full executable is sitting in a private, executable memory region with no corresponding file path on disk. This is textbook process hollowing or reflective DLL injection — the attacker loaded a malicious binary entirely in RAM.
The PAGE_EXECUTE_READWRITE protection is the other tell. Legitimate code regions are typically PAGE_EXECUTE_READ. Writable and executable means something wrote shellcode there at runtime.
Now dump that region for further analysis:
python3 vol.py -f WORKSTATION-04.raw windows.dumpfiles --pid 3612 --virtaddr 0x1d0000 -o ./dump_output/Take the dumped file and run it through strings, YARA, or upload it to a sandboxed environment. You're likely looking at a Cobalt Strike beacon, Meterpreter stage, or similar C2 payload.
Extracting Network Connections and Command History
Memory holds active and recently closed network connections. Use windows.netstat to see what the compromised process was talking to:
python3 vol.py -f WORKSTATION-04.raw windows.netstat
Offset Proto LocalAddr LocalPort ForeignAddr ForeignPort State PID Owner
0x... TCPv4 192.0.2.47 49832 203.0.113.88 443 CLOSED 3612 svchost.exe
0x... TCPv4 192.0.2.47 49901 203.0.113.88 443 ESTAB 3902 powershell.exePID 3612 (svchost.exe) made an outbound connection to 203.0.113.88:443 — already closed by the time of the dump. PID 3902 (powershell.exe) has an active established connection to the same IP. That IP is your C2 server. Block it at the firewall immediately and pivot to threat intel to see if it's a known infrastructure.
Also pull command history straight from memory — no need to hope PowerShell logging was enabled:
python3 vol.py -f WORKSTATION-04.raw windows.cmdline
PID Process Args
3881 cmd.exe cmd.exe /c powershell -nop -w hidden -enc SQBFAFgAIA...
3902 powershell.exe powershell -nop -w hidden -enc SQBFAFgAIA...That -enc flag means Base64-encoded command. Decode it with echo SQBFAFgAIA... | base64 -d and you'll almost certainly find a download cradle or reverse shell one-liner. This is the exact command the attacker ran — preserved in RAM even if logs were wiped.
What To Do Now
Pull a memory dump from any Windows endpoint in your lab using NotMyFault or WinPmem, then run windows.pslist and windows.malfind against it. Get familiar with what normal looks like before you're staring at a live incident at 2 a.m. Muscle memory on clean systems saves you when the real thing hits.
