Chapter 20 — Digital forensics and malware analysis: foundational cases
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 Why study cases"]
N2["20.2 Recurring error: tunnel vision"]
N3["20.3 Recurring error: timestamp misreading"]
N4["20.4 Recurring error: unvalidated tools"]
N5["20.5 Recurring error: overstated conclusions"]
N6["20.6 Good practice"]
N7["20.7 Applying to ws-114"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 Why study cases"]
N2["20.2 Recurring error: tunnel vision"]
N3["20.3 Recurring error: timestamp misreading"]
N4["20.4 Recurring error: unvalidated tools"]
N5["20.5 Recurring error: overstated conclusions"]
N6["20.6 Good practice"]
N7["20.7 Applying to ws-114"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 Why study cases]
|
v
[20.2 Recurring error: tunnel vision]
|
v
[20.3 Recurring error: timestamp misreading]
|
v
[20.4 Recurring error: unvalidated tools]
|
v
[20.5 Recurring error: overstated conclusions]
|
v
[20.6 Good practice]
|
v
[20.7 Applying to ws-114]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) study documented lessons from forensic practice; (2) identify recurring errors; (3) relate them to standards; (4) apply lessons to ws-114.
20.1 Why study cases
Mistakes repeat. Reviewing documented practice and guidance helps students recognise patterns before making them.
Guidance documents and published reviews describe the same errors appearing in different labs and countries. Learning them in the classroom costs nothing; learning them in casework can cost a wrong conclusion. Each of the following errors has a specific counter-measure, and Leah adds each one to her checklist for ws-114 as she reads. The list grows from her reading, not from a template, so each item has a case behind it.
20.2 Recurring error: tunnel vision
Investigators who settle early on one explanation interpret everything to fit it. Casey (2011) stresses considering alternative explanations systematically.
Tunnel vision is hard to spot from inside, because each piece of evidence seems to confirm the theory. Writing alternatives down before testing makes them harder to dismiss. In the ws-114 case, the early note saying "the user installed malware" was a candidate for this error, and the worked example shows Leah listing three alternatives and checking each against the process tree and timeline.
20.3 Recurring error: timestamp misreading
Time-zone confusion, clock offsets and misunderstanding which timestamp means what have led to wrong sequences. Careful normalisation and documentation counter this.
The ws-114 case contains its own example: the workstation clock ran 47 seconds slow, and without correction the run key would appear before the DLL it points to had been downloaded. Misreading which timestamp a field holds, such as modification versus metadata change, causes similar errors. Leah normalises everything to UTC, applies the measured offset, and names the timestamp type for each entry in her timeline.
20.4 Recurring error: unvalidated tools
Results from tools never tested for the task have been challenged. ISO/IEC 27041 addresses assurance that methods are suitable; NIST's CFTT programme publishes tool test results.
Validation means testing a tool on data where the right answer is known, then recording how it performed. For ws-114, Leah checks that the tool she uses for registry parsing has been tested for run keys on her OS build, or she tests it herself on a training image. The test result goes into the case file so that a reviewer can see the basis for trusting the tool's output.
20.5 Recurring error: overstated conclusions
Reports that say "proves" when evidence only "is consistent with" mislead courts. Calibrated language is a professional obligation.
The difference matters because a court or manager may act on the stronger word. "The process tree proves the user ran the malware" claims more than the tree shows; "the process tree shows the DLL was launched from the spreadsheet in s.kaur's session" states what was observed. Leah reviews each conclusion for its verb, and checks that the strength of the word matches the evidence cited beside it.
20.6 Good practice
Contemporaneous notes, peer review, documented alternatives, verified copies and clear limitations recur in successful cases.
These practices reinforce each other: contemporaneous notes make peer review possible, verified copies make results repeatable, and stated limitations prevent overreach. None of them is expensive, and together they make a report that another examiner can check. Leah's checklist in the next part turns them into concrete items for ws-114 that she ticks as each is completed, so nothing depends on memory at the end of the case.
20.7 Applying to ws-114
Leah drafts a checklist: alternatives listed for each finding; all times normalised to UTC with offset applied; tools and versions recorded; language reviewed.
Each item counters one recurring error: alternatives counter tunnel vision, UTC with offset counters timestamp misreading, tool records counter unvalidated tools, and language review counters overstatement. The checklist is short enough to use for every finding. Grace's team adopts it for later cases, which shows how a lesson from reading becomes a working procedure that outlives one case.
Learning from near misses
Not every lesson comes from published failures. The security office keeps a log of near misses — a nearly skipped verification, a wrong drive almost imaged — and reviews them quarterly. Leah reads the log and adds two items to her checklist from it, noting their source so reviewers know the checklist grew from local experience.
Worked example
An early team note says "the user installed malware". Applying the checklist, Leah lists alternatives: the user opened a document whose macro launched it; another account did it remotely; a scheduled task from earlier activity created it. The process tree and timeline support the first; the others are recorded and assessed.
Synthetic case. The note is invented.
Errors and limits
Lessons from one context may not transfer directly; adapt checklists to each case.
Exercises
- EX058 — Tunnel vision. What is tunnel vision, and what counters it? Rubric: 3 = early fixation; systematic alternatives; 2 = one; 1 = vague; 0 = none.
- EX059 — Alternatives. List the alternatives Leah recorded for "user installed malware". Rubric: 3 = macro launch, remote account, earlier scheduled task; 2 = two; 1 = one; 0 = none.
- EX060 — Checklist. Name three items on Leah's checklist. Rubric: 3 = alternatives, UTC/offset, tools/versions, language; 2 = two; 1 = one; 0 = none.
Synthesis
Recurring errors have known counters; build them into every case.
Continue studying — chapter 20 of 40
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →