Volatility memory forensics: finding the implant

A memory image is the most honest artifact in forensics: it holds what was actually running, including the things that never touched disk. This walkthrough uses Volatility 3 to work a captured image from first contact to a dumped implant, following the order a CTF challenge usually rewards.

Why memory first

Disk forensics shows you what was stored. Memory shows you what was alive: decrypted strings, network connections, injected code, and processes that deleted their own files. Malware that runs only in RAM leaves almost nothing on disk by design, which is exactly why a memory image is where the flag tends to hide. Your job is to triage fast, then pivot to the one process that does not belong.

Step one: identify the image

Volatility 3 auto-detects the OS from symbols, so you can move straight to plugins. Start with a process listing and a scan of what was running. The difference between the two matters: pslist walks the kernel's process list, while psscan carves process structures directly from memory and can surface processes that were unlinked to hide them.

# windows image: list, then scan for hidden processes
$ vol -f mem.raw windows.pslist
$ vol -f mem.raw windows.psscan

# diff the two: a PID in psscan but not pslist is suspicious
$ vol -f mem.raw windows.pstree   # parent/child relationships

Read the process tree like a sentence. A cmd.exe spawned by a Word document, or an svchost.exe whose parent is not services.exe, is the kind of mismatch that names your suspect.

In memory forensics you are not looking for what is present. You are looking for what is present but should not be, or absent but should be. the triage mindset

Step two: follow the network and the command line

Once a process looks wrong, give it a motive. Network artifacts tie a process to a command-and-control endpoint, and the recovered command line often hands you the lure or the staging path directly.

$ vol -f mem.raw windows.netscan        # sockets and owning PID
$ vol -f mem.raw windows.cmdline         # how each process was launched
$ vol -f mem.raw windows.dlllist --pid 1337

A beaconing process with an outbound connection to a raw IP, launched with an encoded PowerShell command line, is a textbook implant. Note the PID; the next step extracts its payload.

Step three: flag injected code

The strongest single signal of code injection is a private memory region marked read-write-execute. Legitimate code is normally backed by a file on disk and is not writable and executable at once. The malfind plugin looks for exactly this: RWX private regions, often with an MZ header or raw shellcode at the start.

$ vol -f mem.raw windows.malfind --pid 1337
# look for: Protection PAGE_EXECUTE_READWRITE
# and a disassembly that starts with a push/call stub

Treat a flagged RWX region as your lead, not your verdict. Confirm by reading the disassembly Volatility prints; injected shellcode usually opens with a recognisable prologue rather than the noise of unallocated memory.

Step four: dump and analyse

With the suspect process and region identified, carve the artifact out for static analysis. Dump the process image or the injected region, then run strings and a hash before pivoting to a disassembler. Memory-resident strings frequently contain the flag, a C2 URL, or a key.

• windows.dumpfiles --pid 1337 recovers files the process had open.
• windows.memmap --pid 1337 --dump writes the addressable memory to disk.
• Run strings -el for wide (UTF-16) strings, which Windows malware often uses.

The transferable habit

Triage wide, then pivot narrow: list before you scan, scan before you carve, and confirm each lead before you trust it. The same discipline that separates a hidden process from a benign one is the discipline that verifies a single ROP gadget before adding the next, and that confirms an injectable parameter before writing the extraction loop. A signal you cannot reproduce is not yet evidence.