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).