Analyzing Malware in Memory with Volatility 3
When to Use
- You have a RAM image from a suspected-infected host and need to find malicious activity.
- Disk artifacts are insufficient (fileless/in-memory malware) and you need volatile evidence.
- You want to extract injected code, command lines, or network connections for analysis.
Do not use Volatility plugins blindly without an order of investigation — start broad
(processes, network) before deep per-process dumps.
Prerequisites
- Volatility 3 (
pip install volatility3) with appropriate symbol tables.
- A memory image acquired with a sound tool (WinPmem, LiME, or hypervisor snapshot).
- Knowledge of the source OS/version to select the right symbols.
Safety & Handling
- Work on a copy of the image; preserve the original with a recorded hash.
- Treat any dumped executable region as a live sample — store and handle it accordingly.
Workflow
Step 1: Enumerate processes and spot anomalies
vol -f memory.raw windows.pslist
vol -f memory.raw windows.pstree
Look for unusual parents (Word spawning cmd/powershell), masquerading names
(scvhost.exe), processes with no disk path, and orphaned children.
Step 2: Hunt injected code
vol -f memory.raw windows.malfind
malfind flags private, executable, RWX regions with no backing file — classic injection.
Note the PID and base address for dumping.
Step 3: Review network connections
vol -f memory.raw windows.netscan
Correlate listening/established connections with suspicious PIDs and the C2 endpoints from
other analysis.
Step 4: Check modules, handles, and persistence
Examine loaded DLLs (windows.dlllist), services, and registry (windows.registry.*) for
persistence and unexpected modules.
Step 5: Dump artifacts
Dump the suspicious process or injected region for static/RE analysis:
vol -f memory.raw windows.dumpfiles --pid <pid>
The helper script parses Volatility's JSON renderer output to highlight injection candidates.
vol -f memory.raw -r json windows.malfind | python scripts/analyst.py malfind -
Validation
- Injection candidates from
malfind correspond to anomalous processes from pstree.
- Network connections map to known C2 or the sample's extracted config.
- Dumped regions disassemble into meaningful code, not random bytes.
Pitfalls
- Wrong symbols/profile producing empty or garbage results — confirm OS build first.
- Treating every RWX region as malicious; some legitimate JIT engines use RWX. Corroborate.
- Forgetting to hash and preserve the original image before analysis.
References
- See
references/api-reference.md for the malfind output
parser.
- Volatility 3 documentation and memory-forensics concepts (linked in frontmatter).