Writing the Forensic Report: Making Your Findings Hold Up

Prerequisites

• All DFA-C01, DFA-C02, DFA-C03 core cards

Why This Lesson Matters

A forensic examiner who cannot write is like a detective who cannot testify. Your analysis may be flawless — you found the deleted file, you proved the timestamp, you correlated three artefact sources — but if you cannot explain it clearly, accurately, and defensibly, the findings are useless. This lesson teaches the structure, language, and discipline of forensic report writing.

1. The Forensic Report's Purpose

The report must serve multiple audiences simultaneously:

One report, one set of facts, four audiences. The structure must accommodate all four.

2. Report Structure

Forensic Report
├── 1. Cover Page
├── 2. Executive Summary (1 page)
├── 3. Scope and Objectives
├── 4. Evidence Received
├── 5. Methodology
├── 6. Findings
│   ├── 6.1 Finding 1 — [descriptive title]
│   ├── 6.2 Finding 2 — [descriptive title]
│   └── ...
├── 7. Timeline
├── 8. Conclusions
├── 9. Limitations and Caveats
└── Appendices (tool output, raw data excerpts, additional exhibits)

2.1 Cover Page

DIGITAL FORENSIC EXAMINATION REPORT
Case Number:   IR-2026-0608-001
Examiner:      Alice Martin, DFA Certification #042
Date of Report: 2026-06-15
Classification: CONFIDENTIAL — ATTORNEY-CLIENT PRIVILEGE
Report Version: 1.0

2.2 Executive Summary

One page. Written for a non-technical reader. No jargon.

EXECUTIVE SUMMARY

A forensic examination of the hard drive and memory image from workstation WS-042
was conducted between June 9 and June 14, 2026.

The examination revealed that on June 8, 2026, an external attacker gained access
to WS-042 at approximately 14:30 UTC via a brute-force attack against the "alice"
user account. The attacker then used this access to install malicious software and
connect to a server they control on the internet.

Two files were found that had been deliberately concealed: a malware binary and a
configuration file containing credentials. Both are detailed in the Findings section.

No evidence was found that personal or financial data was removed from the workstation.
The examination of the finance database server (SRV-001) is documented in a
separate report.

2.3 Evidence Received

Document every exhibit:

Item  Description                           Hash (SHA-256)       Received
1     512 GB HDD, SN ABC12345, from WS-042  a3f9b2...           2026-06-09 09:15 UTC
2     16 GB RAM image, WS-042               b4c8d1...           2026-06-09 09:15 UTC
3     Security.evtx, WS-042                 c5d9e2...           2026-06-09 10:00 UTC

2.4 Methodology

Describe every significant step:

Forensic imaging:
  Item 1 was connected via Tableau T35689 hardware write-blocker.
  A forensic image was created using dc3dd v7.3.0 with SHA-256 hashing.
  The recorded hash (a3f9b2...) was verified against a recomputed hash on
  2026-06-09 at 11:30 UTC. Hashes matched; evidence integrity confirmed.

Analysis tools:
  Autopsy v4.21.0 — file system analysis and artefact extraction
  Volatility 3.0.0 — memory image analysis
  log2timeline/plaso v20240101 — super-timeline construction
  RegRipper 3.0 — registry hive analysis
  exiftool v12.60 — metadata extraction

All tools are validated against NIST CFTT test sets where available.

3. Writing Findings

Each finding follows the same structure:

6.1 Finding: Malicious Service Installation

Exhibit reference: Item 1 (HDD image), Item 3 (Security.evtx)

Description:
  A Windows service named "WindowsUpdateHelper" was installed on WS-042 on
  2026-06-08 at 14:32:41 UTC. The service binary is located at
  C:UsersPublicDocumentsupdate.exe, a path outside the standard Windows
  system directories and writable by any user without administrator privileges.

Evidence:
  1. Windows System Event Log (Item 3), Event ID 7045, record number 8901,
     timestamp 2026-06-08 14:32:41 UTC:
     ServiceName: WindowsUpdateHelper
     ImagePath: C:UsersPublicDocumentsupdate.exe
     ServiceType: Own Process; Start type: Auto Start

  2. NTFS MFT record for update.exe (inode 2847) shows:
     File created: 2026-06-08 14:32:38 UTC (3 seconds before service installation)
     SHA-256: f8g2b5c7d9e0f1a2b3c4d5e6f7a8b9c0

  3. The SHA-256 hash was submitted to VirusTotal on 2026-06-09. Result:
     41 of 72 security engines classified the file as malicious.
     Family: CobaltStrike Beacon (Loader variant).

Significance:
  The installation of this service by the authenticated attacker session
  constitutes persistence (T1543.003 — Create or Modify System Process:
  Windows Service). The service would restart the malicious binary on
  every system reboot, maintaining attacker access.

4. Language Rules

Use passive voice for tool actions, active voice for attacker actions: - ✓ "The MFT record was analysed using istat." - ✓ "The attacker installed a service at 14:32:41 UTC." - ✗ "I analysed the MFT record." (Too informal) - ✗ "The service was installed." (Obscures the actor)

Never speculate — qualify instead: - ✗ "The attacker probably used Mimikatz to dump credentials." - ✓ "The presence of lsass.exe memory access (Sysmon Event 10, GrantedAccess 0x1410) is consistent with credential dumping tools such as Mimikatz."

Cite every factual claim: - ✗ "The file was created on the day of the incident." - ✓ "The file was created on 2026-06-08 at 14:32:38 UTC (MFT record 2847, $STANDARD_INFORMATION attribute, Born timestamp)."

5. Limitations and Caveats

Every forensic report must include a limitations section. It is professional — not a weakness.

9. LIMITATIONS AND CAVEATS

9.1 Log retention: The DNS server logs were unavailable as they had been
    overwritten by the standard 7-day retention policy before collection.
    DNS-based C2 activity during the incident window cannot be assessed.

9.2 Encrypted traffic: TLS 1.3 connections to 185.220.101.5 (27-minute
    session duration) could not be decrypted. The content of this session
    is unknown. The duration and timing are consistent with C2 activity
    but no direct evidence of data transfer is available.

9.3 Memory acquisition: RAM acquisition was performed 47 minutes after
    the attacker's session ended. Volatile data from the active session
    (active network connections, decrypted credentials in memory) may
    have been partially overwritten.

6. Common Mistakes

Mistake 1: Conclusions not supported by cited evidence. Every conclusion must be traceable to a specific exhibit, timestamp, and artefact. "The attacker exfiltrated data" without evidence is speculation.

Mistake 2: No limitations section. A report without a limitations section looks like the examiner is hiding something. Limitations are professional transparency.

Mistake 3: Using first person throughout. "I found" and "I concluded" in a formal report sounds informal and makes the examiner (not the evidence) the focus. Use passive voice for your own actions.

Mistake 4: Describing what was not done as if it was done. If you did not examine the cloud storage account, do not imply you did. Write: "Cloud storage accounts were not within the scope of this examination."

7. Practice Exercises

1. Rewrite this finding sentence in correct forensic report language: "I think the attacker probably deleted a bunch of files to cover their tracks before they left."

2. Your report states: "No evidence of data exfiltration was found." But you did not check the DNS logs (they were unavailable). How do you correct this statement?

3. Write a two-sentence limitations entry for: "The workstation's Recycle Bin had been emptied before imaging."

8. Lab

Assessment mode: quiz

You are given a draft forensic report section with 6 deliberate errors: - Speculation stated as fact - Missing evidence citation - First person in formal finding - Conclusion that contradicts the evidence presented - Missing limitations caveat for an unavailable log source - Incorrect UTC timezone notation

Identify and correct all six.

9. Framework Alignment

10. Further Reading

• SWGDE Best Practices for Digital Evidence Documentation — Industry standard for forensic report format
• ACPO Good Practice Guide — Section on report writing with examples
• Expert Witness Report Writing (UK CPS guidance) — Applicable principles for any jurisdiction

["Write a complete forensic finding that includes an exhibit reference, factual description, three evidence citations with timestamps, forensic significance, and ATT&CK mapping", "Apply the four language rules to rewrite three incorrectly phrased forensic sentences (speculation, missing citation, wrong voice, obscured actor)", "Write a two-entry limitations section for a described investigation where DNS logs were unavailable and one EVTX channel was cleared before acquisition"]

Prerequisites → Why this matters → Report purpose and audiences → Report structure (9 sections) → Section deep-dive: cover, executive summary, evidence received, methodology, findings → Finding structure template (with worked example) → Language rules (passive/active, qualifiers, citations) → Limitations section → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading