Windows Memory Forensics with Volatility 3: Practical Guide

Disk artifacts tell you what was written; memory tells you what was running. This guide walks through acquiring Windows RAM, using the memory that Windows already leaves on disk, and working a Volatility 3 case from windows.info to dumped files. You will also learn where memory analysis misleads, and how to fold its results into the rest of the investigation.

Why memory matters

A growing share of intrusions leave little on disk. Memory analysis answers questions disk forensics cannot:

• Injected and fileless code: shellcode, reflectively loaded DLLs and PowerShell payloads live in process memory and never touch the file system.
• Live network state: sockets and connections with their owning processes, including ones that have already closed but whose structures remain.
• Real command lines and environment: what a process was actually started with, before any log was rotated.
• Decrypted and unpacked content: packed malware unpacks itself in memory; encryption keys and decrypted strings are often recoverable.
• Kernel state: loaded drivers, callbacks and hooks set by rootkits.

Following the order of volatility, capture memory first on any live system you intend to examine.

Acquisition

Live capture tools

All live tools load a driver to read physical memory. Run them from external media, write the image to external storage, and record the tool, version, hash and time.

• WinPmem (open source, Velocidex): produces a raw image. Also available inside Velociraptor for remote capture.
• Magnet RAM Capture: free GUI tool producing a raw image.
• DumpIt (Magnet/Comae): one-click capture; recent versions write a Microsoft crash dump format that Volatility reads directly.

# WinPmem: write a raw image to external drive E:
.\winpmem_mini_x64.exe E:\HOST01_mem.raw

# Hash the image immediately
Get-FileHash E:\HOST01_mem.raw -Algorithm SHA256

The executable name varies by release; check the one you download.

For remote hosts, Velociraptor's Windows.Memory.Acquisition artifact wraps WinPmem and uploads the image to the server, which avoids handing a USB drive to someone on site. Budget for the transfer: a 32 GB image over a slow VPN link can take hours, so decide early whether a full image or targeted live collection (process list, network connections, suspicious process dumps) is the better trade-off. A capture takes minutes and memory keeps changing during it, which matters later (see smear, below).

Virtual machines

For VMs, suspend or snapshot the guest instead of running a tool inside it. On VMware, the .vmem file holds guest memory and the matching .vmss (suspend) or .vmsn (snapshot) holds the metadata; keep them together, as Volatility 3 uses the metadata file to reconstruct the layout. Hyper-V saved states (.vmrs / .bin) generally need conversion to a crash dump before analysis. Cloud providers vary; plan this before an incident.

Crash dumps

A complete or kernel MEMORY.DMP (see crash dumps) can be loaded by Volatility. Kernel dumps lack user-mode pages, and minidumps are too small for general analysis, but both can still help.

Memory Windows already saved to disk

When no live capture exists, look at the disk. These files are often the only memory from before the incident was contained.

Convert hiberfil.sys before analysis. Hibr2Bin handles older formats; recent Volatility 3 releases include a hibernation layer and windows.hibernation.Info / windows.hibernation.Dump plugins for modern Windows 10/11 files. Support depends on the Windows build and on the compression used, so validate the output (does windows.info succeed, do process lists look sane) before relying on it. Collect all these files with raw NTFS access, as they are locked on a running system.

The Volatility 3 workflow

Volatility 3 is a Python framework; install it with pip install volatility3 or from the GitHub repository. The entry point is vol (or vol.py from a source checkout). Plugins use a windows. prefix, and there is no --profile any more.

Symbol tables

Volatility 3 identifies the kernel build and needs a matching symbol table in its JSON ISF format. With internet access, it downloads the kernel PDB from the Microsoft symbol server and converts it automatically, caching the result. Offline analysis needs the Windows symbol pack from the Volatility Foundation, or ISF files generated on a connected machine, placed in the symbols directory. If identification fails, that is almost always the cause.

Orientation

vol -f HOST01_mem.raw windows.info

windows.info confirms that the image parses and gives the build number, the system time at capture and the number of processors. Record the capture time: every timestamp you quote later is relative to it.

Processes

vol -f HOST01_mem.raw windows.pslist
vol -f HOST01_mem.raw windows.pstree
vol -f HOST01_mem.raw windows.psscan
vol -f HOST01_mem.raw windows.cmdline

• windows.pslist walks the active process list, the same list the OS itself uses.
• windows.pstree shows parent/child relationships, which is where most anomalies stand out.
• windows.psscan scans memory for process structures, finding terminated processes and processes unlinked from the list by rootkits. A process in psscan but not in pslist with no exit time is a finding.
• windows.cmdline shows each process's command line: encoded PowerShell, odd paths and LOLBin abuse show up here (see LOLBins).

Network

vol -f HOST01_mem.raw windows.netscan

windows.netscan scans for TCP/UDP endpoints and connections with the owning PID, process name and, where available, the creation time. windows.netstat walks the live structures instead; use both, since scanning also finds closed connections.

Injected code and modules

vol -f HOST01_mem.raw windows.malfind --pid 4312 --dump
vol -f HOST01_mem.raw windows.dlllist --pid 4312
vol -f HOST01_mem.raw windows.ldrmodules --pid 4312

• windows.malfind looks for private memory regions that are executable and writable and contain code-like content. It is noisy: .NET, JIT engines and some security products produce hits. Look at the disassembly and the presence of an MZ header, then confirm.
• windows.dlllist lists modules from the loader list; windows.ldrmodules compares the loader lists with mapped files, which exposes DLLs hidden from one of them.

Handles, services and registry

vol -f HOST01_mem.raw windows.handles --pid 4312
vol -f HOST01_mem.raw windows.svcscan
vol -f HOST01_mem.raw windows.registry.hivelist
vol -f HOST01_mem.raw windows.registry.printkey --key "Software\Microsoft\Windows\CurrentVersion\Run"

Two quick additions for suspicious processes: windows.getsids shows which account and groups a process runs as, and windows.privileges shows enabled privileges such as SeDebugPrivilege, which credential theft tools need.

windows.handles reveals open files, registry keys, mutexes and named pipes (C2 frameworks often use characteristic pipe and mutex names). windows.svcscan lists services known to the Service Control Manager, including ones whose registry key was already deleted. The registry plugins read hives as they were in memory, which can include changes not yet flushed to disk (see the registry hives page).

Files

vol -f HOST01_mem.raw windows.filescan > filescan.txt
vol -o ./dump -f HOST01_mem.raw windows.dumpfiles --virtaddr 0xe0012a4b3c80
vol -o ./dump -f HOST01_mem.raw windows.dumpfiles --pid 4312

windows.filescan lists file objects with their virtual addresses; windows.dumpfiles extracts cached file content by address or for all files mapped by a process. Dumped files may be incomplete, since only pages resident in memory can be recovered. Treat dumped executables as PE files for triage and hashing.

Use -r csv or -r json to get machine-readable output, and -o to set the output directory for dumps.

Hunting for anomalies

Most memory findings come from knowing what normal looks like.

Beyond the table:

• Parent/child mismatches remain the fastest way in. Shells under WmiPrvSE.exe, wsmprovhost.exe or services.exe-spawned unknown binaries also point to lateral movement.
• Unlinked processes: compare pslist and psscan.
• Unusual paths: binaries running from AppData, ProgramData, C:\Users\Public or Temp.
• Process hollowing: an image path that looks legitimate but whose memory does not match the file on disk. Recent Volatility releases add plugins targeting hollowing; malfind and ldrmodules catch many cases.

YARA and strings over memory

vol -f HOST01_mem.raw windows.vadyarascan --yara-file ./rules/cobaltstrike.yar
vol -f HOST01_mem.raw yarascan.YaraScan --yara-file ./rules/c2_strings.yar
strings -a -el HOST01_mem.raw > strings_utf16.txt

windows.vadyarascan scans process memory and attributes hits to a PID; yarascan.YaraScan scans the memory layer as a whole, without per-process attribution. Plain strings (ASCII and UTF-16LE) over the image, the pagefile and decompressed hiberfil is still useful for IPs, URLs and command fragments, but it cannot attribute a hit to a process.

MemProcFS as an alternative

MemProcFS mounts a memory image as a file system: processes become folders, with their modules, handles, memory maps and dumped files as files. Its forensic mode adds a timeline, parsed NTFS records found in memory, registry access and a findevil report that flags common injection patterns.

MemProcFS.exe -device E:\HOST01_mem.raw -forensic 1
# Then browse M:\ (e.g. M:\forensic\ and M:\name\<process>\)

It is fast and convenient for browsing and for feeding results into other tools. Volatility remains the reference for scripted, reproducible plugin output. Using both on the same image is common.

Timeline integration

Memory timestamps become powerful once they sit next to disk evidence. timeliner.Timeliner in Volatility 3 collects timestamps from every plugin that exposes them and can write a body file for mactime or Plaso; MemProcFS writes its own timeline files in forensic mode.

vol -f HOST01_mem.raw timeliner.Timeliner --create-bodyfile

Then merge the result into your super timeline, as described in building a super timeline with Plaso. A process creation time from memory next to its Prefetch entry and a 4688 event is strong corroboration; a process that exists only in memory is a lead worth chasing (see evidence of execution).

Pitfalls

• Smear. Acquisition is not instantaneous. Pages captured at different times can produce inconsistent structures: truncated lists, processes pointing to freed memory, plugins that crash. Rerun the plugin, cross-check with a scanning plugin, and do not over-interpret a single odd result.
• Compressed memory (Windows 10 and later). Pages evicted to the memory compression store (the MemCompression process) are compressed. Standard plugins and string searches can miss data held there. Support for the compressed store varies by tool and version; do not treat "not found" as "not present".
• Paged-out data. Anything paged to pagefile.sys is missing from the RAM image unless you also collected the pagefile.
• VBS and Credential Guard. With Virtualization-Based Security, some memory is isolated from the normal OS. Credential Guard secrets live in LsaIso.exe and are not recoverable from the image. HVCI and the vulnerable driver blocklist can also stop older acquisition drivers from loading; test your tools on current builds.
• Symbol mismatches. A wrong or missing ISF produces errors or garbage. Check windows.info first.
• malfind noise. RWX private memory is not malware by itself. Confirm with content, context and a second artifact.
• Anti-forensics. Malware can tamper with structures or detect acquisition drivers; see detecting anti-forensics.

Workflow checklist

1. Capture RAM first on live systems (or suspend the VM), hash the image, and note the capture time and tool version.
2. Collect hiberfil.sys, pagefile.sys, swapfile.sys and crash dumps with the disk triage collection.
3. Run windows.info and fix symbols before anything else.
4. Build the process picture: pslist, pstree, psscan, cmdline.
5. Map the network: netscan, netstat, and pivot to owning processes.
6. Look for injection: malfind, dlllist, ldrmodules, then YARA.
7. Examine handles, services and in-memory registry keys for persistence and C2 artifacts.
8. Dump suspicious processes and files, hash them and triage them.
9. Build a memory timeline and merge it with disk artifacts.
10. Document every plugin run, version and output file so the analysis can be reproduced.