In this module
MF1.10 Interactive Lab — Baseline Capture and Analysis
This lab brings everything from MF1 together in one exercise. You'll capture memory from both Target-Win and Target-Linux using the methods covered in MF1.2-1.4, run foundational Volatility 3 analysis commands against both captures, and document the results as the reference state the paid modules compare against.
If you completed MF1.9's baseline procedure, you already have both images and both acquisition records. This lab adds the analysis layer: running core Volatility 3 commands against each baseline to produce a reference document that says "this is what the clean system looks like in Volatility output." When MF2 shows you the compromised system, you'll compare against this document to isolate the attack's footprint.
Deliverable: A baseline analysis document for each target VM containing the output of core Volatility 3 commands: windows.info / linux.banner, pslist, netscan / linux.sockstat, dlllist (Windows), linux.lsmod (Linux). These outputs are your "known-good" reference for every subsequent module.
Lab exercise — Windows baseline analysis
Run these commands against your Target-Win clean baseline image. Record the output in a document alongside your MF1.6 acquisition record.
Command 1 — System identification. vol -f target-win-clean-baseline.vmem windows.info. Confirm the Kernel Base, KernelFileVersion, SystemTime, and KeNumberProcessors match expectations. This is the reference for every subsequent windows.info run — you'll compare future captures against these specific values.
Command 2 — Process listing. vol -f target-win-clean-baseline.vmem windows.pslist. Record the full output. Count the total processes. Identify the core Windows process tree: System → smss → csrss, wininit → services → svchost instances, winlogon → dwm, explorer. The process tree on a clean Windows 11 system follows a predictable pattern — deviations from this pattern in MF2+ captures are the first indicator of compromise.
Command 3 — Network connections. vol -f target-win-clean-baseline.vmem windows.netscan. On a clean VM with no user activity, expect: system-level connections (svchost listening on standard ports), possibly Defender telemetry connections, and the host-only network adapter's DHCP/ARP traffic. Record every connection. In MF2+, any connection not in this baseline list is either new legitimate traffic or attacker C2 — the baseline tells you which is which.
Command 4 — Loaded DLLs. vol -f target-win-clean-baseline.vmem windows.dlllist --pid . Pick Explorer's PID from the pslist output and dump its loaded DLLs. The DLL list for Explorer on a clean system is your reference for detecting DLL injection (MF2) — an injected DLL appears in the compromised capture's dlllist but not in this baseline.
Lab exercise — Linux baseline analysis
Run these commands against your Target-Linux clean baseline image.
Command 1 — System identification. vol -f target-linux-clean-baseline.lime linux.banner. Confirm the kernel version matches uname -r from Target-Linux. This is the reference for every subsequent Linux analysis.
Command 2 — Process listing. vol -f target-linux-clean-baseline.lime linux.pslist. Record the full output. Identify the init system (systemd, PID 1) and the service tree. A clean Ubuntu 22.04 server runs SSH, systemd-journald, systemd-logind, and a handful of system services. The process count is typically 60-120.
Command 3 — Network connections. vol -f target-linux-clean-baseline.lime linux.sockstat. On a clean server, expect: sshd listening on port 22, systemd-resolved on port 53 (local DNS), and possibly DHCP client traffic. Record every listening socket and established connection.
Command 4 — Loaded kernel modules. vol -f target-linux-clean-baseline.lime linux.lsmod. Record the full module list. In MF7 (Linux Attack), an LKM rootkit appears as a new module in the compromised capture that doesn't exist in this baseline.
Self-validation before MF2
Before moving to MF2, confirm you have all of the following. Each item has a section reference if you need to go back.
You should have four files on your analysis workstation: target-win-clean-baseline.vmem (or .raw), target-linux-clean-baseline.lime (or .vmem), and their SHA-256 hashes recorded in your acquisition records.
You should have two VM snapshots: MF1-clean-baseline (Target-Win) and MF1-clean-baseline-linux (Target-Linux), both named and dated.
You should have two completed acquisition records (MF1.6 template) with all structural checks (MF1.6) and smear assessments (MF1.7) documented.
You should have the baseline analysis document from this lab with the output of core Volatility 3 commands against both images.
If any of these are missing, the specific sub that covers the gap is referenced above. Complete the gap before starting MF2 — the paid modules assume all four artifacts exist and are documented.
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