Chapter 20 — Digital forensics and malware analysis: engineering context | Engineering Digital forensics and malware analysis

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 20 — Digital forensics and malware analysis: engineering context

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 The investigation chain"]
  N2["20.2 Engineering's role"]
  N3["20.3 Malware analysis"]
  N4["20.4 Mobile forensics"]
  N5["20.5 Capstone problem"]
  N6["20.6 Constraints"]
  N7["20.7 Success criteria"]
  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 The investigation chain"]
  N2["20.2 Engineering's role"]
  N3["20.3 Malware analysis"]
  N4["20.4 Mobile forensics"]
  N5["20.5 Capstone problem"]
  N6["20.6 Constraints"]
  N7["20.7 Success criteria"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 The investigation chain]
    |
    v
[20.2 Engineering's role]
    |
    v
[20.3 Malware analysis]
    |
    v
[20.4 Mobile forensics]
    |
    v
[20.5 Capstone problem]
    |
    v
[20.6 Constraints]
    |
    v
[20.7 Success criteria]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) describe where forensic engineering fits in investigations; (2) list the standards that shape lab work; (3) describe malware analysis roles; (4) frame Priya's capstone problem.

20.1 The investigation chain

Investigations move from identification and seizure to acquisition, examination, analysis and reporting. NIST SP 800-86 and ISO/IEC 27037 cover early stages; ISO/IEC 27042 covers analysis and interpretation; ISO/IEC 27041 covers assuring methods are suitable; ISO/IEC 27043 sets overall processes.

The stages overlap in practice. An examiner may find during analysis that more data needs acquiring, or a report may prompt further examination. The standards give each stage its own expectations about documentation, method suitability and interpretation. Priya maps EvidenceDesk features to the stages they support, which shows that the system covers acquisition and preservation well and leaves interpretation to examiners.

20.2 Engineering's role

Engineers build intake systems, imaging infrastructure, storage, automation and validation harnesses. They do not draw case conclusions, but their systems determine what examiners can trust.

For example, an imaging station that does not log retries would leave examiners unable to say whether a damaged region was read correctly. A storage system without integrity checks would let silent corruption go unnoticed until a re-verification years later. Engineers therefore own the reliability and transparency of the systems underneath the examination, even though conclusions are drawn by others.

20.3 Malware analysis

Malware analysts determine what a suspicious program does. Sikorski and Honig (2012) distinguish static analysis (examining without running) from dynamic analysis (running in a controlled environment). Engineers build the isolated labs where dynamic analysis is safe.

Static analysis includes hashing a sample, checking it against known sets, reading its strings and inspecting its imports and structure, all without running it. Dynamic analysis runs it in a monitored sandbox and records file, registry, process and network activity. Each method covers gaps in the other: packed code hides from static inspection, while sandbox-aware malware hides its behaviour from dynamic runs.

20.4 Mobile forensics

NIST SP 800-101r1 covers mobile device acquisition and preservation, a large part of modern caseloads with its own tools and isolation needs.

Phones combine encryption by default, frequent operating-system updates and app data stored in many formats. Acquisition options range from logical extraction through the device's own interfaces to more invasive methods, and each yields different data. Isolation matters because an online phone can receive remote wipe commands or new messages that overwrite older ones. Each method's yield is recorded, so readers know what a given extraction could and could not contain.

20.5 Capstone problem

Northfield's intake is paper-based, imaging logs are inconsistent and verification is sometimes skipped. Priya's capstone: an evidence intake and integrity system — "EvidenceDesk" — that registers items, records acquisitions, verifies hashes and keeps a tamper-evident custody log.

The paper intake process at Northfield sometimes leaves item numbers on labels that do not match the register, and imaging logs differ between stations. EvidenceDesk addresses both: each item gets a registered identifier and printed label at intake, and every acquisition records its manifest in one format. The custody log is hash-chained, so each entry includes the hash of the one before it.

20.6 Constraints

Must work offline in the examination zone, use auditable code and fit existing tools.

Working offline rules out cloud services and live package installs, so dependencies must be bundled and validated. Auditable code means a reviewer can read and test the source, which favours a small codebase in a common language. Fitting existing tools means accepting their output formats rather than replacing them, so EvidenceDesk wraps imaging tools and leaves them unchanged. Bundled dependencies are hashed, and those hashes are listed in the release record.

20.7 Success criteria

Every image verified before examination; custody history complete; reviewers can reproduce any record.

Each criterion has a test. To show that every image is verified, a test tries to queue an unverified item for examination and expects a refusal. To show custody is complete, every item must have an unbroken sequence of custody events from intake to its current location. To show reproducibility, a reviewer recreates a randomly chosen record from the stored manifest and gets the same hashes. Failures block release.

Scope boundaries

EvidenceDesk will not analyse evidence, decide relevance or write reports; those remain examiner tasks using validated tools. Keeping the scope narrow makes validation feasible within a capstone, and it lets Northfield adopt the system without changing how examiners reach conclusions. Priya writes the boundary into the project charter so later feature requests can be judged against it.

Worked example

Priya interviews three examiners. All describe skipped verification under time pressure; none record imager firmware versions. She writes two requirements from this: blocking verification and mandatory tool-version capture.

Synthetic case. Interviews are invented.

Errors and limits

Interviews show perceptions; she will check them against records.

Exercises

EX058 — Standards map. Which ISO/IEC standard covers analysis and interpretation? Rubric: 3 = 27042, with others placed; 2 = 27042 only; 1 = wrong; 0 = none.
EX059 — Static vs dynamic. Distinguish static and dynamic malware analysis. Rubric: 3 = without running vs running in controlled environment; 2 = partial; 1 = reversed; 0 = none.
EX060 — Requirements from interviews. Which two requirements came from the interviews? Rubric: 3 = blocking verification, tool-version capture; 2 = one; 1 = vague; 0 = none.

Synthesis

Forensic engineering builds the trusted infrastructure under standards-based investigations; EvidenceDesk is Priya's contribution.

Continue studying — chapter 20 of 50

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →