MF1.11 Module Summary

What MF1 established

MF1 turned memory acquisition from a concept into an operational procedure you've executed. You captured memory from Windows and Linux using three different methods, collected the pagefile alongside RAM, verified the images structurally, assessed smear, documented the acquisitions to legal-readiness standard, and produced the baseline images the rest of the course depends on.

The module's central lesson is that acquisition is a tradeoff decision, not a tool selection. Every method occupies a point in the fidelity-footprint-feasibility space. Hypervisor-based acquisition wins on fidelity and footprint but requires hypervisor access. WinPmem and LiME win on feasibility but introduce smear and forensic footprint. The correct method is the one whose tradeoff profile matches the case — and the decision is documented in the acquisition record because "why you chose this method" is the first question adversarial review asks.

Key concepts by sub

MF1.1 — The Acquisition Problem. Memory acquisition isn't a snapshot; it's a process that runs while the system keeps running. Smear is unavoidable in live capture. The order of volatility says memory comes first when memory matters at all. Every acquisition method trades off fidelity, footprint, and feasibility.

MF1.2 — WinPmem. The open-source Windows acquisition standard. Loads a signed kernel driver, reads physical memory page-by-page, writes a raw image. Five production failure modes: non-elevated shell, Tamper Protection, HVCI driver rejection, insufficient disk space, format mismatch. Four-step execution sequence: elevate, capture, verify size, hash.

MF1.3 — LiME and AVML. Linux acquisition has a version-coupling constraint Windows doesn't: LiME must be compiled against the exact running kernel. AVML avoids this by reading /proc/kcore from userspace. LiME for known kernels (pre-built modules); AVML for everything else. LiME's network-capture mode streams directly to the analysis workstation without writing to the target's disk.

MF1.4 — Hypervisor-Based Acquisition. The gold standard: suspend the VM from outside, copy the .vmem file, resume. Zero smear, zero guest footprint. Available when you have hypervisor access; not available for physical servers or most cloud VMs. This is the default acquisition method for the course lab.

MF1.5 — Pagefile and Swap. RAM isn't the complete memory evidence picture. Pagefile.sys contains pages the OS evicted from RAM — potentially including credential material and process data paged out hours earlier. Collected via VSS shadow copy (Windows) or direct copy (Linux swap). Volatility 3's --swap flag enables pagefile-backed page resolution during analysis. Hiberfil.sys is a compressed historical memory snapshot — valuable but represents the hibernation moment, not the current state.

MF1.6 — Acquisition Verification. The SHA-256 hash proves file integrity, not source fidelity — two consecutive captures of the same system produce different hashes. Four structural checks beyond hashing: size validation, profile identification, kernel address, process list sanity. The acquisition record template documents every capture with fields that satisfy ACPO, CPR 35, and Daubert simultaneously.

MF1.7 — Smear Detection. Three techniques: process-list cross-validation (pslist vs psscan disagreements), structure-field consistency (impossible EPROCESS field combinations), and timestamp-span analysis (measuring the acquisition's time footprint). Smear is assessed per-finding, not per-image — a heavily smeared image can still support high-confidence findings for processes whose structures are consistent.

MF1.8 — Anti-Acquisition. Four categories: anti-VM detection (malware terminates in virtual environments), memory wiping (attacker zeros pages before exiting), acquisition-tool detection (implant triggers cleanup when forensic drivers load), evidence degradation (attacker corrupts structures to confuse analysis). Hypervisor-based acquisition is architecturally resistant to kernel-level tool detection because it operates at a higher privilege level.

MF1.9 — Clean Baselines. The two baseline images (Windows and Linux) captured from clean, settled, documented VM states are the forensic reference for every paid module. Paired with VM snapshots that let you revert to the exact baseline state before each module's attack. Baseline preparation matters: capturing immediately after boot (during the post-login burst) produces noisy comparisons.

What you have now

Four artifacts ready for MF2: two verified baseline memory images (Target-Win and Target-Linux), two VM snapshots at the clean-baseline state, and the acquisition records and baseline analysis documents that make every subsequent comparison defensible. The paid modules assume these exist. If any are missing, MF1.9 and MF1.10 point you to the specific gap.

What comes next

MF2 is the first attack module. You'll run a scripted reflective DLL injection from Kali against Target-Win using Metasploit, capture memory before and after the injection, and analyse what the attack left behind in the process's virtual address space. The analysis techniques in MF2 — VAD tree walking, RWX region identification, PE signature detection — are the same techniques you'll use in production when your SOC alerts on a process exhibiting injection indicators. The baseline image from MF1 is your reference; the attack-modified image from MF2 is the investigation target. The comparison between the two is where memory forensics stops being conceptual and starts producing findings.