Memory Forensics Lab Setup: VM Snapshots, WinPMEM, LiME and Capturing an Image

Introduction

Seven subs have read output from one image that somebody else produced. This one builds the environment that produces your own, because reading output is not the same skill as producing it, and the gap between them is where most of the learning sits.

The fastest route to a working image needs no acquisition tool at all, which is the detail most setup guides bury under a list of software to install. If you have a virtual machine, you already have everything required.

You need very little, and the temptation is to build more than you need before running a single command. The minimum useful lab is two virtual machines on a network that cannot reach anything else, and the second machine is not optional even though every beginner tries to skip it.

One machine is the subject of the exercise: a Windows installation you will run things on and capture. The second exists purely so the first has something to connect to, which matters because a whole class of finding in this course is about network structures, and a machine with nothing to talk to produces none of them at all.

The network setting is the one part to get right before anything else, and it is easy to change later only in theory. A host-only or internal network lets the two machines see each other and nothing else, which is what you want for two independent reasons that happen to point the same way.

The first is obvious: you will deliberately run things that behave like malware, and they must not reach anything real. The second is that isolation makes the output legible. A machine with internet access produces dozens of background connections from update services and telemetry, and finding the one connection you created among them is a needless exercise in frustration when you are still learning what the columns mean.

A third machine is worth adding later but not now. Two is enough to produce every kind of structure this module has examined, and a smaller lab is one you actually use rather than one you keep meaning to finish building.

Snapshot the victim once it is installed, patched and quiet. Every exercise in this module ends with restoring that snapshot, which means you can do something destructive, capture the result, analyze it at leisure, and be back to a clean machine in seconds. Without snapshots you will rebuild the machine repeatedly and do fewer experiments as a result.

Here is the thing worth knowing before you download any acquisition tool. When you suspend a virtual machine, the hypervisor writes the guest's memory to a file on disk so it can restore it later, and that file is a memory image.

Volatility reads that file directly, with the same command shape as everything else in this module. There is nothing to install on the guest, nothing to run as administrator, and no tool to trust, because the hypervisor has already done the work for its own reasons.

That makes the whole loop extremely fast, and speed is what determines how many experiments you actually run rather than intend to. Run something on the victim, suspend, point Volatility at the file, look, resume or restore the snapshot. No administrator prompts, no tool to configure, no argument about whether the acquisition was sound.

It is also the cleanest possible capture in one specific and useful respect. An acquisition tool running inside the machine is itself a process, holding memory and handles, and it appears in every listing you generate. Suspending produces an image with no acquisition tool in it at all, which makes the output easier to read while you are still learning what belongs there.

One practical note before moving on. Some hypervisors keep the memory file only while the machine is suspended and discard it on resume, so copy it somewhere before resuming rather than after. Restoring the snapshot instead of resuming avoids the question entirely and is the habit worth forming.

There is a limitation worth stating plainly so the free route does not become a habit that hides something. This works because you control the hypervisor, which is true in a lab and is very often false in an incident. Learning acquisition properly still matters, and the next section is why.

The free route works in a lab and stops working the moment the machine matters to somebody. A physical workstation cannot be suspended at all, and in an incident you usually cannot suspend a virtual one either, because doing so interrupts a service somebody cares about. That is where acquisition tools come in.

They work the same way in outline: a tool runs with administrative rights, loads a driver so it can read physical memory, and writes the result to a file. The choice between them matters far less than understanding what running any of them does.

PS> vol -f NE-ENG-031-1431.raw windows.pslist | Select-Object -Last 3
PID   PPID  ImageFileName  SessionId  CreateTime
3312  1428  cmd.exe        1          14:07:33
4120  3312  winpmem.exe    1          14:30:58  ◄ the tool, in its own capture
4128  4120  conhost.exe    1          14:30:58

Three seconds before the capture a process appears that had nothing to do with the incident, because you started it. It holds memory, it opened a console, and it is in every listing this image will ever produce.

Expect to find your own tool in the listings, and do not report it as a finding.

That is not a flaw better engineering removes. Reading memory from inside a running system necessarily changes it, so the question is never whether that happened but whether it matters for what you are asking.

The practical consequences are small and worth knowing. Expect to see your own acquisition tool in the process list, and do not report it as a finding, which sounds obvious and is a mistake people genuinely make under pressure. Expect the image to describe the machine over the period of the capture rather than a single instant, because memory changed while it was being read. And capture as early as possible, which is the same point MF0.1 made from the other direction.

Write down what you ran, when you ran it, and on which machine. Two lines in a text file is enough, and that record is what lets somebody else account for the tool's presence in the output rather than wondering about it.

Which tool you reach for is the next question, and the machine usually answers it.

No acquisition tool is right everywhere, and the machine decides rather than preference.

PS> .\winpmem.exe NE-ENG-031-1431.raw
PS> .\DumpIt.exe /O NE-ENG-031-1431.raw /Q

# Linux, kernel module, built against the running kernel
$ sudo insmod lime.ko "path=/mnt/evidence/srv04.lime format=lime"

# Linux and macOS, no module to build
$ sudo ./avml /mnt/evidence/srv04.raw

On Windows, WinPMEM is the open-source reference and the driver MemProcFS uses for live analysis. DumpIt is one executable needing no arguments, which matters when somebody non-technical is at the keyboard. Magnet RAM Capture and FTK Imager are the graphical options most responders meet first. All four load a driver and write physical memory to a file.

On Linux, LiME is a kernel module and inherits MF0.6's problem exactly: it must be built against the running kernel. AVML avoids that by reading through interfaces the kernel already exposes, which makes it the pragmatic choice on a server you cannot compile on, and on cloud instances where nobody is suspending anything.

Velociraptor is worth knowing exists: it collects memory across an estate rather than one host at a time.

What none of them agree on is a format, which is why MF0.6's first question is whether your tool can read what you were handed.

Where they write the output matters more than which one you pick. The machine's own disk overwrites disk evidence; attached storage or the network avoids that and is slower. Decide before the incident, not at the keyboard.

Drawn as before and after, the cost is easy to keep in mind.

What running one costs is the part to internalize. The tool is a program: it is loaded into memory, it allocates memory, it opens handles, and it appears in the very listings you are about to examine. It also overwrites some memory in the course of running, which is memory that will not be in your image.

The practical consequences are small and worth knowing. Expect to see your own acquisition tool in the process list, and do not report it as a finding, which sounds obvious and is a mistake people genuinely make under pressure. Expect the image to describe the machine over the period of the capture rather than a single instant, because memory changed while it was being read. And capture as early as possible, which is the same point MF0.1 made from the other direction: everything this course reads is in memory only until something needs that memory back.

Write down what you ran, when you ran it, and on which machine. Two lines in a text file is enough. That record is what lets somebody else, or you in six months, account for the tool's presence in the output rather than wondering about it.

Memory images come in several formats and the framework handles the common ones without being told which it is looking at.

Knowing which is which matters less than knowing that the distinction exists. A raw image is the simplest: the contents of physical memory, in order, with no structure around it. Most acquisition tools produce this by default and it is what the file extension in this module's examples implies. A crash dump is Windows' own format, produced by the operating system and carrying header information about the machine. Hypervisor suspend files are a third family, and Volatility reads them as well.

PS> vol -f NE-ENG-031-1431.raw windows.info
Kernel Base   0xf80342a00000
SystemTime    2026-03-15 14:31:06

PS> vol -f NE-ENG-031.vmem windows.info
Kernel Base   0xf80342a00000
SystemTime    2026-03-15 14:31:06

PS> vol -f NE-ENG-031-disk.e01 windows.info
unsatisfied requirement: stackers could not open the file

Volatility worked the first two out for itself. A raw acquisition and a hypervisor suspend file are both physical memory, so both return the same kernel base and the same system time from the same machine, and nobody told it which was which.

The third is a disk image, and the error names the reason precisely: the stackers could not find a memory layout to build on, because the file does not contain one. That is not a format Volatility lacks support for. It is a different kind of evidence, and everything this course reads is absent from it by definition.

The last item is the one worth dwelling on because it is a conceptual confusion rather than a technical one. A disk image and a memory image are not two views of the same thing. A process with no file behind it, the unbacked executable page from MF0.3, the handle rights from MF0.4, the network structures from MF0.5: not one of those exists on disk at all, which is precisely why the capture in MF0.1 had to happen while the machine was running.

It is worth adding that the framework works this out for itself. You do not tell it which format you have handed it; it examines the file, recognizes what it is looking at, and builds the layers it needs on top. That is why every command in this module has been the same shape regardless of where the image came from, and it is why an unrecognized format produces a clear error about stacking layers rather than the silence MF0.6 described.

Size is the other practical matter. A memory image is roughly the size of the machine's physical memory, so a modest workstation produces something in the tens of gigabytes. Plan storage before an incident rather than during one, and keep in mind that the analysis machine reads these files repeatedly, so where they sit affects how long every command takes.

Hash the image as soon as it exists, before you copy it, open it or point any tool at it, and record the value alongside the capture notes rather than somewhere separate.

$ sha256sum NE-ENG-031-1431.raw > NE-ENG-031-1431.raw.sha256
$ sha256sum -c NE-ENG-031-1431.raw.sha256
NE-ENG-031-1431.raw: OK

That is the whole procedure and it takes as long as reading the file once. What it buys you is the ability to demonstrate that the file you analyzed in March is the file you still hold in November, which matters more often than people expect and costs nothing to have.

Be precise about what it does not mean, because this is over-claimed routinely. A hash establishes that a file has not changed since it was computed. It says nothing about whether the capture was complete, whether the tool read memory correctly, or whether the machine was already compromised in a way that affected what the tool could see.

The hash establishes one thing: that the file is unchanged since the hash was taken. It does not establish that the capture was complete, that the tool read memory correctly, or that the machine was trustworthy while it was being read. That is integrity of the file, and nothing at all about the fidelity of the capture.

That distinction matters because a hash is sometimes offered as though it answered a question about the evidence. It answers a question about the file. If the acquisition tool missed a region of memory, or the machine was lying to it, the hash of the resulting file is perfectly valid and the image is still incomplete.

Compute it on the acquisition machine if you can, rather than after copying the file somewhere. A hash computed after a transfer establishes integrity from that point onward and says nothing about the transfer itself.

Record the hash in the same file as the capture notes rather than in a separate index, because two files that have to be kept together eventually are not. One text file beside the image, carrying what was run, when, on what machine, and the hash, is enough and survives being forgotten about.

Work the same way in the lab even though nothing depends on it. Habits formed on exercises are the ones that survive an incident, and the cost of hashing an image you made yourself is a few seconds.

The lab exists for exactly one loop, and it is worth stating explicitly, because the common outcome is somebody who builds a working environment and then has no idea what to do inside it.

Here it is. Do something on the victim that you fully understand, start to finish. Capture. Find the thing you did in the output, using the plugins from the last seven subs. Then restore the snapshot so the next experiment starts from the same place. Each pass takes a few minutes and teaches more than any amount of reading, because you knew the answer before you looked and can therefore tell whether you read the output correctly, which is the one thing a downloaded sample can never give you.

you know exactly what you did. now check the output ...

notepad.exe appears, with:
  a CreateTime matching when you clicked
  a PPID pointing at explorer.exe
  a SessionId matching your logon session
# three predictions, three columns, all checkable.

Notice what the loop protects against, because it is the failure this whole module has been circling. Reading output you cannot verify teaches you to recognize shapes without knowing whether your interpretation is right, and that produces confident misreadings. Knowing the answer in advance turns every exercise into a test of your model rather than a demonstration.

Build up from there in small steps. Start a program from a command prompt rather than the menu and watch the parent change. Open a file and find its handle. Make a connection to the second machine and find it in the network output with your program as the owner.

Keep each step small enough that only one thing changed. Two changes at once and a surprising result leaves you unsure which caused it, which wastes the entire advantage of knowing the answer in advance.

Each of those maps directly onto one of the earlier subs, and doing them in that order means every plugin you have read about becomes something you have personally used against a result you knew in advance. That is the difference between recognizing output and reading it.

Four decisions made at setup save real time later, and none of them takes more than a minute to get right. All four are the kind of thing that is trivial now and annoying to change once you have a directory full of images.

None of them is about capability. They are about whether the lab stays pleasant enough to keep using after the first week, which is the thing that actually determines how much you learn from it.

First, give the victim a modest amount of memory rather than a generous one. Every capture is that size, you will make many of them, and there is no analytical benefit to a large machine in a lab. A small victim means fast captures and small files, which means you do more exercises.

That also keeps the whole loop inside a few minutes, which is the single biggest factor in how many exercises you run.

Name the images consistently, including the machine and the time, the way this module's example does. You will accumulate more of them than you expect and a directory of files called dump1 is useless within a week.

Record what you did alongside each image, in a plain text file next to it. Two lines is enough: what you ran and when. This is the same discipline the acquisition section asked for and the lab is where the habit is cheap to build.

Keep the analysis machine separate from the lab network entirely. Volatility runs on your own machine and the lab is isolated, which means moving files across a shared folder or a copy rather than analyzing on the victim. That separation is good practice in itself, and it also removes any chance of accidentally running something on your own machine that you only meant to examine.

Drill four is worth doing once the others are comfortable. Producing a false positive deliberately, on a machine where you know nothing malicious happened, is the fastest way to internalize the point MF0.3 made at length: the plugins report properties, and the judgment about whether a property matters is yours.

Drill one is the one to do early. An analyst who has seen their own acquisition tool sitting in the process list never again wonders whether an unfamiliar process in an image is the attacker or the responder, and that question comes up in real incidents more often than it should.

You can build an isolated two-machine lab, produce a memory image by suspending a virtual machine or by running an acquisition tool, explain what running one costs and why that is unavoidable, name the formats Volatility accepts and why a disk image is not one, hash an image and state precisely what the hash establishes, and run the predict-then-check loop that turns reading into reading correctly. MF0.8 puts the whole module to work on an image you have not seen.