Chapter 27 — Digital forensics and malware analysis: verification
Lesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Why verify findings"]
N2["27.2 Independent tools"]
N3["27.3 Raw checks"]
N4["27.4 Peer review"]
N5["27.5 Verification of times"]
N6["27.6 When verification fails"]
N7["27.7 Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Why verify findings"]
N2["27.2 Independent tools"]
N3["27.3 Raw checks"]
N4["27.4 Peer review"]
N5["27.5 Verification of times"]
N6["27.6 When verification fails"]
N7["27.7 Documentation"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]
[Learning outcomes]
|
v
[27.1 Why verify findings]
|
v
[27.2 Independent tools]
|
v
[27.3 Raw checks]
|
v
[27.4 Peer review]
|
v
[27.5 Verification of times]
|
v
[27.6 When verification fails]
|
v
[27.7 Documentation]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) verify findings by independent methods; (2) cross-check tool output against raw data; (3) conduct peer review of findings; (4) document verification.
27.1 Why verify findings
A finding is stronger when two independent methods agree. ISO/IEC 27042 addresses analysis and interpretation and the need for findings to be supported and reviewable.
Agreement between methods matters because each has its own failure modes. A tool may misparse a value; a person may misread a hex view. When two methods with different weaknesses give the same answer, the chance that both are wrong in the same way is small. ISO/IEC 27042's emphasis on reviewable findings means that verification is recorded, not just done.
27.2 Independent tools
Leah's primary tool reports the run key. She confirms it with a second tool that parses registry hives differently. Both show value "Updater" → rundll32 update.dll with the same last-write time.
The two tools must be genuinely independent: if both rely on the same parsing library, a bug in it would affect both. Leah checks their documentation for the parser used. The matching last-write time also ties the key to the timeline, since it should agree with the run key's creation at 09:31:07 after the clock correction.
27.3 Raw checks
For key artefacts, she inspects the underlying bytes or records directly — for example, viewing the registry value data in a hex view — to confirm the tool's interpretation.
A hex view shows the bytes the tool interpreted. For the run key value, Leah confirms that the stored string is rundll32 followed by the path to update.dll, encoded as the registry stores it. If the tool had shown a cleaned-up or shortened version, the raw view would reveal it. Raw checks are slow, so she reserves them for findings that the report's conclusions rest on.
27.4 Peer review
Grace's colleague reviews each finding: Is the source cited? Is the interpretation supported? Were alternatives considered? Comments and responses are recorded.
The reviewer's three questions match the checklist Leah drafted from the recurring errors. Recording comments and responses shows how each finding changed, if at all, during review. A finding that was challenged and then supported with more evidence is stronger than one that was never questioned, and the record shows that strength. Leah answers every comment, even when the answer is simply that no change was needed and why.
27.5 Verification of times
Key times are confirmed in at least two sources: run key last-write time against the process start in memory and event logs.
For example, the run key's last-write time should fall shortly after the rundll32 process that created it started; memory and event logs record that start independently. If the times differed by minutes, Leah would look for a second write to the key or a clock problem. Agreement to the second gives confidence that the corrected timeline is right.
27.6 When verification fails
If two tools disagree, neither result is reported until the difference is understood and documented.
The worked example shows a typical case: a one-hour difference caused by display settings, not by the evidence. Until the cause was found, either value might have been wrong, and reporting one would have been a guess. Documenting the discrepancy and its resolution also helps the next examiner who uses the same tools. The lesson, set every tool to display UTC, is added to the lessons register for the whole team.
27.7 Documentation
A verification table lists finding, primary method, verifying method, result and reviewer.
A row in Leah's table reads: F6 run key; primary method registry tool A; verifying method registry tool B and hex view; result agree; reviewer Grace's colleague. Reviewers can scan the table to see which findings rest on one method only and ask for more work where needed. The table is attached to the report as an appendix. Findings verified by only one method are marked, and the report's wording for them is more cautious.
Reproducing from notes
A strong test is whether another analyst can reproduce a finding using only the notes. Leah asks a classmate to follow her notes for the run key finding without help. He succeeds but asks where the hive copy was stored; she adds the path to her notes template so the next reader will not need to ask.
Worked example
Two tools disagree on update.dll's creation time by exactly one hour. Leah traces the cause: one tool displayed times in its analysis machine's local zone, one hour ahead of UTC. Converted to UTC, both agree. The note records the discrepancy, cause and resolution.
Synthetic case. The discrepancy is invented.
Errors and limits
Two tools sharing the same parsing library are not independent; check how each works.
Exercises
- EX079 — Run key verification. How was the run key finding verified? Rubric: 3 = second tool with different parser, same value and time; raw check; 2 = partial; 1 = rerun same tool; 0 = none.
- EX080 — One-hour gap. What caused the one-hour disagreement? Rubric: 3 = one tool showed local time one hour ahead of UTC; 2 = partial; 1 = tool bug; 0 = none.
- EX081 — Independence. When are two tools not independent? Rubric: 3 = share parsing library/code; 2 = partial; 1 = always independent; 0 = none.
Synthesis
Verify important findings independently, explain every disagreement and record who reviewed what.
Continue studying — chapter 27 of 40
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →