Memory Forensics with Volatility 3

Why Memory Forensics Matters

Every investigation technique you have learned so far examines artifacts on disk — log files, registry hives, filesystem timestamps, bash_history. But modern attackers increasingly operate in a space that disk forensics cannot reach: memory.

Fileless malware, process injection, living-off-the-land binaries, and in-memory-only payloads leave no files to find and no hashes to match. The encryption keys that protect an attacker's C2 channel exist only in RAM. The network connections that were active during the breach are recorded in memory structures, not log files. The injected shellcode that gave the attacker their foothold may have been loaded directly into a legitimate process — never written to disk.

Memory Acquisition Methods

Before you can analyze memory, you need to capture it. Memory acquisition creates a binary dump of the system's physical RAM — typically a file between 4 GB and 128 GB depending on the system.

Windows Acquisition Tools

C:\> winpmem_mini_x64.exe memory.raw

C:\> DumpIt.exe

Linux Acquisition with LiME

LiME (Linux Memory Extractor) is a loadable kernel module that captures memory from a running Linux system:

sudo insmod lime-$(uname -r).ko "path=/evidence/memory.lime format=lime"

Acquisition Best Practices

1. Capture memory before disk — memory is more volatile
2. Write the dump to an external drive — avoid overwriting evidence on the target system
3. Hash the dump immediately — sha256sum memory.raw > memory.raw.sha256 for chain of custody
4. Document the time and method — note the exact UTC time and tool used
5. Capture the pagefile too — C:\pagefile.sys and C:\swapfile.sys may contain swapped-out memory pages

Volatility 3 Architecture

Volatility is the industry-standard framework for memory forensic analysis. Volatility 3 (the current version) is a complete rewrite of the original Volatility 2, with significant architectural improvements.

Click to enlarge

Key Differences from Volatility 2

Running Volatility 3

python3 vol.py -f memory.raw windows.pslist
python3 vol.py -f memory.raw windows.pstree
python3 vol.py -f memory.raw windows.netscan

The basic syntax is always: vol.py -f <memory_dump> <plugin_name>

Symbol Tables

Volatility 3 needs symbol tables to understand the internal data structures of the operating system. For Windows, these are automatically downloaded from Microsoft's symbol server the first time you analyze a dump. For Linux, you may need to generate them from the target system's kernel debug symbols using dwarf2json.

Essential Plugins: Process Analysis

Process analysis is the foundation of memory forensics. Attackers must run code to accomplish their objectives, and that code runs as (or inside) a process.

windows.pslist — Process Listing

python3 vol.py -f memory.raw windows.pslist

PID     PPID    ImageFileName   Offset          Threads Handles SessionId
4       0       System          0x...           164     -       N/A
88      4       Registry        0x...           4       -       N/A
348     4       smss.exe        0x...           2       -       N/A
444     436     csrss.exe       0x...           10      -       0
508     436     wininit.exe     0x...           3       -       0
528     500     csrss.exe       0x...           12      -       1
588     500     winlogon.exe    0x...           5       -       1
672     508     services.exe    0x...           8       -       0
684     508     lsass.exe       0x...           9       -       0
3284    672     svchost.exe     0x...           15      -       0
7420    3284    cmd.exe         0x...           1       -       0
7488    7420    powershell.exe  0x...           8       -       0

Key things to look for:

• Unexpected parent-child relationships — cmd.exe spawned by svchost.exe is suspicious; powershell.exe spawned by winword.exe is almost certainly malicious
• Processes with unusual names — misspellings like scvhost.exe or lssas.exe
• Multiple instances of singleton processes — there should be exactly one lsass.exe, one services.exe, one wininit.exe
• Processes running from unexpected paths — legitimate svchost.exe runs from C:\Windows\System32\, not C:\Users\Public\

windows.pstree — Process Tree

python3 vol.py -f memory.raw windows.pstree

This displays processes in a hierarchical tree format, making parent-child relationships immediately visible. Attackers who inject into legitimate processes or spawn suspicious child processes are much easier to spot in the tree view.

Essential Plugins: Network Analysis

windows.netscan — Network Connections

python3 vol.py -f memory.raw windows.netscan

Offset          Proto   LocalAddr       LocalPort       ForeignAddr     ForeignPort     State       PID     Owner
0x...           TCPv4   10.0.1.50       49753           185.141.63.12   443             ESTABLISHED 7488    powershell.exe
0x...           TCPv4   10.0.1.50       445             10.0.2.30       52891           ESTABLISHED 4       System
0x...           TCPv4   10.0.1.50       80              0.0.0.0         0               LISTENING   1204    httpd.exe
0x...           TCPv4   10.0.1.50       49771           10.0.2.15       4444            CLOSED      7420    cmd.exe

This is extraordinarily valuable forensic evidence:

• ESTABLISHED connections show what was actively communicating at the time of capture — powershell.exe connecting outbound to 185.141.63.12:443 is a strong C2 indicator
• CLOSED connections show recent connections that have ended — cmd.exe connecting to port 4444 (Metasploit default) confirms exploitation
• LISTENING ports reveal backdoors — unexpected services listening on unusual ports
• PID correlation links network activity to specific processes, which you can then investigate further

Essential Plugins: Command Lines and Code

windows.cmdline — Process Command Lines

python3 vol.py -f memory.raw windows.cmdline

PID     Process         Args
7420    cmd.exe         cmd.exe /c whoami && net user /domain
7488    powershell.exe  powershell.exe -nop -w hidden -enc SQBFAFgAIAAoA...
3284    svchost.exe     C:\Windows\System32\svchost.exe -k netsvcs -p

The -enc flag in PowerShell with a Base64 string is one of the most common attack indicators. Decode it:

echo "SQBFAFgAIAAoA..." | base64 -d

windows.malfind — Injected Code Detection

python3 vol.py -f memory.raw windows.malfind

PID     Process         Start VPN       End VPN         Tag     Protection      Hexdump / Disasm
3284    svchost.exe     0x2a40000       0x2a41fff       VadS    PAGE_EXECUTE_READWRITE
        4d 5a 90 00 03 00 00 00     MZ......
        04 00 00 00 ff ff 00 00     ........

malfind identifies memory regions that are:

1. Executable — marked with execute permissions (PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_READ)
2. Not backed by a file on disk — no corresponding DLL or EXE mapped from the filesystem
3. Contain code patterns — the plugin shows the first bytes, often revealing PE headers (MZ) or shellcode

A PAGE_EXECUTE_READWRITE region containing an MZ header inside a legitimate process like svchost.exe is a near-certain indicator of process injection.

Click to enlarge

windows.filescan — File Handles

python3 vol.py -f memory.raw windows.filescan

This scans memory for FILE_OBJECT structures, revealing every file handle open at the time of capture — including files that may have been deleted from disk but were still open in memory.

windows.dlllist — Loaded DLLs

python3 vol.py -f memory.raw windows.dlllist --pid 7488

Lists every DLL loaded into a process. Compare against known-good DLL lists for that process. An unfamiliar DLL loaded from an unusual path (e.g., C:\Users\Public\malware.dll loaded into svchost.exe) indicates DLL injection or sideloading.

Process Injection Detection

Process injection is the technique of executing code within the address space of another process. Attackers use it to evade detection — the malicious code runs under the identity of a trusted process like svchost.exe or explorer.exe.

Common Injection Techniques and Their Memory Signatures

The Memory Analysis Workflow

A structured approach prevents you from missing critical artifacts:

Phase 1 — Process Triage

1. Run windows.pslist to get the full process listing
2. Run windows.pstree to visualize parent-child relationships
3. Identify suspicious processes: wrong parents, unusual names, wrong session IDs

Phase 2 — Network Triage 4. Run windows.netscan to map all network connections 5. Correlate PIDs from suspicious connections back to processes identified in Phase 1 6. Look for connections to known-bad IPs, unusual ports, or unexpected outbound traffic

Phase 3 — Deep Dive 7. Run windows.cmdline on suspicious PIDs to see their command-line arguments 8. Run windows.malfind to detect injected code 9. Run windows.dlllist on suspicious processes to check loaded modules 10. Run windows.filescan to find file handles of interest

Phase 4 — Extraction 11. Dump suspicious memory regions (--dump flag) for offline analysis 12. Extract injected code for YARA scanning or sandbox submission 13. Document all IOCs found: IPs, domains, file hashes, mutexes

Finding Hidden Processes

Sophisticated malware may attempt to hide processes from standard listing tools by unlinking them from the kernel's process list (Direct Kernel Object Manipulation — DKOM). Volatility can detect this:

python3 vol.py -f memory.raw windows.pslist
python3 vol.py -f memory.raw windows.psscan

windows.pslist walks the kernel's linked list of active processes — what the OS "sees." windows.psscan scans all of physical memory for process structures regardless of whether they are linked. Processes that appear in psscan but not pslist are either terminated processes whose structures have not been overwritten, or actively hidden processes using DKOM.

Memory IOC Extraction

Memory dumps are rich sources of indicators of compromise:

Key Takeaways

• Memory forensics reveals evidence that disk forensics cannot — fileless malware, injected code, encryption keys, and active network connections
• Acquire memory BEFORE disk — RAM evidence is the most volatile and cannot be recovered after power loss
• Volatility 3 uses symbol tables (not profiles), namespaced plugins (windows.pslist not pslist), and Python 3
• windows.pslist + windows.pstree expose process relationships — know the normal Windows process tree to spot anomalies
• windows.netscan reveals network connections tied to specific PIDs — critical for identifying C2 communication
• windows.cmdline recovers full command-line arguments including Base64-encoded PowerShell payloads
• windows.malfind detects injected code by finding executable, non-file-backed memory regions — MZ headers in RWX regions are near-certain injection indicators
• Compare pslist vs psscan to detect hidden processes using DKOM rootkit techniques
• Follow the four-phase workflow: process triage → network triage → deep dive → extraction
• Dump suspicious memory regions for YARA analysis and sandbox submission — bridging memory forensics with malware analysis

What's Next

You can now investigate what happened on disk (Lesson 9.4) and in memory (this lesson). But a real investigation requires combining all artifacts into a single chronological view. Lesson 9.6 introduces building a forensic timeline — using tools like Plaso/log2timeline to merge filesystem timestamps, memory artifacts, log entries, and SIEM alerts into one unified super timeline that tells the complete story of an incident from initial compromise through data exfiltration.