Chapter 32 — Exercises
A mix of concept checks, hands-on labs ("triage this sample," "interpret this output," "write the YARA rule," "build the timeline," "calculate and verify the hash"), and judgment calls — because malware forensics is a deliverable-driven discipline where the hardest decisions (how deep to go, what to upload, when to stop) have no answer key in the room. (answer in Appendix) = worked solution in Answers. ⭐ = stretch. Do every lab in an isolated VM only, on a working copy of a sample whose hash you have verified against its evidentiary original, with shared folders, clipboard, and drag-and-drop off — practice the safety discipline from the first keystroke, exactly as you would on a live weapon.
Group A — The safe lab and handling a live weapon
The lab and the rules come before a single byte of analysis, because the sample on your bench is a working weapon that will go off if you let it.
32.1 State the first principle of handling live malware in your own words, then list five of the ten rules for handling live samples from the chapter. For three of the five, name a concrete way the malware would exploit a violation of that rule (e.g., what a shared folder actually gives a piece of ransomware). (answer in Appendix)
32.2 The chapter calls the snapshot the single most important habit in the lab diagram. (a) Describe the snapshot-and-revert cycle around one detonation, step by step. (b) Explain why "I'll just clean the VM afterward and reuse it" is a mistake even when the cleanup looks complete. (c) Tie the disposable-VM principle to the book's second theme, the original is sacred — what, in a malware lab, plays the role of "the original you never touch"?
32.3 A new analyst sets up a lab with a single Windows VM bridged to the office network "so the malware can phone home and I can see the real C2 respond." Identify three distinct things wrong with this setup, and for each, state the correct alternative (name the tool or setting). (answer in Appendix)
32.4 ⭐ (Judgment.) You are handed a USB drive in an IR engagement with a file named invoice_scan.pdf.exe and told "just take a quick look." Before you do anything, write the four questions you must answer about authorization, isolation, the evidentiary original, and your goal — and explain why "confirm your authorization to possess and analyze the sample" (rule 10) is on the list at all when you were handed the drive by the client.
Group B — Static triage: identity, hashing, and reputation OPSEC
Static triage is safe and fast; ten disciplined minutes tells you whether you have a known commodity, a packed unknown, or a targeted implant.
32.5 Why must you establish a file's true type with file (its magic bytes) rather than trusting its extension? Give the magic bytes for (a) a Windows PE and (b) a Linux ELF, and state what each of the following ELF identification bytes told you about the recovered kworkerd sample: EI_CLASS = 2, EI_DATA = 1, e_machine = 0x3E, e_type = 3. (answer in Appendix)
32.6 Distinguish the three hash types in static triage by what each one is for: SHA-256, imphash, and ssdeep. (a) Two samples have completely different SHA-256 values but an identical imphash of 8a1f4c9e2b6d83f05c1ae97d44b2e810 — what does that tell you, and why? (b) Two samples score 95% similar under ssdeep but differ in SHA-256 — what does that tell you? (c) Which of the three is useless for catching the next variant of a family, and why does the Pyramid of Pain agree?
32.7 (The OPSEC decision.) For each scenario, state whether you would (a) look up the hash only, (b) upload the full sample to a public service like VirusTotal/ANY.RUN, or (c) detonate only on a self-hosted CAPE — and justify each in one sentence: (i) a clearly commodity adware bundle from a home user's laptop; (ii) the winhost.exe implant from the targeted WEB-07 intrusion; (iii) an unknown binary from a sensitive matter under legal hold. (answer in Appendix)
32.8 Reconstruct the reasoning behind the rule "look up the hash, do not upload the sample" in a targeted incident. (a) What does a hash lookup reveal to the attacker? (b) What does an upload reveal to the attacker, and through what mechanism do operators learn of it? (c) Write the one-sentence policy you would put in your team's runbook so a junior analyst never has to re-derive this at 2 a.m.
32.9 ⭐ (Calculate and verify the hash.) At acquisition (Chapter 15) the recovered ELF was sealed in the chain of custody with SHA-256 = e7d2a9c4…. Tonight you copy it into the lab and compute the working copy's hash. (a) What must the working copy's hash equal, and what does a match prove? (b) Your copy hashes to a different value — list the three most likely innocent explanations and the one that should stop the analysis cold. (c) Explain why this verification is the first thing you do after intake and the last thing you would want to discover you skipped, in the language of chain of custody.
Group C — Strings, the PE/ELF structure, imports, and entropy
These are the high-value middle of static analysis — the import table is the implant's spec sheet, and entropy reveals what packing hides.
32.10 (Interpret the output.) You run strings on winhost.exe and circle these lines: Software\Microsoft\Windows\CurrentVersion\Run, schtasks /create /tn "WindowsHostUpdate" /sc minute /mo 10, 185.220.101.47, /gate, Global\MSCTF_x7f3a2b, GetAsyncKeyState, and {"c2":. For each line, name the capability or IOC it points to in one phrase. Then explain why you must run strings twice — once for ASCII and once with -e l (UTF-16LE) — and what you would miss otherwise. (answer in Appendix)
32.11 A 600 KB executable returns only a dozen strings, mostly the names LoadLibraryA, GetProcAddress, VirtualProtect, and ExitProcess. (a) What does this absence tell you, and which theme is it ("the absence of a trace is itself a trace")? (b) What single static measurement would you take next to confirm the hypothesis? (c) What is your next action once confirmed, and why is a static-only verdict on this file incomplete?
32.12 (Calculate — read the PE header.) Given this hex from the start of a sample:
00000000 4D 5A 90 00 03 00 00 00 ...
0000003C F8 00 00 00
000000F8 50 45 00 00 64 86 06 00 9B 41 5A 65 ...
(a) Confirm the file is a PE: what are the bytes at offset 0, and what 4-byte value sits at offset 0x3C? (b) That value is e_lfanew — compute the offset it points to, and verify the signature there reads PE\0\0. (c) Machine = 0x8664 and the TimeDateStamp field reads 9B 41 5A 65 — state the architecture, and explain in one sentence why you would not report the decoded build time as a fact. (answer in Appendix)
32.13 ⭐ (Calculate — decode the timestamp.) Take the PE TimeDateStamp field 9B 41 5A 65. (a) Read it as a little-endian 32-bit value and write the hexadecimal number it represents. (b) Convert that hex to decimal. (c) Interpret the decimal as a Unix epoch (seconds since 1970-01-01 UTC) and give the approximate calendar date. (d) Now give two reasons this value is at best a weak lead — one about forgery, one about what packers do to it. Show your arithmetic. (answer in Appendix)
32.14 (Interpret the import table.) From winhost.exe's imports, group these into the four capabilities they reveal and name each capability: CreateMutexA; VirtualAllocEx, WriteProcessMemory, CreateRemoteThread; RegCreateKeyExA, RegSetValueExA, OpenSCManagerA, CreateServiceA; SetWindowsHookExA, GetAsyncKeyState, GetForegroundWindow; InternetOpenA, InternetConnectA, HttpSendRequestA. Then explain why GetForegroundWindow paired with the keylogging APIs makes the captured keystrokes more dangerous, not just more numerous.
32.15 (Interpret entropy.) You compute per-section entropy for winhost.exe: .text 6.42, .rdata 5.10, .data 3.88, .rsrc 7.86, .reloc 4.95. (a) Which section is the anomaly, and what does a value near 7.9 mean physically? (b) Because .text is normal (6.42), what can you conclude about whether the whole file is packed — and what is hiding in .rsrc instead? (c) Which import from 32.14 explains how that hidden content gets used at runtime? (d) Contrast this with a UPX-packed sample: name two giveaways in the section table and one in the import table, and state the command that often unpacks UPX. (answer in Appendix)
Group D — YARA: turning observation into reusable detection
A finding that lives only in your notebook protects no one. YARA is how one analyzed sample becomes a sensor for the whole campaign.
32.16 (Write the rule.) Write a YARA rule named APT_WEB07_winhost_backdoor for the Windows implant. Include a meta block (author, date, the SHA-256 b41c0e9a…, the imphash 8a1f4c9e…, TLP, and a reference to the ATT&CK techniques); a strings block with at least the C2 IP, the /gate URI, the mutex, the user-agent, the Run-key path, and the config bytes { 7B 22 63 32 22 3A }; and a condition that (i) confirms a real PE via the MZ/PE\0\0 check, (ii) bounds filesize, and (iii) requires the config bytes or at least 3 of the text strings. Annotate each line of the condition with what it does. (answer in Appendix)
32.17 Explain why the rule in 32.16 requires "3 of 5" strings rather than any single one. (a) Why is a lone match on 185.220.101.47 or on the Run-key path a poor detection? (b) Why does the hex pattern { 7B 22 63 32 22 3A } let this one rule match both the file on disk and the running process in a memory image? (c) Which chapter owns the memory-scanning use of YARA, and how would you invoke yara against the WEB07-mem.raw image?
32.18 ⭐ (Judgment / Pyramid of Pain.) Your first draft of the rule keys only on the SHA-256 and the C2 IP. Critique it against the Pyramid of Pain. (a) Where on the pyramid do those two indicators sit, and how cheaply does the attacker defeat them? (b) Rewrite the strategy (not the syntax) to target durable indicators, naming the specific mutex, user-agent, task name, and config structure you would key on and why each is "annoying" or worse for the attacker to change. (c) State the principle in one sentence: write the rule to the most durable behavior you can.
Group E — Dynamic analysis: detonating under observation
When static hits a packer, or you need behavior rather than capability, you detonate — once per snapshot, instrumented across all four domains.
32.19 Name the four domains of dynamic monitoring and the primary tool for each. (a) For each domain, give one thing the WEB-07 detonation revealed in that domain. (b) Explain the before/after diff workflow and which tool implements it. (c) Why do you "only get one clean detonation per snapshot," and what does that imply about preparing your instrumentation before you press go? (answer in Appendix)
32.20 (Interpret the process tree.) The detonation's Process Hacker view shows:
winhost.exe (PID 4120)
├─ cmd.exe /c reg add "HKCU\...\CurrentVersion\Run" /v WindowsHostSvc ...
├─ cmd.exe /c schtasks /create /tn "WindowsHostUpdate" /sc minute /mo 10 /ru SYSTEM
└─ (no child) -- injects into -> explorer.exe (PID 2104)
(a) Which two persistence mechanisms are being created here, and where will each live? (b) The third branch shows injection into explorer.exe — name the API trio that accomplishes it and explain what changes about whose identity the malicious activity now runs under. (c) Why does confirming these in the process tree matter when the static imports already predicted them — what does dynamic analysis add that static could not?
32.21 (Build the timeline.) Using the artifacts below, build a short MACB-style intrusion timeline (event · source · UTC) and write the two-sentence narrative it supports. Cross-reference Chapter 21 — Timeline Analysis. Artifacts: Regshot shows the WindowsHostSvc Run value and the WinHostSvc service ImagePath added; a self-copy appears at %APPDATA%\Microsoft\Windows\winhost.exe; a file %TEMP%\~wh3a2b.tmp is created and grows; the packet capture shows a POST /gate to 185.220.101.47 repeating every ~60 s; the EDR first alerted on a 60-second beacon from WEB-07. (answer in Appendix)
32.22 ⭐ (The fake internet.) The chapter insists that faking the internet is what makes the network behavior observable. (a) Explain what most malware does when it cannot resolve its C2, and why a "no network at all" lab therefore shows you almost nothing. (b) Describe what INetSim/FakeNet-NG do when the sample resolves api.cloudmetric-sync.net and POSTs to /gate. (c) State the OPSEC reason you also would not just give a targeted sample the real internet, tying back to the upload/exposure problem from Group B.
Group F — Capabilities, IOCs, and the report
The point of all the analysis is deliverables the responder, the SOC, and counsel can act on.
32.23 (Map to ATT&CK.) For each WEB-07 capability, give the MITRE ATT&CK technique ID and one piece of evidence that supports it: (a) Run-key persistence; (b) service persistence; (c) scheduled-task persistence; (d) process injection into explorer.exe; (e) keylogging; (f) HTTPS command-and-control; (g) exfiltration over the C2 channel; (h) SMB lateral movement. (answer in Appendix)
32.24 (Persistence hunt — and the dual lens.) The most insidious WEB-07-adjacent persistence is a WMI event subscription. (a) Why is it called "fileless," and where does it actually live on disk and in the namespace? (b) Write the one-line Get-CimInstance query a responder runs to enumerate it. (c) Now resolve the Recovery vs. Forensics tension on a found persistence entry: the remediation reader wants to delete every entry to truly clean the host; the examiner wants to preserve them as evidence. State the professional sequence that serves both, and what specifically you capture before removing a malicious service.
32.25 (Build and defang the IOC package — write the report.) Assemble a one-page IOC package for case 2026-0428-IR at TLP:AMBER, organized into FILE / NETWORK / HOST / DETECTIONS sections, using every indicator the chapter established (hashes, imphash, C2 IP and domain, user-agent, mutex, Run value, service, task, file paths, the YARA rule name, and a one-line Sigma idea). Defang all network indicators using the bracket convention and explain in one sentence why. Then write the two-sentence "capabilities summary" paragraph that would open the report's technical findings. (answer in Appendix)
32.26 ⭐ (Judgment — capability vs. behavior, and the limits of attribution.) Two sentences from a draft report are challenged on cross-examination. For each, state whether it is defensible from your analysis or overreaching, and rewrite the overreaching one: (i) "The binary imports the API set used for keystroke capture." (ii) "This sample is the work of APT group X." Then explain the difference between a forensic finding and an intelligence assessment with a confidence level, and why conflating them is how examiners get impeached (cross-reference Chapter 27 — Expert Testimony).
Group G — Progressive project: analyze the implant in your case file
Your Forensic Case File now holds an image, recovered artifacts, a timeline, and a suspicious executable recovered from the subject system. Add a malware-analysis annex.
32.27 (Intake safely.) Copy the sample into your isolated lab, defang the filename, store it in a password-protected zip (password infected), and verify the working copy's SHA-256 matches the evidentiary original you sealed at acquisition. Open a chain-of-custody entry for the sample (template in Appendix F) and record the verification in your log. State, in one line, why you never detonate the only copy you have.
32.28 (Full static-then-dynamic pass.) Run the complete triage on your working copy: establish true file type; compute SHA-256 / imphash / ssdeep; perform a hash-only reputation check; run strings (ASCII + UTF-16LE); parse the PE/ELF header and import table; and compute per-section entropy, noting whether the sample appears packed. Author a YARA rule keyed to durable indicators and verify it matches the sample (and the memory image if you have one). Then snapshot the VM, instrument process/file/registry/network, detonate, observe persistence, dropped files, injection, and C2, and revert — recording behavioral evidence with timestamps. Add every hash and artifact to the case file. (answer in Appendix)
32.29 ⭐ (Produce the deliverables and state the limits.) Write the malware-analysis annex: a capability list mapped to ATT&CK; a defanged IOC package (hashes, C2, mutex, registry keys, paths, YARA, Sigma); and a one-paragraph attribution statement with a confidence level and its basis. Then write the limitations section honestly — name any anti-VM behavior you observed, any packing you could not unpack, and any capability that was indicated but not confirmed — and feed the host indicators back into your Chapter 15 triage tooling to note which other hosts they would sweep. Save the annex, YARA, IOC package, and sandbox report into the case file for the capstone (Chapter 38).
Self-check. You have mastered this chapter when you can (1) stand up an isolated lab and handle a live sample without endangering your host, your network, or the evidence — and prove the working copy matches the sealed original; (2) run a static triage that yields file type, identity and similarity hashes, the capability-revealing imports, and an entropy verdict on packing — and know not to upload a targeted sample; (3) write a YARA rule that targets durable, middle-of-the-pyramid indicators and matches both a file and a memory image; (4) detonate safely, read the process/file/registry/network behavior, and tell capability from behavior in your wording; and (5) turn it all into an ATT&CK-mapped capability list and a defanged IOC package that scopes the breach — with an honest statement of what you could not establish. If any of those five still feels improvised, redo Groups A, C, and F before moving on. Next, Chapter 33 — Cryptocurrency Investigation follows the money the weapon was built to extract.