Windows Memory Forensics with Volatility 3: A Practical Walkthrough

Windows Memory Forensics with Volatility 3: A Practical Walkthrough

Disclosure: The companion video is a paid promotion for TryHackMe. This article accompanies that collaboration and includes my TryHackMe campaign link and discount code.

A Windows memory capture can tell you which processes were present, what they loaded and how they relate to each other. The difficult part is deciding what those observations actually prove.

In my Volatility Essentials video, I work through two TryHackMe investigations: an endpoint suspected of harbouring a banking Trojan, followed by a ransomware case. This guide follows the same investigation, with commands you can revisit and questions to ask of the output.

The aim is to build an evidence trail: identify a process, establish its context, investigate its activity and explain the limits of your conclusion.

Follow along with the lab

Open TryHackMe through my campaign link and find Volatility Essentials. The room was available on the free tier when I recorded the walkthrough. Follow the room's instructions to start its lab machine and locate the supplied memory images.

You will need a TryHackMe account, the room's lab environment and a little familiarity with the Linux terminal. The lab supplies the investigation files; you do not need to capture memory from your own computer to follow along.

For a local practice environment, my VMware cybersecurity lab guide covers the VM setup. Memory acquisition is a separate step: Volatility analyses a capture rather than creating one.

A note about the commands

The examples below use Bash in the Linux lab and run from the directory containing vol.py. Set these paths to the actual files supplied by your room:

CASE1="/absolute/path/to/first-memory-image.vmem"
CASE2="/absolute/path/to/second-memory-image.raw"

Those are placeholders, not download locations. Check the directory and filenames in your lab before running the examples.

python3 vol.py -h
python3 vol.py windows.pslist -h

Global options such as -f go before the plugin name; plugin options such as --pid follow it. The official Windows tutorial documents this command structure.

Start with the image, not the suspected malware

Video: 01:39 for memory versus disk; 06:26 for image information.

A memory capture is a snapshot, not a complete activity log. It can retain process structures, loaded modules, handles and network objects. Some artefacts may remain after a process exits; others may already be gone or unreadable.

Before analysing the first case, record the image hash and save the system information:

sha256sum "$CASE1"
python3 vol.py -f "$CASE1" windows.info

Record the Volatility version displayed by the tool, the image filename, your command and the output. That makes it possible to repeat the analysis and compare results later.

Use windows.info to establish the Windows build, architecture and available system context. Treat the reported system time as a value recovered from the image. In a real investigation, compare it with acquisition records and clock information before treating it as an independently verified capture time.

If this first command fails, resolve the image-path, layer or symbol problem before interpreting downstream output. An unreadable image is not evidence of a clean system.

Case 1: reconstruct the process story

Video: 05:08 for the scenario; 08:55 for process plugins.

The first scenario describes a quarantined endpoint suspected of a banking Trojan masquerading as an Adobe document. That gives us a lead to investigate, rather than a verdict about every Adobe-related process.

Start with three views:

python3 vol.py -f "$CASE1" windows.pslist
python3 vol.py -f "$CASE1" windows.psscan
python3 vol.py -f "$CASE1" windows.pstree

In the walkthrough, I follow reader_sl.exe and trace its recorded parent to explorer.exe, PID 1484. That is a relationship recovered in this particular lab image. It does not establish that Explorer is malicious, or that the same PID will mean anything on another system.

Inspect the full process tree before narrowing the output. A text search can find a name quickly, but it can also remove the headers and surrounding rows you need to understand the relationship.

The filtered process scan connects reader_sl.exe (PID 1640) to explorer.exe (PID 1484). Read the PID and PPID columns together. Captured at 12:18 in the video.

Write down the target PID and PPID separately. This matters in the next stage: inspecting a child's DLLs and inspecting its parent's DLLs answer different questions.

Inspect DLLs and handles for the chosen process

Video: 12:43.

Choose the PID that answers your current investigation question. In the video I also inspect PID 1484, the parent process; do not automatically reuse that value when you mean to examine the Adobe-related child.

The following Bash command asks you to enter the PID you have selected:

read -r -p "PID to investigate: " TARGET_PID
python3 vol.py -f "$CASE1" windows.dlllist --pid "$TARGET_PID"
python3 vol.py -f "$CASE1" windows.handles --pid "$TARGET_PID"

dlllist shows loaded DLL information. Look at the paths and ask whether they fit the process and its installed application. A DLL outside System32 is not automatically malicious: legitimate applications load their own libraries from application directories.

Likewise, do not count every line in a filtered terminal view as a DLL. Check that you are counting actual module rows for the intended PID, rather than headers or unrelated output.

Handles add another view of what the process references, such as files, registry keys, events and other objects. A handle name is a useful observation; it does not, by itself, explain how that object was used.

The DLL plugin reference describes the loaded-module view. Use the plugin's -h output to check the options available in your installed version.

Add network context

The room introduces network plugins alongside the process tools. To extend your investigation, inspect recovered network objects:

python3 vol.py -f "$CASE1" windows.netscan

Compare any relevant PID, address, port and available timestamp with your process notes. If the scenario supplies a suspicious address, record whether you actually found a matching artefact and which process it was associated with.

netscan is a scan of memory-resident network objects, not a packet capture. It cannot show you the full conversation or prove what data crossed a connection. A missing result also does not rule out earlier activity. See the NetScan reference for the plugin's scope.

Investigate suspicious executable memory

Video: 15:41.

The next question is whether a process contains memory regions that deserve closer inspection for possible injected code.

Current Volatility documentation uses:

python3 vol.py -f "$CASE1" windows.malware.malfind

The video uses the older windows.malfind name. If you are working in the same older lab environment, use the name listed by python3 vol.py -h. The old plugin reference identifies its replacement as windows.malware.malfind.

The output in the walkthrough includes regions starting with MZ, a signature associated with DOS headers in Windows PE files. That is a reason to examine the region further. Those two bytes alone neither validate a complete executable nor identify malware.

Look at the region starting at 0x1460000 for explorer.exe and 0x3d0000 for reader_sl.exe. Both show 4d 5a (MZ) at the beginning of the displayed bytes. These are investigation leads, not standalone malware verdicts. Captured at 17:24 in the video.

For a flagged process, inspect its virtual address descriptors:

python3 vol.py -f "$CASE1" windows.vadinfo --pid "$TARGET_PID"

Make sure TARGET_PID now refers to the process flagged by malfind. Compare the reported address range, protection and available backing-file information with the suspicious region.

The Malfind documentation describes potential injected-code regions. Treat them as leads. Legitimate software can also create executable memory, and the absence of a hit does not rule out compromise.

Inspect kernel artefacts when the question calls for it

Video: 17:42.

The room then introduces the System Service Descriptor Table, or SSDT, and asks us to locate a system-call address:

python3 vol.py -f "$CASE1" windows.ssdt
python3 vol.py -f "$CASE1" windows.modules
python3 vol.py -f "$CASE1" windows.driverscan

These provide different views of system-call entries, loaded kernel modules and driver objects. Use them to investigate a specific anomaly or answer a defined question.

Finding an SSDT entry's address completes the room's lookup task. It does not demonstrate that the entry has been hooked. A hooking claim needs further analysis of the destination and the expected behaviour for that system.

Case 2: investigate the ransomware lead

Video: 19:13.

The second scenario describes an organisation recovering from ransomware and supplies another memory image. Start a fresh set of notes: observations from case 1 do not carry over to this capture.

sha256sum "$CASE2"
python3 vol.py -f "$CASE2" windows.info
python3 vol.py -f "$CASE2" windows.pslist --pid 740
python3 vol.py -f "$CASE2" windows.pstree

PID 740 is the lead supplied in this lab. In the video, it returns a WannaDecryptor-related process name. I then inspect its path and parent relationship. The lab accepts WannaCry as the malware-family answer.

PID 740 has PPID 1940, linking it to tasksche.exe. The wrapped rows below the process entries contain the paths; follow each row carefully rather than treating every displayed line as another process. Captured at 20:47 in the video.

For your own evidence notes, separate those statements:

• Observed: the process entry, PID, reported path and parent relationship recovered from the capture.
• Lab conclusion: the scenario identifies the malware as WannaCry.
• Further work for a real incident: corroborate the identification with recovered-file analysis, hashes, behaviour and other host evidence.

A familiar filename is easy to imitate. The AI tutor's explanation in the video is useful learning context, but it is not independent forensic evidence.

Look for file objects connected to the working directory

Video: 23:00.

python3 vol.py -f "$CASE2" windows.filescan

Use the directory identified during your process investigation to guide your review of the output. Preserve the full results before filtering them down.

As the FileScan reference explains, this scans for file objects in the memory image. It is not a complete directory listing and does not automatically recover each file's contents. A matching path is a lead to correlate with the rest of the evidence.

Keep an evidence table as you work

For each finding, record what you observed and what you still need to check. This is the format I would use alongside the lab:

Before finishing, check that you can answer these questions:

1. Which image and tool version produced each result?
2. Did I inspect the intended PID, or accidentally switch to its parent?
3. Does another artefact support the relationship I am claiming?
4. Could a legitimate activity explain this finding?
5. What would I need to collect next to test my conclusion?

Repeat the investigation yourself

Open the room and work through each question before checking the video. For the ransomware case, try writing a short explanation of the process, its parent and the supporting file artefacts. Then state what the capture cannot establish.

Sign up to TryHackMe for free. If you choose an annual Premium subscription, the offer supplied for this collaboration is 25% off with code JOSHUAC25. Check the current offer terms when signing up.

For more practical security projects, continue with my Wazuh SIEM home lab guide. The useful habit to carry forward is the same: keep the observation, your interpretation and the evidence needed to confirm it distinct.