HackBlue

Tools · Forensics tools · 06 / 25

Volatility 3: an image, a symbol table, and the first plugin

A memory image is a snapshot of RAM. Volatility 3 can read it only after a symbol table matches the kernel that was running. windows.info is how you check that match before you believe a process list.

16 min read · practice only with authorization

What you were handed

A memory image is the contents of RAM as some tool copied them at one moment, plus whatever header that tool added. It is not a disk, and it is not a recording of the whole morning. Pages that were swapped out may be missing. Pages that were freed can still hold leftovers. The snapshot answers questions about what was resident when the copy was taken, and it stays silent about everything that had already left RAM.

For NL-2026-041 the lab already has NL-FIN-14.raw, taken at 09:22 America/New_York, before the laptop was shut down for the afternoon disk image. You treat the raw file the way you treated the E01: hash it, record the hash, and work on a copy. Volatility reads the image. It should not be the only copy. The command you will live in is a plugin name after the file, and the plugin names in Volatility 3 are dotted: windows.info, windows.pslist, windows.netscan.

Snippet
vol -f NL-FIN-14.raw windows.info

Symbol tables replaced the old profile string

Volatility 3 learns the offsets of kernel structures from a symbol table for that Windows build. The table is selected from identifiers in the image, often the kernel’s debugging information. When the table matches, plugins can walk lists and print fields with names you recognize. When it does not, you get an error, an empty table, or numbers that do not correspond to real processes. Those numbers are not a hidden result. They are a failed match.

windows.info is the first plugin because it reports whether that match happened and which kernel it thinks it sees. Read the output and write down the kernel version and the symbol table name. If the lab cannot reach a symbol server, use the symbol pack that was downloaded for the lab and point the tool at it the way that pack’s README says. Record the file you used. “It worked on my other machine” is not a symbol table.

A plugin is a question

Each plugin answers one shaped question. windows.pslist walks the kernel’s live process list. windows.psscan scans memory for process objects that may already have left that list. windows.cmdline reads command lines where the process environment block still holds them. You run the question you have, and you name the plugin in the note next to the answer. Two plugins that disagree are a finding about the image, and you keep both outputs.

Filter when the plugin allows it. A pid filter on windows.cmdline keeps the note about the one process you already care about. Save the text output into the case folder with the plugin name and the image hash in the filename. A screenshot of a partial table is harder to diff later. The terminal scrollback is not a record.

  • Image filename and SHA-256.
  • The windows.info kernel line and the symbol table that matched.
  • Each plugin you ran, with the time you ran it.
  • The output file’s name, stored next to the case number.

What a match still does not mean

A successful windows.info means the structures were readable enough to describe the kernel. It does not mean every page is present, and it does not mean the snapshot was taken at the moment you wish it had been. Write the acquisition time next to the disk timeline. If memory was taken at 09:22 America/New_York and the workbook copy was at 09:18, you are looking at RAM from after the event. Processes that exited may still be findable. Processes that exited and whose pages were reused will be gone. The clock on the acquisition is part of the interpretation.

Stay inside the image you were given. Practice plugins on this file or on a memory sample the range allows. Another machine’s RAM is another person’s work, and it is outside NL-2026-041 even when the same command would run.

Worked case: windows.info before any theory

You hash NL-FIN-14.raw and it matches the SOC sheet. windows.info prints a Windows 10 kernel build consistent with the disk image’s OS version, and it names the symbol table it loaded. You paste those lines into the case log under “memory, acquired 15 April 2026 09:22 America/New_York.” The disk window you care about is 09:12 to 09:18, so this snapshot is later. You write that down before you go looking for powershell.

The first saved output is NL-2026-041-windows-info.txt. You have not claimed a process is suspicious. You have claimed that later plugins are reading a matched kernel, on the image Northline sent, taken after the file copy.

Diagram

From a raw image to a plugin you can cite

  1. Hash

    Confirm the memory file matches the hash you were given. Work on a copy.

  2. Symbols

    Run windows.info. Record the kernel and the symbol table. Stop if they are missing.

  3. Clock

    Write the acquisition time in the case timezone next to the disk window. The snapshot is one moment.

  4. Plugin

    Run one plugin for one question, and save the text under the case number.

    First commands
    vol -f NL-FIN-14.raw windows.info
    # After the kernel line looks right:
    vol -f NL-FIN-14.raw windows.pslist

Check yourself

1. windows.info fails to identify a kernel, and windows.pslist then prints a short table of strange names. What should you trust?