◇ OpenCyber Academy
Bachelor's · Chapter 24 · English

Chapter 24 — Digital forensics and malware analysis: controls

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 24 — Digital forensics and malware analysis: controls

Lesson map

Lesson 24 published. Map, example, EX070.

flowchart TD
  N0["Learning outcomes"]
  N1["24.1 What worked"]
  N2["24.2 What failed"]
  N3["24.3 Evidence-based recommendations"]
  N4["24.4 Prioritising"]
  N5["24.5 Avoiding overreach"]
  N6["24.6 Verifying controls"]
  N7["24.7 Communicating"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX070"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["24.1 What worked"]
  N2["24.2 What failed"]
  N3["24.3 Evidence-based recommendations"]
  N4["24.4 Prioritising"]
  N5["24.5 Avoiding overreach"]
  N6["24.6 Verifying controls"]
  N7["24.7 Communicating"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]
[Learning outcomes]
    |
    v
[24.1 What worked]
    |
    v
[24.2 What failed]
    |
    v
[24.3 Evidence-based recommendations]
    |
    v
[24.4 Prioritising]
    |
    v
[24.5 Avoiding overreach]
    |
    v
[24.6 Verifying controls]
    |
    v
[24.7 Communicating]
    |
    v
[Worked example] --> [Exercise EX070]

Learning outcomes

You will (1) identify which controls failed or worked in the ws-114 incident; (2) recommend controls based on evidence; (3) distinguish preventive, detective and corrective controls; (4) avoid recommendations the evidence does not support.

24.1 What worked

The proxy logged requests (detective); the indicator alert fired (detective); segmentation kept ws-114 from reaching staff servers (preventive); the security office responded within hours (corrective).

Listing what worked is not self-congratulation; it identifies controls to keep and fund. Segmentation's value is easy to overlook because its success is an absence: no staff server was reached. The proxy logs, which made the timeline possible, would be an obvious target for budget cuts if their role in this case were not recorded.

24.2 What failed

The email gateway delivered the phish (preventive failed); the user's MFA push was approved (preventive failed); macros were allowed to run from downloaded documents (preventive gap); file share logging was off (detective gap).

Each failure maps to a control layer: the gateway's filtering, the MFA method, the macro policy and the logging configuration. Describing them as control gaps rather than personal failures keeps the analysis useful. The macro gap is the most direct link in the chain, since Q1_budget.xlsm saved at 09:15:10 launched the EXCEL to cmd to rundll32 sequence.

24.3 Evidence-based recommendations

Block macros in files from the internet; switch MFA to number matching to reduce push fatigue; enable file share access logs; hold reimaging for alerted machines. Each links to a specific finding.

Linking each recommendation to a finding lets decision makers see why it matters and lets auditors later check whether it addressed the problem. Number matching makes a user type a code shown on the sign-in screen, which a user who did not start the sign-in cannot do, so an unexpected push like the one at 10:02 would fail.

24.4 Prioritising

Recommendations are ranked by risk reduction and effort. Blocking internet macros is high impact, low effort.

Blocking macros from the internet would have stopped the ws-114 chain at its first executable step and needs only a policy change. Enabling file share logs is cheaper still but detects rather than prevents. Switching MFA methods affects every user and needs communication, so it ranks high in impact but medium in effort. Leah presents the ranking as a small table so decision makers can see the trade-offs at once.

24.5 Avoiding overreach

The evidence does not show the user ignored training, so "retrain the user" is not recommended as a finding-based action; a general awareness reminder may be considered separately.

A recommendation without supporting evidence weakens the report, because readers may doubt the others too. It also risks blaming a victim of a well-crafted attack. If the security office wants to review awareness training, that decision can be made on its own merits, outside the forensic report. Leah's report sticks to controls that the evidence links to the incident.

24.6 Verifying controls

After changes, tests confirm they work: a synthetic macro document from the internet should be blocked.

Testing with a synthetic document confirms the policy applies to the right file types and sources. The test is recorded like any other evidence: date, file used, expected result, actual result. Without the test, the university might believe it was protected while a misconfigured policy let macros run. A similar test for number matching uses a training account to confirm an unexpected push cannot be approved.

24.7 Communicating

Recommendations are written for decision-makers: what, why (finding), effort, owner.

Decision-makers rarely need technical detail; they need to know what to approve and why. A line such as "block macros in internet files: stops the ws-114 attack chain at the document stage; one-day effort; owner: desktop team" gives them that. The technical evidence remains in the report's appendix for those who want to check it. Each line in the summary carries the identifier of the finding it rests on, so a manager who doubts a recommendation can ask for that finding and see the evidence directly.

Residual risk

After the recommended changes, some risk remains: attackers can still steal credentials with convincing pages, and new delivery methods appear. Leah's report states the residual risk plainly so leadership does not assume the problem is solved, and she proposes a review in six months.

Worked example

Leah's table row: "Finding F3: macro in Q1_budget.xlsm launched cmd and rundll32. Recommendation: block macros in files marked as from the internet. Effort: low (policy). Owner: desktop team. Verification: synthetic test document blocked."

Synthetic case. The findings are invented.

Errors and limits

Controls reduce risk; no set of controls makes incidents impossible.

Exercises

Synthesis

Recommend controls that trace to findings, rank them, verify them and avoid claims the evidence does not support.

Continue studying — chapter 24 of 40

← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →