In this module
MF0.9 Lab Environment Setup — VMware, Target-Win, Target-Linux, and Kali
From MF0.1-0.8 you understand what memory forensics is, what lives in memory, how the workflow runs, how addressing works, what the tools are, and what the legal context looks like. What you don't have yet is an environment to do any of it in. This sub is where the course becomes hands-on — you build the three virtual machines that every subsequent module uses, on your own hardware, under your full control.
Applied Memory Forensics is the course where you execute an attack, capture the resulting memory image, and analyse what your own attack produced. That loop requires three virtual machines, running on your own hardware, on a network isolated from anything else you care about. No attacks run 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 Target-Win (Windows 11 Evaluation), Target-Linux (Ubuntu 22.04 LTS), and Kali Linux all running in VMware Workstation, all connected by a host-only network, all with clean baseline snapshots taken. The three-VM lab is the platform every subsequent module uses; this is the sub where it gets built.
The investment is real — expect 2 to 3 hours to walk through the full build, plus ~70 GB of disk and 10 GB of RAM allocation peak (3 GB Target-Linux + 4 GB Kali + 4 GB Target-Win when all three run simultaneously, which only happens during attack execution). The cost is zero; every component listed is free for the use this course puts it to.
Deliverable: A working three-VM lab — VMware Workstation installed, Target-Win 11 built and snapshotted, Target-Linux (Ubuntu 22.04) built and snapshotted, Kali Linux built and snapshotted, a host-only network connecting all three VMs with no path to the internet or the learner's corporate network, and a verified mesh of inter-VM connectivity confirming the lab is ready for MF0.10's first memory capture.
Figure 0.9.1 — The three-VM lab topology. Kali attacks Target-Win and Target-Linux across a host-only network that has no route to the internet or the learner's corporate LAN. All three VMs live on the learner's machine under VMware Workstation. The analysis station is the learner's host OS (or a separate analysis VM if preferred). Snapshots on each target VM allow clean resets between attack modules.
Hypervisor selection and install
VMware Workstation Pro is the primary recommendation. It's free for personal use as of 2024, handles Windows 11 reliably, supports the .vmem suspend-file acquisition pattern that MF1 teaches, and has stable snapshot semantics. VirtualBox is the open-source fallback.
VMware Workstation Pro went free for personal use in May 2024. Download from the Broadcom portal (registration required) — the installer runs on Windows and Linux host OSes. The reason Workstation is preferred over the free ESXi or the older Workstation Player: Pro includes snapshot trees, multi-VM scripting, and the ability to pause a VM and directly read its .vmem suspend file (which MF1 uses for the hypervisor-based acquisition pattern). Player omits these features.
VirtualBox works but has two annoyances for this course. Windows 11 installation is harder — you need the TPM-enabled VirtualBox 7.0 or later, plus a registry-bypass trick for the Secure Boot check. And VirtualBox's .vmem files have a different internal format, so some of the course's acquisition examples need translation. If you already have VirtualBox running happily, keep it and work around these friction points. If you're starting fresh, use VMware.
Install the hypervisor with default options. On Linux hosts, confirm virtualisation extensions are enabled in BIOS (Intel VT-x or AMD-V) — without them, VMs will run orders of magnitude slower, which makes memory acquisition unreliable. On Windows hosts, Hyper-V must be disabled because it takes exclusive control of the CPU's virtualisation extensions; VMware's installer warns about this but doesn't always fix it automatically. If VMs fail to start with a "VT-x is being used by another hypervisor" error, disable Hyper-V via bcdedit /set hypervisorlaunchtype off from an elevated command prompt, reboot, and retry.
Building Target-Win (Windows 11 Evaluation)
Target-Win is the victim of MF2 through MF6 and MF9. Build it once, take a clean snapshot, then revert to the snapshot between modules to get a consistent starting state.
Microsoft provides a free 90-day Windows 11 Enterprise Evaluation ISO at microsoft.com/en-us/evalcenter. Download the ISO (about 5 GB). Create a new VMware VM with: 4 GB RAM, 2 CPU cores, 60 GB thin-provisioned disk, the Windows 11 ISO mounted, and the VM's network adapter set to VMnet1 (host-only) — we'll create VMnet1 shortly. Use UEFI firmware with secure boot enabled (Windows 11 requires it). VMware 17 and later handles the Windows 11 TPM requirement automatically via a virtual TPM; older versions need manual workarounds.
Install Windows 11 as a local account (the Enterprise Evaluation installer doesn't require a Microsoft account). Username investigator is a reasonable convention; password is whatever you'll remember. Install VMware Tools once Windows is up — this enables smooth cursor handling, shared-folder support, and most importantly, clean suspend-to-disk behaviour which MF1 uses for hypervisor-based memory acquisition.
Configure Windows Defender as the course expects: leave Real-time Protection on for baseline modules (MF0.10 captures a clean system with Defender active), but know how to disable it quickly for attack modules where you need a compromised process to survive long enough to capture memory. Set-MpPreference -DisableRealtimeMonitoring $true from an elevated PowerShell disables it; re-enable with $false. You'll toggle this repeatedly as the course progresses.
Take a snapshot called "clean-baseline" once Windows is fully installed, VMware Tools is loaded, and Defender is in its default state. This is the snapshot MF0.10 captures from, and it's the snapshot you revert to before every subsequent module's attack. The 90-day evaluation timer starts ticking the moment Windows boots. Use slmgr -rearm from an elevated command prompt to reset the 90-day counter; this works up to three times, giving you effectively a year of runway.
Building Target-Linux (Ubuntu 22.04 LTS)
Target-Linux is the victim of MF7 only. Lighter-weight than Target-Win, but configured with intentional SSH weaknesses the MF7 brute-force attack depends on.
Download the Ubuntu 22.04.4 LTS server ISO from ubuntu.com/download/server (around 1.5 GB). Create a VMware VM with: 2 GB RAM, 2 CPU cores, 40 GB thin-provisioned disk, the Ubuntu ISO mounted, network adapter on VMnet1. UEFI firmware, secure boot disabled (Linux distros don't require it and it simplifies later kernel-module work for MF7). Install Ubuntu with the default options, create a user account called admin with the password admin123! — this is an intentionally weak credential that MF7's SSH brute-force attack will target.
Install OpenSSH during the installer's "Featured Server Snaps" step, or add it after install with sudo apt install openssh-server. Confirm SSH is running: sudo systemctl status ssh. Edit /etc/ssh/sshd_config to allow password authentication (PasswordAuthentication yes) — default modern Ubuntu installs leave it off, which would block the brute-force attack. Restart SSH: sudo systemctl restart ssh.
Install VMware Tools (sudo apt install open-vm-tools) and install kernel headers to enable later LKM work (sudo apt install linux-headers-$(uname -r)). The kernel headers are specifically needed for MF7's rootkit lab — without them, the PoC LKM won't build on the target. Take a snapshot called "clean-baseline." The MF7 attack reverts to this between runs.
Building Kali Linux
Kali is your attacker VM. One install, no baseline re-use needed — the attacker state is generally fresh-tool-install rather than from-snapshot revert.
Download the Kali Linux VMware VM appliance from kali.org/get-kali/ — the appliance is faster to set up than an ISO install because it ships pre-configured with the attacker tooling. The download is about 4 GB. Import it in VMware: File → Open → select the .vmx file. Adjust RAM to 4 GB, CPU to 2 cores, network adapter to VMnet1.
Default credentials are kali / kali — fine for lab use. First boot, run sudo apt update && sudo apt full-upgrade -y to bring tooling current. Confirm Metasploit, Mimikatz, Impacket, and PowerShell Empire are installed: msfconsole -v, which mimikatz.exe, which impacket-smbclient, which empire. If any are missing, install from the Kali repositories (sudo apt install metasploit-framework impacket-scripts). Take a snapshot called "kali-baseline" — you'll revert to it if a module's attack tooling leaves Kali in a weird state.
Network configuration: Kali, Target-Win, and Target-Linux all live on VMnet1. Confirm Kali's IP is in the 192.168.56.0/24 range. If it isn't, VMnet1 wasn't configured correctly — return to the hypervisor and verify.
Host-only network configuration
The host-only network is what keeps your attack traffic inside your machine. Attacks never touch your corporate network, the public internet, or any shared infrastructure — they run entirely between the three VMs you control.
VMware's host-only networks are managed through Edit → Virtual Network Editor (or vmware-netcfg on Linux). VMnet1 is the default host-only network on a fresh install; if it isn't, create it: Add Network, type Host-only, subnet 192.168.56.0/24, DHCP enabled, no connection to the host network. The specific subnet doesn't matter as long as it doesn't collide with your corporate network — 192.168.56.0/24 is the VirtualBox convention and works for VMware too.
Verify isolation before running any attacks. Open a terminal on Kali and run ip route — there should be no default gateway leading to the internet. Run ping 8.8.8.8 — it should fail (no route to host). If it succeeds, the VM is somehow connected to your physical network, which means your attack traffic could escape the lab. Fix before continuing.
Verify inter-VM connectivity. From Kali, ping Target-Win's IP and Target-Linux's IP. Both should respond. From Target-Win, ping Kali (via its IP, not hostname). From Target-Linux, same. You should have a full mesh: six successful pings total. Windows Firewall blocks inbound ICMP by default — enable it temporarily for lab connectivity verification, then leave it in whichever state the module's attack requires. The Guided Procedure below walks this end to end.
This is the full end-to-end lab build, in the order you should tackle it. Expect 2 to 3 hours. Working from top to bottom produces a verified, snapshot-clean lab ready for MF0.10.
When all five steps complete, your three-VM lab is operational. MF0.10 captures memory from the clean Target-Win snapshot and validates the setup end to end.
The situation. You've built the three lab VMs and you're planning how to do memory analysis. Two approaches present themselves: install Volatility 3 and your analysis tools on your host OS and analyse the .vmem files directly, or build a fourth VM (an Analysis-Station VM) and do all analysis inside it. The course material is usable with either approach; your choice affects how cleanly your investigation work is isolated from the attack traffic.
The choice. Analyse on the host, or build a dedicated analysis VM.
The correct call. For learners: analyse on the host is fine. The attack traffic stays inside the host-only network; memory images you copy to the host for analysis are just files. An analysis VM adds friction (install Volatility 3 twice, maintain another VM, copy files between VMs) without adding meaningful safety. The pragmatic choice is host analysis.
For practitioners doing this in a real investigation context: build the analysis VM. Real-world cases often involve adversary material that you don't want on your daily-driver machine — malware samples, hostile payloads dumped from memory, possibly live network artefacts. The analysis VM lets you segregate that material cleanly. It also gives you a reproducible analysis environment that doesn't change as your host OS does.
The operational lesson. Isolation is layered. The host-only network isolates the attack VMs from the outside world. The analysis-VM-vs-host decision isolates analysis from the attack VMs. You don't need both layers for this course, but in real work you probably do.
The myth. The VMs only talk to each other. They don't have internet access. That's isolation — no need to check further, no need to configure a specific host-only network, no need to disable default NAT adapters or verify that traffic can't escape.
The reality. "Not connected to the internet" isn't automatic when you build a VM. VMware's default network adapter is NAT, which gives the VM internet access through the host's connection. VirtualBox's default adapter is the same. If you accept defaults during VM creation and don't explicitly switch to a host-only network, your attack VMs reach the internet, your attack traffic leaves your machine, and — if the course's attacks ever accidentally point outward — you're executing attack traffic against real systems you don't own.
The verification check that catches this is explicit: from the attacker VM, ping 8.8.8.8. If that succeeds, the VM has internet access and is not isolated. Stop and fix the network adapter before running a single attack. The same check applies every time you add a new VM to the lab; default adapters drift toward NAT and each new VM is a potential escape path.
The principle is stronger than "don't cause internet-bound attack traffic." Lab isolation also protects against malware you encounter in real investigations. If you later import a memory image from a real incident into your lab for analysis, you don't want the VM that's running your analysis tools to have a route to attacker infrastructure. The host-only network is the habit you want established before you need it.
Try it — Verify the full lab mesh
Setup. All three VMs built and running per the Guided Procedure above. All three on VMnet1. Know the IP of each VM (ip a on Kali and Target-Linux, ipconfig on Target-Win).
Task. Run a connectivity mesh test. Open terminals on all three VMs simultaneously. From each VM, ping the other two. Record the six results. Separately, from Kali, attempt ping 8.8.8.8 and record whether it succeeds.
Expected result. All six inter-VM pings succeed within a few milliseconds. Kali's ping 8.8.8.8 fails with "Destination Host Unreachable" or "Network is unreachable" — no route to the internet confirms isolation. If Kali can reach 8.8.8.8, the network adapter is on NAT rather than VMnet1 and needs to be changed before you run any attacks.
If your result doesn't match. If Target-Win doesn't respond to pings but can ping out, Windows Firewall is blocking inbound ICMP — enable File and Printer Sharing in Windows Defender Firewall's allowed apps list. If two VMs can ping each other but the third can't, that third VM's adapter is likely on a different VMnet — check VM Settings → Network Adapter and confirm VMnet1 is selected. If Kali succeeds at pinging 8.8.8.8, switch its adapter to VMnet1 (Host-only) and retry — all three VMs must be on VMnet1 for the course's isolation model to hold.
You should be able to do the following without referring back to this sub. If you can't, the sections to re-read are noted.
You've set up the lab and captured your first clean baselines.
MF0 built the three-VM lab and established the memory forensics landscape. MF1 taught acquisition with WinPmem and LiME, integrity verification, and chain of custody. From here, you execute attacks and investigate what they leave behind.
- 8 attack modules (MF2–MF9) — process injection, credential theft, fileless malware, persistence, kernel drivers, Linux rootkits, timeline construction, and a multi-stage capstone
- You run every attack yourself — from Kali against your target VMs, then capture memory and investigate your own attack's artifacts with Volatility 3
- MF9 Capstone — multi-stage chain (initial access → privilege escalation → credential theft → persistence → data staging), three checkpoint captures, complete investigation report
- The lab pack — PoC kernel driver and LKM rootkit source code, setup scripts, 21 exercises, 7 verification scripts, investigation report templates
- Cross-platform coverage — Windows and Linux memory analysis in one course, with the timeline module integrating evidence from both
Cancel anytime