Volatility 3 Tutorial: Analyze a Memory Dump Step by Step

A running computer can contain evidence that never gets written to a file on disk. A suspicious process, a command executed by a user, or a network connection may leave traces in RAM. If the system shuts down, some of that information may disappear.

Memory forensics helps investigators examine this volatile data. Volatility 3 is an open-source framework that can extract and analyze artifacts from memory images.

In this tutorial, we will set up Volatility 3, examine a Windows memory dump, investigate running processes, compare process enumeration results, inspect network artifacts, and correlate findings into an evidence-based investigation.

What Is Volatility 3?

Volatility 3 is a memory forensics framework used to analyze RAM images from supported operating systems. It provides plugins for examining different types of artifacts, including processes, network connections, command-line arguments, and loaded modules.

Investigators use it to support malware investigations, incident response, and digital forensic examinations.

However, Volatility 3 does not automatically determine whether a system was compromised. Its output provides evidence that must be interpreted alongside the acquisition circumstances and other available artifacts.

Prerequisites

Before starting, you need:

• Python 3.8 or later, as specified by the current project documentation.
• A terminal or command prompt.
• Volatility 3 installed in an isolated Python environment.
• A Windows memory image obtained from a trusted forensic training source.
• Enough storage space for the memory image and analysis output.

For practice, use a training image from the NIST Computer Forensic Reference Data Sets (CFReDS) or a reputable memory forensics training repository.

Memory acquisition is a separate process. Volatility 3 analyzes an acquired memory image; it does not itself acquire RAM from a live computer. Tools such as WinPmem can be used for acquisition where appropriate. See the official Windows tutorial.

Step 1: Install Volatility 3

Create a virtual environment so that Volatility 3's dependencies remain separate from your other Python projects.

On Linux or macOS, run:

python3 -m venv volatility-env
source volatility-env/bin/activate
python -m pip install --upgrade pip
python -m pip install volatility3

On Windows PowerShell, create and activate the environment with:

py -m venv volatility-env
.\volatility-env\Scripts\Activate.ps1
python -m pip install --upgrade pip
python -m pip install volatility3

Check whether the command is available:

vol -h

If the command is not found, confirm that the virtual environment is active and that the installation completed successfully.

For advanced installations or development work, consult the official Volatility 3 repository.

Step 2: Prepare and Verify the Memory Image

For this tutorial, assume that your training image is named memory.raw.

Before examining it, record its source, filename, acquisition details where available, and reference hash if the publisher provides one.

Calculate its SHA-256 hash.

Linux:

sha256sum memory.raw

macOS:

shasum -a 256 memory.raw

Windows PowerShell:

Get-FileHash .\memory.raw -Algorithm SHA256

Save the resulting hash in your investigation notes.

A matching reference hash supports the conclusion that the downloaded file matches the published reference. It does not independently establish that the original acquisition was complete or that the memory image is free of acquisition errors.

Keep the original image unchanged and perform analysis using a working copy whenever practical.

Step 3: Identify the Operating System

Start by examining the system information Volatility 3 can recover from the image.

vol -f memory.raw windows.info

Here, -f specifies the input memory image, while windows.info identifies relevant Windows kernel and system information.

Depending on the image, the output may include the operating system build, kernel details, architecture, and system time information.

These details help establish whether the selected plugin family is appropriate for the image and provide context for subsequent analysis.

If the command fails, check the file path, image format, and symbol resolution. Volatility 3 may need to locate or generate suitable Windows symbol information before some plugins can run.

A symbol-related error does not automatically mean the image is corrupt. Record the exact error and investigate it before proceeding.

Step 4: List Processes with windows.pslist

Processes provide a useful starting point for understanding the system's runtime state.

Run:

vol -f memory.raw windows.pslist

The output can include:

• PID: Process identifier.
• PPID: Parent process identifier.
• ImageFileName: Process name.
• CreateTime: Recorded process creation time.
• ExitTime: Recorded exit time, when available.

Look for relationships or details that deserve further examination. An unfamiliar process name, an unexpected parent process, or a suspicious command line may provide a lead.

Do not assume that an unusual process is malicious. Legitimate applications, administrative utilities, and security tools can all appear unexpected without the right context.

Record the process identifier and any relevant observations so that you can compare them with other artifacts.

Step 5: Cross-Check Processes with windows.psscan

A stronger investigation does not rely on a single process enumeration method.

Run:

vol -f memory.raw windows.psscan

windows.pslist and windows.psscan use different approaches to locate process information. Comparing their results may reveal processes that warrant further investigation.

For example, a process identified by windows.psscan but absent from windows.pslist could represent a terminated process, a residual object, or another situation that requires examination.

The difference alone does not prove that malware deliberately hid the process.

Compare the process identifiers, names, timestamps, and other available details. Then investigate whether the difference can be explained by the state of the system and the limitations of the memory image.

This cross-check is useful because a process list is an investigative starting point, not a complete account of every process that ever ran.

Step 6: Examine Process Command Lines

Command-line arguments can provide additional context about how a process was started.

Run:

vol -f memory.raw windows.cmdline

Review the process name, identifier, and available command-line information.

An unexpected script path, unfamiliar executable location, or unusual set of arguments may justify further examination. Compare the command line with the process tree and any available executable or event-log evidence.

For example, a process running a script from a temporary directory might deserve attention if its parent process and other artifacts are also suspicious. The directory alone is not evidence of malicious activity.

Command-line information may be incomplete or unavailable. Missing arguments should not be interpreted as proof that the process was harmless.

Step 7: Investigate Network Artifacts

Memory can preserve network-related artifacts that help explain a system's activity around the time of acquisition.

Run:

vol -f memory.raw windows.netscan

Where supported by the image and plugin, the output may contain local and remote addresses, ports, protocols, and connection-state information.

Look for network artifacts that are unexpected in the context of the process or system being examined.

For example, an unfamiliar remote endpoint associated with a suspicious process could be a lead for further investigation. Compare it with firewall logs, packet captures, endpoint telemetry, or other available records.

Keep the limitations in mind:

• A network artifact does not establish who controlled the remote endpoint.
• A connection listed in memory does not, by itself, prove malicious communication.
• Missing network artifacts do not prove that no communication occurred.
• The available evidence depends on the image, the system state, and what remained in memory.

Document the observed values and explain why they warrant further investigation.

Step 8: Examine Loaded DLLs

Dynamic-link libraries (DLLs) provide functionality that processes can load during execution. Examining them may help identify modules that need further scrutiny.

Run:

vol -f memory.raw windows.dlllist

Review the process association, module names, and available path information.

Investigate modules that appear inconsistent with the process or its expected behavior. Where possible, correlate these observations with file metadata, cryptographic hashes, digital signatures, and other evidence.

An unfamiliar DLL is not automatically malicious. Legitimate software can load third-party modules, and memory artifacts may not provide a complete view of every module that was present.

If the results raise concerns, preserve the relevant output and document the next steps rather than treating the plugin result as a final verdict.

Step 9: Correlate the Findings

The real value of memory forensics comes from connecting evidence across multiple artifacts.

Consider this hypothetical training scenario: an unfamiliar process appears in a memory image, and its command-line arguments look unusual.

A reasonable investigation would proceed as follows:

1. Examine the process with windows.pslist.
2. Compare the results with windows.psscan.
3. Review its command-line arguments with windows.cmdline.
4. Check available network artifacts with windows.netscan.
5. Examine loaded DLLs with windows.dlllist.
6. Compare the findings with other available evidence, such as disk artifacts and event logs.

The following table illustrates how to document observations without overstating their significance.

These are investigative leads, not findings from an actual case. The significance of each observation depends on the surrounding evidence.

Step 10: Document the Examination

A defensible forensic examination requires more than a list of commands and screenshots.

Record the following information:

• Source and identity of the memory image.
• Acquisition details and known limitations.
• SHA-256 hash and reference-hash comparison, where available.
• Volatility 3 version and relevant environment details.
• Commands executed and errors encountered.
• Relevant output, observations, and supporting artifacts.
• Alternative explanations and limitations.
• Conclusions that are supported by the available evidence.

Preserve the original output where possible, and make it clear which statements are direct observations and which are interpretations.

This documentation also helps another examiner reproduce the analysis and assess whether the conclusions are justified.

Common Volatility 3 Errors

For plugin-specific options, run:

vol windows.pslist -h

Replace windows.pslist with the plugin you want to inspect. For version-specific issues, consult the official documentation and repository.

Limitations of Memory Forensics

Memory analysis can reveal useful evidence, but it does not provide a complete record of everything that happened on a computer.

Some information may have been overwritten, paged out, or never captured. Acquisition methods can also affect which artifacts remain available.

The absence of an artifact is not necessarily proof that an event did not occur. Likewise, the presence of an artifact does not automatically establish malicious intent or identify the person responsible.

The strongest conclusions come from correlating memory artifacts with independent evidence and clearly documenting uncertainty.

Conclusion

Volatility 3 provides a practical way to examine memory images and investigate processes, command lines, network artifacts, and loaded modules.

Start with system identification, enumerate processes, compare pslist and psscan, and then investigate suspicious findings using additional plugins. Document the results and validate important observations against other evidence.

For students, this workflow builds practical memory-forensics skills. For working investigators, it provides a structured starting point for an examination that must remain reproducible and evidence-based.