Reading width
Wide uses the full column for everything — text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
The Memory Forensics Workflow and Documentation Standard
The image is in front of you. Now what?
A memory image arrives. You have Volatility 3, the matching symbols, and the taxonomy from the last sub. What you do next decides whether the result holds up. Without a disciplined workflow, analysts drift between plugins, chase the first interesting hit, and produce inconsistent investigations, one engagement goes deep on processes and skips the network, the next does the reverse. That inconsistency is the failure mode counsel, auditors, and clients notice. Not a wrong finding, the absence of a repeatable method.
This sub gives you the six-phase workflow every module in the course applies: Acquire, Identify, Enumerate, Analyse, Correlate, Conclude. It is not a rigid script, it is a coverage guarantee. The phases are iterative, you return to an earlier one whenever a finding demands it, but the documentation is strictly linear, every entry timestamped as it happens. That combination, iterative analysis and linear record, is what lets you answer the one question that breaks unprepared analysts in cross-examination: "how did you know to look there?"
The phases are iterative; the record is linear. Every module references these six explicitly, and the MF9 capstone runs the full workflow against a multi-stage intrusion with no guidance. The sequence, not any single plugin, is what produces a defensible result.
Acquire, Identify, Enumerate
Phase 1, Acquire captures the image and is covered in depth in the next module. At the workflow level it produces three outputs: the image itself (a bit-for-bit capture, format set by the tool, WinPmem raw, LiME, a hypervisor .vmem), the integrity evidence (MD5 and SHA-256 computed at acquisition, verified at receipt, logged), and the acquisition record (method, tool and version, operator, timestamp, target identification, any anomalies). Phase 1 is done when the image is in hand with hashes matching the record, the method is documented, and chain of custody is signed. The three outputs are not interchangeable, and an investigation that has the image but not the integrity evidence is already compromised: without a hash computed at acquisition and verified at receipt, you cannot prove the bytes you analyzed are the bytes that were captured, and an opposing expert does not need to prove tampering occurred, only that you cannot rule it out. Its documentation is usually the longest per-investigation record, because it is what makes everything downstream admissible.
Phase 2, Identify confirms what the image actually is. An image arrives labelled "Windows 10 finance workstation NE-FIN-014"; your job is to verify that and extract the specifics analysis needs. The technical work is symbol-profile selection. Volatility 3 needs symbols matching the exact build, and profile mismatch is the most common cause of wrong memory analysis: offsets that do not match the image produce output that looks correct but reads fields from the wrong locations.
Identify exists as its own phase because labelling errors are common and they propagate silently. A hypervisor exports the wrong snapshot, an evidence transfer sends the wrong file, two captures from a cluster get swapped. None of these announces itself, the analysis simply runs against the wrong system and produces clean-looking output about a machine you were not investigating. Build 19045.5131 is Windows 10 22H2, and Volatility auto-selected matching symbols. The kernel base is plausible (kernel-space on x86-64), the processor count is sane, and the system time confirms a 15 March 2026 capture. Phase 2 complete. Had the output shown a kernel base of 0x00000000, zero processors, or a 1970 timestamp, the profile would be wrong and analysis could not proceed until it was fixed.
Phase 3, Enumerate is the exhaustive inventory, every process, thread, connection, module, and handle, not "what is interesting," which is phase 4. Completeness here is what later lets you defend phase 4's findings as "the anomalies in a fully-enumerated set" rather than "the first things I noticed." The decisive activity is reconciliation: for categories with multiple discovery methods, compare them and investigate every discrepancy. On Windows that means running windows.pslist, windows.psscan, and windows.pstree for processes, plus windows.netscan, windows.dlllist, windows.handles, windows.modules, windows.ssdt, and windows.callbacks for the other categories, each saved to the case file. On Linux the equivalents are linux.pslist and linux.pstree, linux.bash for shell history, linux.lsmod and linux.check_modules for kernel modules, linux.check_syscall for hooks, and the socket plugins for connections. Enumeration is dull and it is the phase analysts most want to shortcut, which is exactly why it is the phase that wins or loses the case: every confident phase-4 finding rests on phase 3 having looked everywhere first.
The discrepancy is itself the evidence. Two processes in psscan but not pslist are unlinked from the active list, their structures still in kernel memory. They do not get skipped, because phase 3's reconciliation, not the default plugin, is what surfaces them. Phase 3 is done when every category is enumerated with all applicable methods, reconciliation is recorded, and you have a written anomalies list for phase 4.
Analyse, Correlate, Conclude
Phase 4, Analyse investigates each anomaly from phase 3. The governing rule is raw-first: when a plugin reports an injected region, you verify it by reading the raw bytes, not by trusting the parse, for any finding decisive to the conclusion.
Four independent signals confirm it: RWX protection, private allocation, the 4d 5a MZ header read from raw memory, and no file backing. Confidence tier HIGH, and the record reads "verified against raw memory at offset X," not "plugin reported finding." Under adversarial review that distinction is the difference between a supportable claim and a dismissable one.
Phase 5, Correlate connects memory findings to independent sources, event logs, disk, firewall, other hosts, and resolves discrepancies. Process creation in EPROCESS is matched to Security event 4688; a C2 address from memory is checked against the firewall; a decoded command from memory is matched to the encoded form in PowerShell logging. The output is a unified timeline and a conflict log. Phase 5 does what phase 4 cannot: it separates findings independently supported by multiple sources from those resting on memory alone. A memory-only finding (the decoded PowerShell command exists only in RAM) is still valid, but the report should say so. Correlation also resolves apparent conflicts that are really just different clocks. A firewall may stamp an outbound connection three seconds after the kernel created the endpoint in memory, because the firewall logs after the handshake while memory records endpoint creation; that gap is not a contradiction once you understand what each source timestamps, and the conflict log records the reasoning so the three-second difference is never raised against you later as an inconsistency. Resolving these in phase 5, in writing, is cheaper than explaining them live under questioning.
Phase 6, Conclude produces the report, structured for its audience, with findings at honest confidence tiers, limitations stated plainly, and a methodology section referencing every prior phase. It includes adversarial self-review: did I enumerate completely, verify raw memory for decisive findings, correlate before concluding, state the real limitations? If any answer is uncertain, the report is not ready. The same findings get shaped differently for different readers without changing the methodology beneath them: a CISO brief leads with impact and decision, a court report leads with method and chain of custody, a peer technical deliverable leads with the evidence itself. What stays constant across all three is the methodology section, because that is the part that has to survive scrutiny no matter who is reading.
Why the sequence is the thing, not the plugins
Any analyst can run windows.malfind and report an injection. What makes that finding survive adversarial review is the phase context around it: phase 2 proves the right profile was selected, phase 3 proves every category was covered and reconciled, phase 4 proves raw verification, phase 5 proves the finding was confirmed against independent sources rather than taken at face value, and phase 6 proves the analyst scrutinized their own work first. A single command produces a finding. The sequence produces a forensic result. This is also why the workflow is worth internalizing rather than consulting: in a live incident you will not stop to read a checklist, but if the six phases are the shape your investigation naturally takes, you get the coverage guarantee for free, under pressure, when it matters most. The analysts who produce defensible work at 03:00 are not the ones with the best memory for plugins, they are the ones for whom acquire-identify-enumerate-analyse-correlate-conclude has become the default order of operations.
The documentation discipline
The standard is not a template, it is contemporaneous recording. Open the case log before phase 1. Write the phase header, then what you did, what you saw, what you decided, with a timestamp on each entry. When a phase-4 finding sends you back to phase 3, write the return, record what was missed and what you found, then return to phase 4 with a timestamp. An analyst who reconstructs documentation from memory after the fact produces a record that does not match what happened, subtle omissions, forgotten sequence, rationalized decisions, and all of those corrupt a retrospective record while none corrupt a contemporaneous one.
The bar is reproducibility: a second analyst reading only your documentation could reproduce your findings. "Ran pslist and psscan, reconciled, two anomalies" fails that test. "Ran windows.pslist (142) and windows.psscan (144), diffed by PID; the two extras are 7842 and 11334, both flagged DKOM-hidden for phase 4" passes it. The tool you record in matters less than the format: structured (one section per phase), searchable, and preserved with the image. Markdown files per phase work, a case-management system works, a personal knowledge base works; what fails is an unstructured scratchpad that you alone can navigate, because the test is whether a colleague who has never seen the case can follow your record to the same findings. Write for that colleague, not for yourself, and write it while the work is fresh, the discipline costs minutes during the investigation and saves the entire investigation if it is ever challenged. The course applies this standard from MF1 onward, and the capstone is graded partly on whether your record meets it.
The next sub goes under the workflow to the thing it operates on: physical versus virtual memory, address translation, and why a single misunderstanding there produces analysis that looks right and is wrong.