Chapter 11 — Digital forensics and malware analysis: verification
Lesson map
Lesson 11 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Verifying collections"]
N2["Lab — manifest verification"]
N3["11.2 Reading the result"]
N4["11.3 Handling the mismatch"]
N5["11.4 Verifying findings"]
N6["11.5 Peer check"]
N7["11.6 Records"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Verifying collections"]
N2["Lab — manifest verification"]
N3["11.2 Reading the result"]
N4["11.3 Handling the mismatch"]
N5["11.4 Verifying findings"]
N6["11.5 Peer check"]
N7["11.6 Records"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]
[Learning outcomes]
|
v
[11.1 Verifying collections]
|
v
[Lab — manifest verification]
|
v
[11.2 Reading the result]
|
v
[11.3 Handling the mismatch]
|
v
[11.4 Verifying findings]
|
v
[11.5 Peer check]
|
v
[11.6 Records]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) verify collected files against manifests; (2) investigate mismatches; (3) verify findings by a second source; (4) record verification.
11.1 Verifying collections
Every collected file was hashed at collection. Before analysis and before handover, files are re-hashed and compared with the manifest.
Re-hashing before analysis catches any change since collection, and re-hashing before handover lets the receiver trust what they get. The manifests from the collection logs, such as the 63-file triage manifest for PHARM-PC3, provide the expected values. Sana uses the reviewed script rather than comparing long hash strings by eye. The comparison result for each file is written into the verification table immediately.
Lab — manifest verification
"""Verify collected copies against a manifest of SHA-256 digests."""
import hashlib
files = {"memory.raw": b"synthetic-memory", "triage.zip": b"synthetic-triage", "usb_log.csv": b"synthetic-usb"}
manifest = {k: hashlib.sha256(v).hexdigest() for k, v in files.items()}
files["usb_log.csv"] = b"synthetic-usb\r\n" # re-saved by an editor
for k, v in files.items():
print(k, "OK" if hashlib.sha256(v).hexdigest() == manifest[k] else "MISMATCH")
Run with python3 lab_verify.py. Verified output:
memory.raw OK
triage.zip OK
usb_log.csv MISMATCH
11.2 Reading the result
memory.raw and triage.zip verify OK. usb_log.csv shows MISMATCH: someone opened it in an editor and re-saved it, adding a line ending. The content looks the same, but it is no longer the collected file.
A single added line ending is invisible when the file is viewed, which is why only the hash revealed it. The mismatch does not mean the evidence is worthless, since a verified original still exists in the store. It does mean the edited copy cannot be used, because nobody can prove that nothing else changed.
11.3 Handling the mismatch
The altered copy is set aside and labelled. A fresh copy is made from the evidence store, verified OK and used for analysis. The incident is noted in the case log, and the evidence folder is made read-only for operators.
The altered copy is kept rather than deleted, because deleting it would hide what happened from later reviewers. Making the folder read-only addresses the cause, since operators can no longer re-save files there by accident. This was one of the response failure modes already listed, and it is now recorded as having actually happened once.
11.4 Verifying findings
Key findings are checked by a second source: the USB connection time on PHARM-PC3 from the registry is compared with the EDR mount event; they agree within two seconds.
Two independent sources agreeing within two seconds is strong support for the 11:15 connection time, since the registry and the EDR agent record it in different ways. Where a finding rests on one source only, Sana says so in her notes. The table of findings shows which ones have a second source and which do not.
11.5 Peer check
Owen repeats two findings from Sana's notes alone.
Owen uses only Sana's notes and the evidence store, without asking her questions, so the test shows whether the notes are complete. If he cannot reach the same result, the gap is in the notes, not necessarily in the finding. He records which two findings he repeated and whether they matched. For this case he chose the PHARM-PC3 USB connection time and the corrected WARD4-PC2 sequence. He signs the verification table once both repeats are complete.
11.6 Records
A verification table lists item, expected hash, result, date and verifier.
Each row is dated and signed, and new checks add rows rather than overwriting earlier ones. For usb_log.csv the table shows the mismatch on 15 September, followed by the fresh copy verified OK. Owen reviews the table before any handover and adds his name beside Sana's. The table travels with the evidence at every handover, so whoever receives the files can repeat the checks against the same expected hashes.
11.7 Standards
ISO/IEC 27037 stresses integrity of evidence and repeatability; verification is how operators show both.
The verification table, the manifests and the custody records together show that evidence was not altered and that the checks can be repeated. ISO/IEC 27037 does not prescribe a particular tool, so the hospital's own scripts are acceptable as long as they are validated and recorded. Verification of copies remains separate from the question of whether collection was complete. Owen's peer check and the second-source comparisons add reproducibility to the integrity the hashes show.
When to verify
Verification happens at three points: immediately after collection, before analysis starts, and before any handover to analysts, auditors or police. Each check is a new row in the table, so a reader can see that integrity held at every step, not only at the start.
Worked example
Sana's verification table: "usb_log.csv — MISMATCH on 15/09 (editor re-save). Fresh copy from store — OK. memory.raw — OK. triage.zip — OK. Verifier: S. Mirza; reviewed O. Price."
Synthetic case. Files come from the lab script.
Errors and limits
Verification proves copies match collection, not that collection captured everything relevant.
Exercises
- EX041 — Lab result. Which file mismatched, and why? Rubric: 3 = usb_log.csv; editor re-save added line ending; 2 = file only; 1 = wrong; 0 = none.
- EX042 — Mismatch handling. What was done after the mismatch? Rubric: 3 = set aside, fresh verified copy, logged, folder read-only; 2 = partial; 1 = ignored; 0 = none.
- EX043 — Second source. How was the PHARM-PC3 USB time verified? Rubric: 3 = registry vs EDR mount, within 2 s; 2 = partial; 1 = vague; 0 = none.
- EX044 — Verification limit. What does verification not prove? Rubric: 3 = completeness of collection; 2 = partial; 1 = proves all; 0 = none.
Synthesis
Verify copies, explain mismatches, confirm findings with second sources and keep a verification table.
Continue studying — chapter 11 of 18
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →