Chapter 28 — Digital forensics and malware analysis: failure analysis
Lesson map
Lesson 28 published. Map, example, EX082.
flowchart TD
N0["Learning outcomes"]
N1["28.1 Root cause analysis"]
N2["28.2 Contributing factors"]
N3["28.3 Investigation failures"]
N4["28.4 Blameless review"]
N5["28.5 Lessons register"]
N6["28.6 Follow-up"]
N7["28.7 Sharing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX082"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["28.1 Root cause analysis"]
N2["28.2 Contributing factors"]
N3["28.3 Investigation failures"]
N4["28.4 Blameless review"]
N5["28.5 Lessons register"]
N6["28.6 Follow-up"]
N7["28.7 Sharing"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX082"]
[Learning outcomes]
|
v
[28.1 Root cause analysis]
|
v
[28.2 Contributing factors]
|
v
[28.3 Investigation failures]
|
v
[28.4 Blameless review]
|
v
[28.5 Lessons register]
|
v
[28.6 Follow-up]
|
v
[28.7 Sharing]
|
v
[Worked example] --> [Exercise EX082]
Learning outcomes
You will (1) analyse why the incident succeeded using root-cause methods; (2) distinguish root causes from symptoms; (3) analyse failures in the investigation itself; (4) record lessons.
28.1 Root cause analysis
Asking "why?" repeatedly moves from symptom to cause. Why was ws-114 compromised? A macro ran. Why? Macros from internet files were allowed. Why? The policy predated internet-marking features and was never reviewed. The root cause is an unreviewed policy, not the user.
Stopping at "a macro ran" would lead to a narrow fix; stopping at "the user clicked" would lead to blame. Following the chain to the unreviewed policy points to a fix that protects every user. The analysis also shows why the policy was never reviewed, which may reveal a gap in how the university manages security settings over time.
28.2 Contributing factors
Push MFA without number matching, file share logging off, and nightly reimaging that could have destroyed evidence were contributing factors.
Contributing factors did not start the incident but made it worse or harder to investigate. Push MFA without number matching let the 10:02 sign-in succeed. Logging being off left Q3 partly unanswered. Nightly reimaging nearly erased the endpoint evidence. Each is recorded so its fix can be tracked alongside the root cause, rather than being forgotten once the main fix is done.
28.3 Investigation failures
The investigation itself had problems: the first team note overstated a conclusion; proxy log export initially covered only one hour; a tool displayed local time. Each is recorded.
Recording the investigation's own problems is part of honest practice. The one-hour proxy export would have missed the 09:31:02 download had it not been widened. The local-time display caused the one-hour disagreement between tools. None changed the final findings, but each could have, and each led to a lesson in the register below.
28.4 Blameless review
Reviews focus on systems and decisions, not individuals, so people report problems honestly.
If the analyst who exported only one hour of logs were blamed, the next analyst might hide a similar mistake. A blameless review asks why the export window was too narrow, perhaps because the request form had a one-hour default, and fixes that. The aim is that problems are reported early, when they are cheap to correct. Grace's team writes its review in terms of process steps, never names.
28.5 Lessons register
Each lesson has an owner and a due date: review macro policy annually; standardise log export windows; set tools to display UTC.
Owners and dates turn lessons into tasks. "Standardise log export windows" becomes a change to the export request form owned by the log administrator, due within a month. "Set tools to display UTC" becomes a setting in the lab's standard configuration. The register is reviewed at Grace's monthly team meeting, where overdue items are discussed and either given a new date or escalated.
28.6 Follow-up
Lessons are checked later to confirm they were implemented.
For the macro policy, follow-up means repeating the synthetic macro test after the change and recording the result. For the export window, it means checking that the next few exports use the new default. A lesson that is recorded but never checked may not have been implemented, and the same problem could appear in the next case. Grace's register has a column for the follow-up result, filled in only after the check is done, with the date and the evidence that the change works.
28.7 Sharing
Lessons go to the wider IT team and, anonymised, to the course.
Wider sharing spreads the benefit: the IT team can check other policies that may also be outdated, and students learn from a realistic case. Anonymisation removes names and details that could identify the user or reveal remaining weaknesses. For the course, the ws-114 case is already synthetic, so it can be used freely as a teaching example. For a real case, Grace would ask the data protection officer to confirm the anonymised version before it left the security office.
Timeline of the response
Leah also builds a timeline of the response itself: alert at 09:35, ticket opened 09:50, ws-114 isolated 10:20, credentials reset 11:30, forwarding rule removed 11:42. Gaps between steps show where response could be faster; the almost ninety minutes between the 10:02 account takeover and the 11:30 reset allowed the forwarding to continue.
Worked example
Leah's root-cause chart for the evidence gap: "Why was file share access unknown? Logging off. Why? Disabled years ago for storage cost. Why not revisited? No owner for logging decisions." Recommendation: assign an owner for logging policy with annual review.
Synthetic case. The analysis is invented.
Errors and limits
"Five whys" can stop too early or follow one branch; draw several branches when causes are multiple.
Exercises
- EX082 — Root cause. What was the root cause of the macro running? Rubric: 3 = unreviewed macro policy; 2 = partial; 1 = user; 0 = none.
- EX083 — Investigation failure. Name two failures in the investigation itself. Rubric: 3 = overstated note, short log export, local-time display; 2 = one; 1 = vague; 0 = none.
- EX084 — Blameless. Why use blameless review? Rubric: 3 = encourages honest reporting; focus on systems; 2 = partial; 1 = kindness only; 0 = none.
Synthesis
Trace incidents and investigation problems to root causes, assign owners and follow up.
Continue studying — chapter 28 of 40
← Chapter 27 (draft) · Course chapter index · Chapter 29 (draft) →