In this module
MF0.10 Interactive Lab — Verify Lab Setup
You've built the three-VM lab in MF0.9 and installed the analysis toolset on your workstation. Before moving to MF1 — where the course starts capturing real attack-modified memory — the lab needs a smoke test. Can you capture memory from the Target-Win VM? Can Volatility 3 parse what you captured? Does the output look right, or is something silently miscofigured?
This lab is the end-to-end validation. Capture memory from clean Target-Win using WinPmem, transfer the image to the analysis workstation, run windows.info, verify the output matches what a healthy Windows 11 memory image should look like. Ninety minutes of work that confirms the entire MF0.9 build before MF1 assumes it.
If the lab produces clean output, the learner is ready for MF1. If anything fails — WinPmem won't run, Volatility 3 can't parse the image, the output looks wrong — this lab surfaces the problem now, while the fix is isolated to the lab environment, rather than in MF2 when the fix competes with a real attack analysis.
Deliverable: A memory image captured from clean Target-Win, verified intact via SHA-256 hash, transferred to the analysis workstation, parsed by Volatility 3's windows.info plugin with output matching the expected Windows 11 profile. Lab-readiness confirmed; you're ready for MF1.
What this lab tests
Four independent things need to work for the rest of the course to run. This lab tests each one in sequence.
WinPmem can execute on Target-Win. If Defender's residual Tamper Protection blocks it, or if the signing chain is broken on the binary you downloaded, the capture never starts. This is the most common MF0.9 misconfiguration — the lab's first check.
The capture completes without smear or tear. WinPmem captures while Windows is still running, so process lists can shift mid-capture. A well-configured VM with enough RAM produces a clean capture; an over-subscribed host with aggressive paging produces a torn one. Running this lab now establishes what "clean" looks like on your hardware so you recognise "torn" in later modules.
File transfer from the VM to the analysis workstation works. The VM's host-only network has no route to the workstation's LAN, so transfer happens via hypervisor file share (VMware's shared folders or VirtualBox's guest additions). If that's misconfigured, every subsequent capture requires a manual USB workaround.
Volatility 3 can parse what you captured. This is a two-way check: Volatility 3's symbol tables need to match the Windows 11 build, and the image has to be structurally sound. A valid capture against an unsupported build fails silently with wrong offsets; an invalid capture against supported symbols fails loudly with "unable to find kernel." Both need ruling out before MF1.
The lab
Work through the simulator below. Each phase has expected output that confirms the step worked. If any phase fails, the simulator's help text points to the MF0.9 section that covers the underlying configuration.
What the output should tell you
Running windows.info on a clean capture produces output with a dozen fields. Most are confirmation noise; four of them are the actual readiness signal.
Kernel Base. A plausible kernel address starts with 0xfffff8... on 64-bit Windows. If Volatility 3 reports 0x00000000 or a value that doesn't start with 0xfffff, the image couldn't locate the kernel and the rest of the output is meaningless.
KernelFileVersion. Should be 10.0.22621.xxxx or 10.0.22631.xxxx for Windows 11 23H2/24H2, or 10.0.26100.xxxx for Windows 11 24H2. If it shows a much older build (e.g. 10.0.19045.xxxx for Windows 10), you captured from the wrong VM or the Windows 11 install reverted to an older update channel. Not fatal — the rest of the course tolerates any Windows 11 build — but worth confirming matches the OS you think Target-Win is running.
SystemTime. Should be within a few seconds of when you ran the capture. Memory timestamps are in UTC; if your VM is configured for a local timezone, the VM's clock shows local time but memory stamps show UTC. A 5-hour delta between SystemTime and your capture wall-clock is normal and correct. A 5-day delta is a sign the VM's clock is wrong, which causes problems later for timeline correlation.
KeNumberProcessors. Matches the vCPU count you set for Target-Win (2 in the MF0.9 build procedure). If it shows 0 or 1 when you configured 2, the VM didn't expose both cores to Windows — a hypervisor CPU configuration issue that will affect every subsequent capture's multi-threaded process analysis.
If all four fields match expected values, the lab is operational. If any one is wrong, fix it now — MF1's acquisition module assumes Target-Win captures work correctly.
Troubleshooting — the three most common failures
If the simulator surfaces an error it couldn't walk you through, the cause is almost always one of these three.
WinPmem reports access denied. The command prompt doesn't have administrator rights. Close the window, right-click the Command Prompt in the Start menu, "Run as administrator," retype the WinPmem command. Memory acquisition requires kernel-level access and won't work from an unelevated shell.
Volatility 3 reports "unable to find kernel" or "no valid kernel found." Two possible causes. Either the image is corrupt (incomplete capture because Target-Win ran out of disk space mid-write — check the image size matches Target-Win's RAM), or Volatility 3's symbol pack doesn't include the Windows 11 build you captured. For the latter, source ~/vol3/bin/activate && pip install --upgrade volatility3 pulls the latest symbols; the symbol pack updates monthly to cover new Windows builds.
The file transfer from VM to host produces a zero-byte image on the analysis workstation. VMware's shared folders and VirtualBox's guest additions can both break when VM tools versions drift out of sync with the hypervisor. Re-install VMware Tools (or Guest Additions) in Target-Win to match the current hypervisor version, restart the VM, retry the copy. An alternative: use an SCP transfer from Target-Win to the host over the host-only network (requires OpenSSH Server on Windows, which is a single-command install).
Ready for MF1
Once the lab produces clean output, the course's lab infrastructure is confirmed operational. MF1 extends this work: properly captured memory on both Windows and Linux, pagefile and hibernation file acquisition, smear detection, and the clean baseline captures the paid modules depend on.
The memory image you captured in this lab can be retained as your first analysis artefact, or discarded — MF1 walks through capture again with additional rigour and will produce the baseline image the course expects you to keep. Either way, the lab has served its purpose: the MF0.9 build is validated, your analysis workstation parses output correctly, and you know what a healthy Windows 11 capture looks like.
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