In this module
MF1.9 Building the Evidence Library — Clean Baselines
From MF1.1-1.8 you know how to capture, verify, assess, and document memory images from Windows and Linux systems. You've captured test images along the way. This sub is where you produce the two images that matter for the rest of the course: the clean Windows baseline and the clean Linux baseline. Every paid module's attack-capture-analyse loop compares the compromised image against these baselines to isolate what the attack changed.
The paid modules in this course all follow the same loop: run a scripted attack from Kali against Target-Win or Target-Linux, capture memory before and after the attack, then analyse what the attack changed. The "what changed" question only has an answer if you know what the baseline looked like before the attack ran. That's what this sub produces.
A clean baseline isn't just "a capture from a VM with no malware." It's a captured, verified, smear-assessed, documented image from a VM in a known-good state — Windows updated, no unusual processes, no pending reboots, no lingering artifacts from previous exercises. The baseline is your forensic reference point. If the baseline is sloppy, every comparison against it inherits the sloppiness.
This sub walks you through producing both baselines to the standard MF1.6 established: full acquisition records, four structural checks, smear assessment, and a snapshot of the VM at the baseline state so you can revert to it before each module's attack.
Deliverable: Two documented baseline memory images (Target-Win and Target-Linux), each with a completed acquisition record, structural verification, and smear assessment. Two VM snapshots (one per target) at the clean-baseline state for revert-before-attack in MF2 onward. These four artifacts — two images and two snapshots — are the foundation every subsequent module depends on.
What makes a clean baseline state
This section defines "clean" precisely. A vague baseline produces vague comparisons.
A clean baseline state means the VM has been booted, has completed all startup tasks, has settled into an idle state, and has no artifacts from previous testing or course exercises. Specifically:
The operating system is fully updated. Windows Update has been run and no pending restarts exist. On Target-Linux, apt update && apt upgrade has completed. Pending updates add processes, services, and scheduled tasks that may or may not be present in later captures — which makes comparison noisy.
No user applications are running beyond the default session. On Target-Win, the desktop is logged in (you need a user session for the process tree to be complete) but no additional applications are open. On Target-Linux, the SSH session you used for maintenance is closed; the system is running its default service set and nothing else.
No artifacts from previous exercises remain. If you ran WinPmem earlier in the module, the WinPmem executable and output files are deleted. If you compiled LiME on Target-Linux, the build artifacts and kernel module file are deleted. The evidence directory is empty. The pagefile contains whatever the OS generated during normal operation, not remnants of your testing.
The system has been idle for at least two minutes after boot and login. Immediately after login, Windows runs a burst of scheduled tasks, Defender scans, and telemetry uploads. This burst lasts 1-2 minutes on a clean VM. Capturing during the burst produces a baseline with extra transient processes that won't appear in later captures (because the later captures happen after the burst completes). Wait for the burst to settle before capturing.
Producing the Windows baseline
This section is the operational procedure for Target-Win. By the end you have a verified .vmem file and a matching VM snapshot.
Step 1 — Prepare the clean state. Boot Target-Win. Log in. Open Task Manager and wait until CPU usage drops below 5% and disk activity stops (the post-login burst is over). Close Task Manager. Delete any files from previous exercises and verify no acquisition tools remain:
del /s /q C:\evidence\*
dir C:\winpmem*The dir command should return "File Not Found" — no WinPmem binaries left on the VM.
Step 2 — Create the VM snapshot. In VMware Workstation: VM → Snapshot → Take Snapshot. Name it "MF1-clean-baseline" with a description "Clean Windows 11 baseline state for MF course. No malware, no testing artifacts, system idle post-login. Captured [date]." This snapshot is the revert point for every subsequent module.
Step 3 — Capture memory via hypervisor suspension. Follow the MF1.4 procedure: suspend the VM, copy the .vmem file to your evidence directory as target-win-clean-baseline.vmem, hash it immediately, resume the VM.
Step 4 — Complete the acquisition record. Fill in the MF1.6 template: operator (you), tool (VMware Workstation suspend), method rationale ("hypervisor suspension selected for maximum fidelity on baseline capture — zero smear, zero guest footprint"), target (Target-Win hostname, IP, Windows build), SHA-256 hash.
Step 5 — Run structural checks and smear assessment. The four structural checks from MF1.6 (size, profile, kernel address, process count) plus the three smear checks from MF1.7 (pslist/psscan cross-validation, thread-state consistency, timestamp span). Record all results in the acquisition record. A hypervisor-captured baseline should show zero smear indicators — if it shows any, the VM wasn't fully quiesced before suspension.
Producing the Linux baseline
Same procedure, different VM. By the end you have a verified LiME image and a matching VM snapshot.
Step 1 — Prepare the clean state. Boot Target-Linux. SSH in and run sudo apt update && sudo apt upgrade -y. Wait for the upgrade to complete. Delete any LiME build artifacts and evidence directory contents:
rm -rf ~/LiME
sudo rm -rf /evidence/*Step 2 — Create the VM snapshot. Same as Windows: VM → Snapshot → Take Snapshot, named "MF1-clean-baseline-linux" with a description including the date.
Step 3 — Capture memory. Two options: hypervisor suspension (MF1.4 — preferred for zero smear) or LiME (MF1.3 — if you want to practice the LiME procedure). If using hypervisor suspension, the resulting .vmem file needs to be paired with a Volatility 3 Linux ISF for the target kernel. If using LiME, SSH back in and run the MF1.3 procedure.
Step 4 — Complete the acquisition record. Same template as Windows. Note the kernel version (uname -r output) — this is the value Volatility 3 needs to match against its symbol pack.
Step 5 — Run structural checks. Size check (file size matches RAM). Profile identification (vol -f image linux.banner). Process list sanity (vol -f image linux.pslist | wc -l — a clean Ubuntu 22.04 server runs 60-120 processes). Record all results.
This procedure produces both baselines in one session. By the end you have four artifacts: two images and two snapshots.
The situation. You're about to start MF2 (Process Injection). You took the baselines two weeks ago. Since then, you've been experimenting with Target-Win — installed a few tools, ran some test captures, browsed the web from the VM. The VM is no longer in a clean state. You have the MF1-clean-baseline snapshot available to revert to.
The choice. Start MF2 with the current (dirty) VM state and compare against the two-week-old baseline image. Or revert to the baseline snapshot first, which wipes your experimental changes but puts the VM back in the exact state the baseline image represents.
The correct call. Revert to the baseline snapshot. The entire point of the baseline is that the comparison is clean — the only difference between the baseline image and the attack-modified capture is the attack. If the VM has drifted since the baseline was captured, the comparison shows attack changes plus two weeks of experimental drift, and you can't tell which differences are which. Revert, confirm the VM matches the baseline state, then run the attack. Your experimental tools and test captures are gone, but they were temporary anyway — the baseline snapshot is the anchor.
The operational lesson. The snapshot is not a backup — it's a forensic reference point. Treat it the way you'd treat an evidence image: don't modify the VM state it represents. If you need to experiment between modules, do it after capturing the baseline snapshot, and revert before starting the next module's attack.
The myth. A baseline is just a capture of the VM before the attack runs. Boot the VM, capture immediately, done. The baseline doesn't need special preparation because it's only a reference point, not evidence itself.
The reality. A baseline captured from an unprepared VM state produces noisy comparisons that waste investigation time. A VM captured immediately after boot (before the post-login burst settles) has 20-30 transient processes that won't appear in later captures — every one of those "missing" processes shows up as a false difference in MF2's comparison. A VM with leftover artifacts from previous testing has files, registry keys, and process remnants that confuse the comparison with attack-generated artifacts.
The baseline needs the same preparation discipline as any other forensic capture: known-good state, settled system, no artifacts from other activities, documented and verified. The two minutes of preparation save hours of analysis noise in subsequent modules. Every false positive from a sloppy baseline is time subtracted from actual investigation work.
Try it — Produce both baseline images and self-validate against MF1.6 acquisition record standard
Setup. Both VMs (Target-Win and Target-Linux) in clean states. VMware Workstation (or VirtualBox) with snapshot capability. Your analysis workstation with Volatility 3 installed.
Task. Execute the full Guided Procedure: produce both baselines, snapshot both VMs, run all structural checks and smear assessment on both images, complete acquisition records for both. Then self-validate: does each acquisition record contain every field from MF1.6's template? Are the four structural checks documented? Is the smear assessment recorded?
Expected result. Two completed acquisition records with all fields populated. Two memory images that pass all structural checks. Two VM snapshots named with the date and "clean-baseline" label. Both baselines parse in Volatility 3 without errors. The documents are the reusable templates for every capture you produce for the rest of the course and in production.
If your result doesn't match. If either baseline fails a structural check, re-capture from a fully settled VM state. If the acquisition record is missing fields, re-read MF1.6's template section and fill in the gaps. If you can't produce a Linux baseline because Volatility 3 can't parse the image, the ISF generation step from MF1.3 is the fix — generate the ISF before re-attempting.
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