Ten scenario-based questions covering the full scope of MF0. Each presents an operational situation and tests your judgment, not your recall. The scenarios reflect decisions you'll face in real investigations — when to acquire, how to classify evidence, which tool to use, what confidence tier to assign, and how to frame findings for legal review. Incorrect options are plausible and common. The feedback explains why each wrong answer is wrong, so the learning continues from the options you rule out as well as the one you select.
Deliverable: Confirmation that the MF0 material has become operational judgment, not just knowledge. Questions you answer correctly confirm the concept has transferred. Questions you answer incorrectly identify the specific material to revisit before MF1.
Estimated completion: 30 minutes
Questions
Question 1. At 03:14 on a Thursday, Defender for Endpoint fires on an NE finance workstation for anomalous PowerShell with outbound connections to an unfamiliar IP. Live-response disk investigation finds no suspicious files, no registry persistence, no unusual scheduled tasks. The endpoint team wants the machine reimaged within the hour — the finance controller has a 9am board-pack deadline. You're the on-shift SOC analyst. What do you do?
Authorise the reimage. The disk is clean, the attachment has been identified and contained, the user has a business deadline. No further investigation is required; the incident is contained.
Pause remediation, acquire memory before the workstation is rebooted, then allow reimage. This fact pattern matches the canonical "EDR fires without corresponding disk evidence" trigger from MF0.1; the only evidence that can answer what the PowerShell actually did is the memory. The 20–30 minute acquisition delay is defensible against the business deadline because the alternative destroys the evidence and leaves the investigation unable to determine whether credentials were harvested, whether lateral movement occurred, or whether other systems are affected. Communicate the delay to stakeholders; don't negotiate the acquisition decision.
Reimage immediately, then acquire memory from a clean replacement workstation to establish a baseline. The replacement image will show what a non-compromised system looks like, which is valuable reference data for future investigations.
Escalate to the CISO for a decision on whether to acquire memory. Memory acquisition is a major operational decision that should not be made by a SOC analyst without executive sign-off, and the 03:14 timing means waking the CISO is appropriate.
Question 2. You're analysing a memory image and find three pieces of evidence in PID 4872 (powershell.exe, parented by WINWORD.EXE): (1) an active-list process entry confirming the process is running; (2) a cached NTLM hash for a privileged account in LSASS memory; (3) an RWX memory region in the process address space containing a PE header but not appearing in the process's module list. A colleague asks you to classify each per the MF0.2 taxonomy for the report's claim language. What is the correct classification for each?
(1) volatile structure — the active-list entry is kernel bookkeeping that persists independently of the process's own memory. (2) ephemeral data — the cached NTLM hash is LSASS's working state for authenticated sessions. (3) transient artefact — the RWX region without module-list backing is attack-introduced, pattern-discovered, anti-forensic target. Each classification determines the claim language appropriate to the finding, per the MF0.2 guidance that findings from different categories support different claim strengths.
All three are volatile structures because they all came from memory analysis performed against kernel-maintained structures (the EPROCESS linked list, LSASS's process memory, and the VAD tree). Memory findings in general are volatile-category evidence.
(1) volatile structure; (2) ephemeral data; (3) volatile structure. The RWX region was discovered by examining the VAD tree, which is a kernel bookkeeping structure, so the finding itself is volatile-structure category.
(1) ephemeral data; (2) transient artefact; (3) volatile structure. The running process is the application's working state (ephemeral), the cached hash is attacker-introduced (transient), and the RWX region is part of the kernel's memory-management bookkeeping (volatile).
Question 3. You've completed phase 3 enumeration on the NE-FIN-014 image. The pslist plugin returned 142 processes; psscan returned 144. The two additional processes in psscan are PIDs 7842 and 11334. Your case log notes them as "reconciliation candidates, flagged for phase 4." What should phase 4 actually investigate, and what does the reconciliation discrepancy most likely indicate?
The discrepancy indicates tool error — Volatility 3's psscan is over-reporting. Phase 4 should ignore PIDs 7842 and 11334 and focus on the 142 processes both plugins agree on.
The discrepancy is significant and PIDs 7842 and 11334 are phase 4 priorities. Two additional processes in psscan that don't appear in pslist are candidates for DKOM-hidden processes (attacker unlinked them from the active list but pool-scanning still finds their EPROCESS structures). Phase 4 should extract these processes' details (cmdline, handles, VAD layout), compare against the thread-scan results (windows.thrdscan) for independent corroboration, and assess whether the reconciliation discrepancy reflects DKOM or a more benign cause (terminated processes caught by psscan's more-permissive scan). Either way, the finding carries forward to phase 4 documented, not dismissed.
The discrepancy is normal — psscan typically returns slightly more results than pslist because it also captures recently-terminated processes that pslist excludes. Phase 4 can proceed on the 142-process pslist and note the psscan excess in the report as tool-specific noise.
The discrepancy requires re-capturing the memory image; the two results should be identical on a consistent image, and disagreement implies the image was captured during a state change that produced inconsistent views. Phase 4 is blocked until a fresh image is acquired.
Question 4. A finding in your investigation report cites virtual address 0x00007ff8a2100000 in PID 4872 as containing a reflectively-loaded PE. Your peer reviewer wants to verify the finding independently by examining the raw bytes. They ask you: "what physical offset in the image file contains those bytes?" What is the correct response?
The physical offset is 0x00007ff8a2100000 — it's the same value; virtual and physical addresses are the same when the process is in its natural address space. The reviewer can seek to that offset in the image file directly.
The physical offset has to be computed by walking PID 4872's page tables. The virtual address 0x00007ff8a2100000 is per-process — another process has different data at the same virtual address, and the byte stream of the image has no inherent awareness of process. Run vol -f NE-FIN-014-mem.raw windows.vadinfo --pid 4872 --address 0x7ff8a2100000 --dump to let Volatility walk the page tables and extract the bytes; the dump file contains the verified bytes. If the reviewer wants the physical offset directly (for use outside Volatility), windows.pagetable --pid 4872 lists the translations. The rule: virtual addresses require translation through the owning process's page tables before raw reads.
The physical offset cannot be determined without acquiring a new memory image with the --pagefile option enabled. Without pagefile integration, virtual-to-physical translation is incomplete.
The reviewer should use a hex editor to search the raw image file for the MZ header bytes (4D 5A) — any match is the reflectively-loaded PE. Page-table translation is tool-specific overhead; direct byte search is faster and more reliable.
Question 5. Your team lead asks: "for the NE-FIN-014 investigation finding about the injected PE in PID 4872, do we need WinDbg validation on top of Volatility 3, or is the Volatility output enough?" The report is going to NE's external legal counsel because the affected employee is contesting their dismissal at an employment tribunal. What do you tell the team lead?
Volatility output is enough. Volatility 3 is well-tested, widely used in DFIR, and its output is accepted by courts. Adding WinDbg validation would be redundant and add analysis time without improving the report's defensibility.
WinDbg validation is required. The report heads for adversarial review at the tribunal. Volatility-only findings give opposing counsel the opening to argue "the conclusion rests on a third-party plugin's output; the investigator did not independently verify the underlying kernel structures." WinDbg validation — walking the EPROCESS structure at its kernel address, confirming the fields, checking the VAD tree's entry for the injected region — closes that opening. The five-minute cost (per MF0.6's worked example) is the insurance premium for adversarial review; the timing is phase 4 analysis, not phase 6 conclusion, so the validation is complete before the report is written.
Use MemProcFS to validate instead. MemProcFS mounts the image as a filesystem and provides independent parsing of the same data; if MemProcFS and Volatility agree on the finding, the parallel tool confirmation is equivalent to WinDbg validation and faster to perform.
The decision depends on the tribunal's specific evidentiary requirements. Check with legal counsel first; if they indicate Volatility output will be accepted, no additional validation is needed.
Question 6. You have a finding with multiple favouring modifiers: pslist and psscan and pstree all agree on the process, Security event 4688 corroborates the creation timestamp, no plausible alternative explanations exist. You did not perform raw-memory verification of the EPROCESS structure. Per the MF0.7 framework, what is the correct confidence tier?
High confidence. Three-way discovery agreement plus cross-source corroboration plus no alternatives is overwhelming evidence. Raw-memory verification would add nothing that isn't already established.
Medium confidence. The MF0.7 framework's step 2 is explicit: absent raw-memory verification, the finding caps at medium regardless of how many favouring modifiers accumulate. The reason isn't that the finding is likely wrong — with three-way discovery and event-log corroboration, it's almost certainly correct. The reason is defensibility: without raw-memory verification, the methodology record leaves an opening for the opposing expert to argue the investigator relied on tool output without independent structural verification. Raising to high requires five minutes in WinDbg (MF0.6's worked example); if the finding is going in a report, spend the five minutes. If the finding stays in internal notes, medium is defensible as-is.
High confidence, with a footnote noting that raw-memory verification was not performed. The footnote disclosure addresses the methodology gap, allowing the finding to retain high-confidence language in the main report.
Low confidence. Memory forensics findings without raw-memory verification cannot be considered reliable, regardless of plugin output or cross-source corroboration.
Question 7. Six months after an incident closes, the employee whose credentials were harvested brings an employment tribunal claim against NE. Their solicitor requests disclosure of "all memory forensics evidence." The case folder contains the original acquisition image (in write-protected storage), three drafts of the report, analyst working notes with early hypotheses that were later revised, Volatility 3 output files, and the final report. What should you produce to the solicitor?
Produce everything — full disclosure is the safest legal posture, and withholding any material risks adverse inferences. Redact nothing.
Produce only the final report — the report is the evidence, and working materials (drafts, notes) are pre-decisional and not appropriate for external disclosure.
Consult NE's legal team and any instructed expert before producing anything. The scope of disclosure under CPR 31 is a legal judgment, not a technical one, and the expert's duty of preservation applies from the moment legal process is foreseeable. Preserve everything untouched while the scope is determined under legal guidance, then produce per the agreed scope. Producing everything unilaterally exposes internal working material that can be exploited by opposing counsel (early hypotheses that were wrong become cross-examination material); producing only the report unilaterally risks an incomplete-disclosure challenge. Neither is the technical practitioner's decision to make.
Produce the final report plus the Volatility 3 output files, but withhold the drafts and working notes. Finished work products are evidence; working materials carry implicit privilege.
Question 8. You're setting up the memory forensics analysis workstation. Your organisation's security policy requires all forensic analysis be performed on an air-gapped system. When you try to run Volatility 3 against your first Windows memory image, the tool hangs on "downloading symbols..." and eventually times out. What is the correct fix?
Pre-stage the symbol cache. Run Volatility 3 against the same Windows build (or any memory image from that build) on a connected workstation first — this triggers symbol download and populates the local cache. Then copy the cache folder (typically ~/.cache/volatility3/ on Linux or %LOCALAPPDATA%\volatility3\ on Windows) to the air-gapped workstation. Volatility 3 will find and use the cached symbols without attempting the download. Alternative: run an internal symbol server on the air-gapped network that mirrors Microsoft's symbol server for the Windows builds your organisation encounters. Either approach resolves the air-gap limitation without compromising the air-gap itself.
Configure Volatility 3 to use the --offline flag, which bypasses symbol resolution entirely and uses a built-in generic symbol table instead. This works for standard Windows analyses and avoids the air-gap problem.
Abandon the air-gap requirement. Modern forensic workstations require internet access for symbol resolution, and the policy is incompatible with current tool behaviour. Escalate to security leadership to update the policy.
Install Volatility 2 instead of Volatility 3 — V2 uses local profile packs rather than remote symbol servers and is air-gap-friendly by default.
Question 9. A colleague on your IR team writes up the NE-FIN-014 finding as: "the malicious PowerShell process (PID 4872) was running and downloaded additional payloads from attacker infrastructure." The evidence: three-way discovery agreement plus event-log corroboration for the running process; a YARA rule match plus a URL string found in the process memory for the download attribution. What is the correct critique of this sentence?
The sentence mixes confidence tiers without signalling which claim is which. "Was running" is high-confidence (multi-method discovery plus event-log corroboration). "Downloaded additional payloads" is medium-confidence (YARA match plus string reference, but no direct capture of download activity). As written, the sentence reads as a uniformly-asserted claim, which overclaims the second clause. Correct form: two sentences with tier-matched language. "PID 4872 (powershell.exe) was running at the time of acquisition. The evidence is consistent with the process having downloaded additional payloads from attacker infrastructure, based on YARA rule match and URL references in process memory." Per MF0.8's expert reporting conventions, sentences mixing tiers must signal which claim is which.
The sentence is fine. Both clauses are supported by evidence, and a single sentence communicates the finding efficiently. Separating claims into multiple sentences adds length without adding clarity.
The sentence uses "malicious" as an attributive claim that requires evidence of malicious intent. Without that evidence, the adjective should be removed: "the PowerShell process (PID 4872)..." The rest of the sentence is appropriately asserted.
The sentence should be rewritten in passive voice to comply with expert reporting conventions: "the malicious PowerShell process (PID 4872) was observed to be running, and additional payloads were observed to have been downloaded." Active voice is too direct for legal reporting.
Question 10. You've built your three-VM lab per MF0.9 and run the MF0.10 verification. The capture succeeded, the transfer worked, but Volatility 3's windows.info output shows KernelFileVersion: 10.0.19045.5131 (Windows 10 22H2) on what you thought was a Target-Win running Windows 11. Three possible explanations come to mind. Which response is correct?
Ignore the version discrepancy — Volatility 3's output sometimes misreports the kernel version string when symbols don't match exactly. As long as the other fields look healthy (Kernel Base, KeNumberProcessors, SystemTime), the image is valid and you can proceed to MF1.
Stop and reconcile the discrepancy before proceeding. KernelFileVersion is read directly from kernel memory, not from a symbol table — if Volatility 3 reports Windows 10, the VM you captured is running Windows 10, not Windows 11. Most likely causes: you captured from a wrong VM (check the hypervisor's VM list — the VM you thought was Target-Win may be a leftover from earlier experimentation), or the Windows 11 ISO you downloaded was mislabelled. Either way, the course's worked examples assume a Windows 11 Target-Win; a Windows 10 VM produces different memory layouts, different Defender behaviours, and different Volatility 3 symbol requirements. Rebuild Target-Win per MF0.9 against a confirmed Windows 11 Enterprise Evaluation ISO before starting MF1.
Accept the Windows 10 version and proceed with MF1 — the course's attack-capture-analyse loop works on either Windows 10 or Windows 11. The differences between the two versions don't affect memory forensics methodology, and rebuilding is wasted time.
Upgrade the VM in place from Windows 10 to Windows 11 using Windows Update, then re-capture. In-place upgrades preserve the VM's existing configuration while meeting the course's OS requirement without a full rebuild.
After completing these questions
If you answered all ten correctly on the first attempt, the MF0 material has transferred as operational judgment. You're ready for MF1.
If you missed any, the specific subsection to revisit:
Close the gap before moving to MF1 — the methodology is cumulative and each module assumes the one before is internalised. When the review is complete and you can answer each question from recall (not by re-reading), the MF0 foundation is ready for the depth MF1 begins to add.
💬
How was this module?
Your feedback helps us improve the course. One click is enough — comments are optional.
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
