Reading width
Wide uses the full column for everything — text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
Building the Memory Forensics Lab: Three-VM Setup
The lab is the course
This is the course where you run an attack, capture the memory it produced, and analyze your own evidence. That loop, the attack-capture-analyze model from MF0.1, needs three virtual machines on your own hardware, on a network sealed off from everything else. No attacks against shared infrastructure, no shipped memory images, you capture your own evidence from systems you compromised, every time. This sub builds that environment.
By the end you have three VMs in VMware Workstation, all on one isolated host-only network, each with a clean baseline snapshot: Target-Win (Windows 11 Evaluation), Target-Linux (Ubuntu 22.04 LTS), and Kali (the attacker). The investment is real, budget two to three hours for the full build, roughly 70 GB of disk, and about 10 GB of RAM in use when all three run at once during an attack, but the cost is zero, because every component is free for the use this course puts it to. You do not need the lab to study MF0; you need it built before MF1 has you capturing.
Kali attacks the two targets across an isolated network; the host runs the analysis tools and holds the captured images as files. The single most important property is that the host-only network has no path off the machine, and that property is verified, not assumed.
The hypervisor and the two targets
VMware Workstation Pro is the recommendation, and as of 2024 it is free for personal use from the Broadcom portal, on Windows and Linux hosts alike. Pro is preferred over the cut-down Player because it includes snapshot trees, multi-VM control, and the ability to pause a VM and read its .vmem suspend file directly, which is the hypervisor-based acquisition pattern MF1 teaches. That .vmem capability is worth dwelling on, because it is the cleanest acquisition method available and the course uses it heavily. When you suspend a VMware VM, the hypervisor writes the guest's entire physical RAM to a .vmem file on the host, a complete, consistent snapshot of memory taken from outside the guest, which means the acquisition does not run inside the system being captured and therefore does not perturb it the way an in-guest tool does. For a lab, that gives you a forensically clean image with none of the in-guest footprint a tool like WinPmem leaves, which is exactly why MF1 contrasts the two methods. Snapshot trees matter for a parallel reason: they let you branch from the clean baseline, run an attack down one branch, capture, and revert, without ever losing the pristine starting state. VirtualBox works as a fallback but adds friction: Windows 11 needs the TPM-enabled build plus a Secure Boot bypass, and its .vmem format differs enough that some acquisition examples need translation. Install with defaults, confirm virtualization extensions are enabled in the host BIOS, and on a Windows host disable Hyper-V if VMs refuse to start, since Hyper-V claims the CPU's virtualization extensions exclusively.
Target-Win is the victim of MF2 through MF6 and the MF9 capstone. Build it from Microsoft's free 90-day Windows 11 Enterprise Evaluation ISO: 4 GB RAM, 2 cores, a 60 GB thin-provisioned disk, UEFI with Secure Boot on, and the network adapter set to the host-only network. Install as a local account, add VMware Tools (which enables the clean suspend-to-disk behavior acquisition relies on), and leave Defender at its default state for now. Then take a snapshot named clean-baseline. That snapshot is what the orientation sub captures from and what you revert to before every attack module, so the system always starts from a known-good state. The discipline of revert-to-clean is not housekeeping, it is what makes your captures comparable. If Target-Win drifts, accumulating updates, leftover artifacts from a previous module's attack, a changing set of running processes, then a finding in module five cannot be cleanly attributed to that module's attack rather than to residue from module three. Reverting to the same baseline before each attack means every capture differs from clean by exactly one thing: the attack you just ran. That is the lab embodiment of the attack-capture-analyze principle, you know what is in the image because you know precisely what changed since the snapshot, and it is also why the baseline snapshot is taken with care, with Defender in a known state and the system fully settled, rather than at some arbitrary moment. The 90-day timer starts at first boot; slmgr -rearm resets it up to three times, giving roughly a year of runway.
Target-Linux is the victim of MF7 only, and it is deliberately built with a weakness the MF7 attack depends on. Use the Ubuntu 22.04 LTS server ISO: 2 GB RAM, 2 cores, a 40 GB disk, host-only network, Secure Boot off to simplify the later kernel-module work. Create a user admin with an intentionally weak password, install OpenSSH, and edit the SSH config to permit password authentication, because modern Ubuntu disables it by default and that default would block MF7's brute-force attack. Add VMware Tools and the kernel headers for your running kernel, which MF7's rootkit lab needs to build its proof-of-concept module, then snapshot clean-baseline. The deliberate weaknesses on Target-Linux are a teaching choice worth naming: a real Linux server you are asked to investigate will often have exactly these misconfigurations, password SSH left enabled, a weak account credential, because real environments are imperfect, and building the lab target the same way means the MF7 attack you run is the attack you will actually investigate in the field rather than a contrived one. The lab is not sanitized to be easy; it is configured to be realistic.
The attacker and the network that contains it
Kali is the attacker. The fastest path is the prebuilt Kali VMware appliance from the Kali project, imported and adjusted to 4 GB RAM and 2 cores on the host-only network. Bring its tooling current on first boot, confirm the attack frameworks the course uses are present, and snapshot kali-baseline so you can revert if a module's tooling leaves the VM in an odd state. Kali, Target-Win, and Target-Linux all live on the same host-only network, which is the piece that makes the whole lab safe to attack inside. The reason the attacker gets its own baseline snapshot is subtler than the targets' and worth understanding. The targets revert to clean so each capture differs from baseline by exactly one attack; Kali is reverted for a different purpose, to recover a known-good tooling state when a module's attack leaves the attacker in an odd configuration, a half-configured listener, a modified payload, a tool whose state has drifted. You are not capturing Kali's memory for evidence, so its cleanliness does not affect your findings; what its snapshot protects is your time, by giving you a one-step return to working tooling instead of a debugging session in the middle of a lab. Keeping the two purposes distinct, targets clean for evidence integrity, attacker clean for operational sanity, is part of running the lab deliberately rather than by habit.
That host-only network is the one configuration you verify rather than trust. In VMware's Virtual Network Editor, the host-only network has a private subnet, DHCP enabled, and crucially no connection to the host's network. The verification is concrete and non-negotiable: from Kali, check the routing table for any default gateway to the internet, then run a ping to a public address.
A successful ping to a public address means the VM is not isolated, and the fix comes before any attack runs, because the default VMware adapter is NAT, which silently grants internet access. Then verify the inverse, that the three VMs can reach each other across the host-only network, a full mesh of successful pings between Kali and both targets, so the attacks have a path while nothing has a path out. Note that Windows Firewall blocks inbound ICMP by default, so a failed ping to Target-Win during this check may be the firewall rather than the network; enable ICMP temporarily to confirm connectivity, then set the firewall to whatever the module's attack requires.
A note on where you analyze
You can run the analysis tools, Volatility 3, MemProcFS, and WinDbg, directly on your host and work against the captured image files there, and for learning this course that is the right choice: the attack traffic stays inside the host-only network, and a memory image copied to the host is just a file. A dedicated analysis VM adds friction without adding meaningful safety in a lab. In real investigations the calculus flips, because you may be handling hostile payloads dumped from a memory image and you want them segregated from your daily machine, so practitioners build an analysis VM. Isolation is layered: the host-only network isolates the attack VMs from the world, and the analysis-VM decision isolates analysis from the attack VMs. The course needs only the first layer; real work usually needs both. Whichever you choose, the rule that does not bend is the isolation check on the host-only network, because that is the layer protecting things outside your control. An analysis VM is about protecting you from hostile material; the host-only network is about protecting everyone else from your attack traffic, and only the second has consequences that reach beyond your own machine.
What you have built
When the three VMs are running on the host-only network with clean baseline snapshots and verified isolation, the platform for the entire course is in place. Target-Win is your Windows victim for the bulk of the modules, Target-Linux is your MF7 victim with its deliberate SSH weakness, Kali is your attacker, and your host holds the toolkit MF0.5 and MF0.6 introduced. The discipline you just practiced, snapshot before, verify isolation, revert to clean between runs, is the same discipline the course repeats in every attack module, so that each capture starts from a known state and produces evidence you can trust.
The next sub puts the toolkit to work against this lab for the first time: a guided orientation through the opening Volatility 3 and MemProcFS commands on a clean capture of Target-Win, so the tools are familiar in your hands before MF1 has you acquiring an image under acquisition discipline. After that, the module closes on an interactive triage that asks you to reason across everything MF0 has built.