Chapter 22 — Exercises

Thirty problems in seven groups (A–G), mixing concept checks, hands-on labs (acquire and analyze a memory image, diff the process views, hunt injected code, recover the narrative, write the report, verify a hash), and judgment questions. Hands-on labs assume a practice memory image and a working Volatility 3 (and, where noted, Volatility 2) install from Appendix J — Practice Images and Lab Setup; the plugin and tool syntax is in Appendix C — Tool Reference. (answer in Appendix) = worked solution in Answers to Selected. ⭐ = stretch. One rule overrides every problem here: a memory image is the only evidence in this book you cannot re-acquire — analyze a copy, never the lone capture, and hash before you touch it.

Group A — Why memory, and the order of volatility

22.1 Build the "memory holds, disk doesn't" table from memory. List at least eight artifact types that live in RAM, and for each state whether (and in what form) the same thing exists on disk: full-disk-encryption keys, the running-process list, live network connections, injected/fileless code, decrypted file content, console command history, the clipboard, and cached credentials. For the three where the on-disk version is useless or absent, explain in one sentence each why that makes the live capture decisive. (answer in Appendix)

22.2 Place physical memory (RAM) correctly in the order of volatility (RFC 3227), naming at least one layer that is more volatile and two that are less. Then state, in a single sentence you could say on the stand, the irreversible operational rule that this ordering implies for a live, lawfully-accessible machine — and explain precisely why it is irreversible in a way that disk imaging is not.

22.3 ⭐ A colleague proposes a field procedure that relies on cold-boot remanence: chill the DRAM modules, reboot into a tiny imaging stub, and recover keys from the bytes that have not yet decayed. (a) Explain the physical phenomenon that makes this possible at all and ties it to the book's first theme. (b) Give two concrete reasons a professional should not plan a standard acquisition around it. (c) State the posture you adopt instead toward power-off.

22.4 Memory does not only live in RAM. Name the four on-disk sources of memory contents you can analyze after the live moment has passed — the Windows hibernation file, the page/swap file, a crash dump, and a virtual machine's memory file — and for each give its typical name/location and one limitation versus a clean live capture. Which of the four is the closest to an atomic snapshot, and why? (answer in Appendix)

Group B — Acquisition

22.5 Explain the acquisition paradox unique to memory: the act of capturing changes the thing being captured. (a) Name the two unavoidable consequences (the tool's own footprint, and non-atomicity / "page smear") and describe what page smear can break during analysis. (b) Explain why this means a memory image's integrity hash proves something narrower than a disk image's hash — state exactly what the SHA-256 does and does not prove. (c) Tie the whole answer to the book's second theme (the original is sacred) and explain the twist that makes memory the one un-re-acquirable evidence in this book. (answer in Appendix)

22.6 For each platform, name a defensible acquisition tool and one property that recommends it: Windows GUI, Windows CLI/scriptable, Linux without a compilable kernel module, and a virtual machine. Then state the two non-negotiable handling rules that apply to every memory capture regardless of tool (where you write it, and what you do the instant it finishes).

22.7 Lab — capture and prove it. On a spare VM or lab host you are authorized to image, capture RAM to external media with a documented tool (WinPmem or FTK Imager on Windows; AVML or LiME on Linux), including the pagefile/swap where applicable. Then: (a) compute the SHA-256 of the image and record it; (b) write a single chain-of-custody log line containing the tool name and version, start and completion times, output filename, byte size, and the hash (template in Appendix F); (c) capture the image a second time and compare the two hashes. Explain in two sentences why the hashes differ even though "nothing happened" between captures, and why that is expected rather than alarming.

22.8 ⭐ Your case Linux box is a live web server. (a) Contrast LiME (a loadable kernel module) with AVML (a userland static binary) and explain the single field condition that makes AVML the safer choice. (b) Explain why, at acquisition time, you must also record the exact kernel version (uname -a) and try to preserve the kernel's debug symbols / System.map — what later step fails completely without them? (c) Why is the analogous step usually automatic on Windows but not on Linux? (answer in Appendix)

22.9 A target system is a virtual machine on an ESXi host you control. Explain why you may not need an in-guest acquisition tool at all: name the file(s) you would copy, describe how pausing or snapshotting the guest gets you closer to an atomic image than any agent running inside it, and finish the sentence: "When the machine is virtual, the hypervisor is your ____."

Group C — The memory model you must hold

22.10 Explain virtual-to-physical address translation at the level you would need to defend an analysis. (a) What is a page, and what is the default size on x86-64? (b) What is the Directory Table Base (DTB), which CPU register holds it, and why is finding a process's DTB the analysis tool's first job? (c) Explain precisely why a missing pagefile can cause a tool to silently fail to read part of a process's memory. (d) Calculate: with 4 KiB (4,096-byte) pages, a virtual address of 0x0001D2A4F falls in which page? Give the page-aligned base address and the offset within the page, in hex, and show the masking you used (the low 12 bits are the in-page offset). (answer in Appendix)

22.11 Windows threads every running process into a doubly-linked list. (a) Name the kernel structure that represents a process and three fields it carries that an examiner reads constantly (the image name, the PID, and the parent PID). (b) Name the list field that links processes together and the kernel global that anchors the head of the list. (c) Explain in one sentence why walking this list is fast and accurate for honest processes but is exactly the mechanism a rootkit subverts.

22.12 Convert the four-character pool tags to their hexadecimal byte signatures and state what each marks: Proc, Thre, File, and TcpE. (Use the ASCII table in Appendix H; for example, P=0x50, r=0x72.) Then explain the difference between enumerating (walking the official list) and scanning (sweeping memory for a pool tag), and why a tool can find a structure by scan that the list omits. (answer in Appendix)

22.13 ⭐ Describe, step by step, how a DKOM (Direct Kernel Object Manipulation) rootkit hides a running process from a list walk, and why the very same process still surfaces under a pool-tag scan. Draw the before/after of the FLINK/BLINK pointers in ASCII. Then state the one-sentence principle this proves — connect it explicitly to the book's third theme (the absence of a trace is itself a trace).

Group D — Enumerating processes and live network state

22.14 Lab — diff the three process views. On a practice image, run the process-listing, pool-scanning, and process-tree plugins (windows.pslist, windows.psscan, windows.pstree). (a) Diff the scan against the list and report any PID present in the scan but absent from the list, plus any process whose only record is an exit time. (b) For one suspicious process, report its parent and explain why its ancestry is or is not consistent with the Windows process model (for example, a service host whose parent is not services.exe). (c) Save all three outputs and hash them, and explain in one sentence why you hash your own analysis output. (answer in Appendix)

22.15 Lab — attribute the connection. Run the network plugin (windows.netscan). (a) List every ESTABLISHED connection with its owning PID and process name. (b) Identify the connection most likely to be command-and-control and give two reasons (the foreign address, the owning process, the port, the state). (c) Explain the one thing memory tells you here that a raw packet capture from Chapter 23 — Network Forensics cannot tell you on its own.

22.16 A cmdline listing shows three processes: svchost.exe launched as C:\Windows\System32\svchost.exe -k netsvcs -p; a second svchost.exe launched as C:\Users\Public\svchost.exe with no arguments; and powershell.exe -nop -w hidden -enc SQBFAFgA.... (a) Identify the two anomalies in the second svchost and explain why each is a red flag specific to that process name. (b) Decode what -nop -w hidden -enc means and what the -enc argument carries (you need not decode the Base64 — state the encoding and why an attacker uses it). (c) Which single artifact family proves these command lines were reconstructed from memory rather than read off the disk?

22.17 You are handed only this pslist excerpt and asked for a thirty-second read:

PID    PPID  ImageFileName    CreateTime
712    512   services.exe     2024-05-14 12:31:06
1120   712   svchost.exe      2024-05-14 12:31:07
3120   3088  explorer.exe     2024-05-14 12:33:40
4488   3120  svchost.exe      2024-05-14 13:52:09
5012   3120  powershell.exe   2024-05-14 13:55:44

Name the single most suspicious row and give the two independent reasons it is suspicious (one about lineage, one about timing). Then name the next two plugins you would run to confirm or dismiss your suspicion, and say what each would show if you are right. (c) The powershell.exe at PID 5012 is parented to explorer.exe — which is ordinary for an interactive admin. Explain what additional fact about it (visible in cmdline) would move it from "ordinary" to "suspicious," and why context — its timing relative to the rogue svchost — matters to that judgment.

Group E — Detecting code that lives only in memory

22.18 Explain why a memory region that is private, committed, and marked PAGE_EXECUTE_READWRITE (RWX) is the classic signature the injected-code plugin (malfind) hunts for. (a) Contrast it with how legitimate code is normally mapped and protected. (b) Explain why a region that also begins with the bytes 4D 5A is a stronger finding, and what 4D 5A is. (c) State plainly why malfind output is a lead generator, not a conviction — name one legitimate source of RWX-private regions — and list two corroborating artifacts you would add before writing "injection." (answer in Appendix)

22.19 Reflective DLL injection loads a module without the Windows loader recording it. (a) Name the three PEB module lists that a normally-loaded DLL appears in. (b) Explain what the ldrmodules flags False / False / False with no MappedPath mean, and why that combination is the canonical reflective-injection signature. (c) Tie this to the third theme: what is the "trace" here, given that the attacker's whole goal was to leave none?

22.20 Process hollowing is the technique behind a svchost.exe that is really something else. List the five independent signals across this chapter's plugins that, together, make hollowing airtight: the injected-code finding, the VAD anomaly for the main image, the command-line/path tell, the parentage tell, and the on-disk comparison. Then explain in two sentences why no single one of the five is sufficient on its own and why the correlation is what survives cross-examination.

22.21 ⭐ Lab — the kernel diff. On a practice image with a rootkit, run the kernel-module list plugin and the kernel pool-scan plugin (windows.modules and windows.modscan) and compare their counts. (a) Report the difference and identify the extra entry that appears only in the scan. (b) Explain why this modules-vs-modscan diff is the kernel analog of the pslist-vs-psscan diff. (c) Name one other kernel-subversion check covered in the chapter (syscall-table or callback inspection) and state what kind of hook it would reveal. Frame your whole answer as detection, consistent with this book's constraint.

22.22 Lab — extract and verify. Dump the executable image of a suspected hollowed process (windows.pslist --pid <PID> --dump). (a) Compute the SHA-256 of the dumped image. (b) Compute the SHA-256 of the legitimate on-disk binary of the same name from a known-good C:\Windows\System32 (or a reference hash). (c) State exactly what it means if the two hashes differ, and exactly what a match would have meant instead. (d) Why is "the in-memory image differs from the on-disk binary of the same name" such persuasive evidence of hollowing? (e) Write the one-sentence chain-of-custody note you would add to your worksheet recording the dump itself — tool, source PID, output filename, and SHA-256 — and explain why your dumped artifact, not just the original image, is now evidence that must be hashed and tracked. (answer in Appendix)

Group F — Registry, credentials, command history, and extraction

22.23 Memory analysis is partly registry analysis. (a) Name the plugin that lists hives mapped in RAM and the one that prints a specific key, and give one thing memory-resident registry analysis can reach that a dead-disk hive cannot. (b) A printkey of ...\CurrentVersion\Run shows value Updater → C:\Users\Public\svchost.exe with a last-write time minutes after the suspicious process started. Explain what this proves and how it corroborates the disk-side autostart analysis of Chapter 16 — Windows Forensics. (c) The credential-dumping plugin (hashdump) is powerful — state the one thing that decides whether you may run it, and which chapter owns that decision. (answer in Appendix)

22.24 Command history is one of memory's most evocative artifacts. (a) Distinguish cmdscan (input history) from consoles (screen buffer). (b) Given this cmdscan output, narrate the intrusion in one sentence and identify which command is the "absence-of-a-trace becomes a trace" moment:

Cmd #0: whoami
Cmd #1: net user svc_help P@ss!2024 /add
Cmd #2: net localgroup administrators svc_help /add
Cmd #3: reg add ...\Run /v Updater /d C:\Users\Public\svchost.exe /f
Cmd #4: del C:\Users\Public\dropper.exe

(c) Explain why the deletion in Cmd #4 does not clean up the way the attacker hoped — name two things that survive the del. (d) consoles would add something cmdscan cannot. State what extra evidence the screen buffer provides over the input history, and give one concrete example from the sequence above where seeing the system's printed response (for instance, "The command completed successfully") strengthens the finding.

22.25 Lab — the encryption-key save (Recovery vs. Forensics). You have a memory image captured from a live host whose BitLocker (or VeraCrypt) volume was mounted at capture. (a) Run a key-scanning tool (bulk_extractor or aeskeyfind) over the raw image and describe what an AES key-schedule hit represents. (b) Explain, in the book's dual-lens terms, how the identical recovered key serves the 🔍 forensic examiner (proving access / making the disk image readable) and the 💾 recovery technician (giving a client back an otherwise-unreadable volume). (c) State the legal line: recovering the key is a technical act, but using it to decrypt is governed by — what, and decided where? Tie this to Chapter 29 — Encrypted Device Forensics.

22.26 ⭐ Write the report. Draft a 120–150 word Findings paragraph for a memory-forensics conclusion that a competent cross-examiner could not impeach: report that a svchost.exe (PID 4488) running from C:\Users\Public was a hollowed process beaconing to an external host, citing the specific plugins behind each claim (parentage, command line, malfind RWX-MZ region, netscan connection, on-disk hash mismatch). State at least two limitations explicitly (non-atomic smear; malfind candidate-vs-conviction; authority bounds on any key/credential use). Keep finding strictly separate from inference. Then list the one sentence an opposing expert would attack first and tighten it.

Group G — Judgment, limits, and the progressive project

22.27 A junior analyst reports: "malfind found a PAGE_EXECUTE_READWRITE private region in dotnet.exe, so the host is compromised." The region does not begin with MZ, the process has no suspicious network connection, normal parentage, and is a known .NET/JIT application. (a) Identify the error in the analyst's reasoning. (b) Explain why a JIT compiler legitimately produces RWX-private regions. (c) Rewrite the finding so it is defensible, and say what additional evidence would be required before the word "compromised" is warranted. (answer in Appendix)

22.28 State the four hard limitations of memory forensics from the chapter and, for each, the one-sentence honest disclosure you would put in a report: non-atomic smear; un-re-acquirability; no symbols / no analysis; and paged-out / freed / overwritten data. Then write the exact wording of a valid, professional finding for the situation where the captured memory simply does not support a conclusion — connecting it to the book's fifth theme (know your limitations).

22.29 Investigators executing a warrant find a laptop powered on and logged in, screen unlocked, system drive BitLocker-encrypted, with no recovery key escrowed (anchor case #4's decisive moment, handled at the level of procedure only). (a) What is the single most consequential decision in the first ninety seconds, and what happens to the case if the team follows the old "photograph, pull the plug, image later" reflex? (b) Name the two evidence facts the memory establishes that no later disk analysis can reconstruct. (c) State the Fifth-Amendment distinction that makes a key seized from RAM different from a compelled passphrase, and name the chapter that owns that doctrine.

22.30 Progressive project — the volatile-evidence layer. Add this chapter's evidence to your Forensic Case File (begun in Chapter 5, acquired in Chapters 14–15). (1) Capture or source memory: if your case system was live and authorized, acquire RAM to external media including the pagefile, hash it immediately, and log the capture on your custody form (Appendix F); if it was already off, extract hiberfil.sys/pagefile.sys (or a VM .vmem) from your verified disk image and document why no live capture exists. (2) Identify and enumerate: run windows.info, then pslist, psscan, pstree, and diff scan against list. (3) Hunt in-memory code and live state: run cmdline, netscan, malfind, and ldrmodules; for every suspect process record parentage, path/command line, owned connections, any RWX-private region (with first bytes), and any False/False/False module. (4) Recover the narrative and artifacts: run cmdscan/consoles, printkey on the Run key, and hivelist/hashdump as authority permits; dump at least one suspect executable, hash it, and compare to the legitimate on-disk binary. (5) Feed the timeline and state limits: emit a timeliner bodyfile for merger into your master timeline in Chapter 21 — Timeline Analysis, and write the limitation beside every memory finding. Save all Volatility outputs and dumped artifacts into the case-file folder and hash them; list the files and hashes in your submission. Remember: volatile evidence that lives only in your head cannot be assembled at the capstone, because it cannot be recaptured at all.

Self-check. You have mastered this chapter when you can take a raw memory image and, in a disciplined sequence, answer four questions with cited plugin output — what was running (list and scan), what it was talking to, what code touched no disk, and what the attacker typed — and when you instinctively diff pslist against psscan, read malfind as a lead rather than a verdict, corroborate hollowing across five independent signals, and state every finding's limit out loud. If you can defend a key recovered from RAM both as a forensic fact and as a recovery win, and explain in one breath why pulling the plug first is the one irreversible mistake, you are ready for Chapter 23 — Network Forensics, where the C2 connection you found in memory is followed out onto the wire.