DFIR Fundamentals

Foundation

Digital forensics is the application of scientific methodology to identify, preserve, analyze, and present digital evidence in a manner that is legally admissible. Proper handling of evidence is paramount—mistakes can render critical artifacts inadmissible in court.

Chain of Custody

Chain of custody documents who handled evidence, when, where, and why. Every transfer must be logged, and the log is itself evidence: an unexplained gap is what opposing counsel attacks first, long before anyone argues about what the artifact actually means.

chain-of-custody.md

# Chain of Custody Template

## Evidence Details
- Case Number: 2026-001-RANSOMWARE
- Evidence ID: EVD-2026-001-HDD01
- Description: 1TB Western Digital hard drive from CFO laptop
- Serial Number: WD-WCAV12345678
- Collection Date/Time: 2026-01-15 09:45 UTC
- Collector: Jane Smith, DFIR Analyst

## Hash Values (Verification)
- MD5: 3cb3de2dbf3941dcaa98fa98cf8f63ce
- SHA256: 556b61dbf285a20da435ae0fca1541d6d7699d7e11df1cefe44bc5520a1f9f54

## Chain of Custody Log
| Date/Time | Transferred From | Transferred To | Reason | Signature |
|-----------|------------------|----------------|--------|-----------|
| 2026-01-15 09:45 | On-site (CFO office) | J. Smith | Collection | JS |
| 2026-01-15 11:30 | J. Smith | Evidence locker | Storage | JS |
| 2026-01-15 14:00 | Evidence locker | M. Johnson | Analysis | MJ |
| 2026-01-16 17:00 | M. Johnson | Evidence locker | Analysis complete | MJ |

## Storage Location
Building A, Room 120, Evidence Locker #3 (locked, access log maintained)

The two digests above are examples, and they are digests of the same 22-byte file — not of the hard drive, and not of two different strings. Verify that claim yourself before you trust the method: a custody record whose MD5 and SHA-256 belong to different inputs is a defect the reader can detect, and an auditor will.

verify-demo-hashes.sh

# Reproduce the two digests above from one input
printf 'DFIR custody hash demo' > demo.txt
md5sum demo.txt
sha256sum demo.txt
# 3cb3de2dbf3941dcaa98fa98cf8f63ce  demo.txt
# 556b61dbf285a20da435ae0fca1541d6d7699d7e11df1cefe44bc5520a1f9f54  demo.txt

Never Work on Original Evidence

Always create a forensic image (bit-for-bit copy) and verify with cryptographic hashes. Work on the copy, preserve the original in a secure location.

Roles and Legal Authority

Evidence handling fails most often on authority, not on tooling: someone collects a laptop nobody authorised them to touch, or ships an image across a border without checking the transfer rules. Name the decision owners before the incident, and record which one approved each collection.

Role	Owns	Decides
Incident commander	Severity, scope, containment tempo	When a host may be isolated, rebuilt, or wiped
Forensic analyst	Acquisition, analysis, findings, reproducibility	Which artifacts answer the investigation question
Evidence custodian	Storage, access control, transfer log	Who may handle the original and under what conditions
Legal counsel	Privilege, disclosure, employment and privacy law	What may be collected, retained, or shared externally
System or data owner	Business context, service impact, data classification	Authorising collection on their estate

The lawful basis for collection comes from one of a small set of sources, and you should be able to name which one applies before you copy anything: an acceptable-use or monitoring policy the user has acknowledged, a written authorisation from the system owner, a contractual right in a managed-service agreement, or a court order, warrant, or regulatory demand. Public-sector and cross-border cases add their own constraints — GDPR and UK GDPR treat a forensic image as personal data, which brings minimisation, retention, transfer, and subject-access duties with it.

Get Scope in Writing

A verbal "go ahead" is not a legal basis. Record the approver's name, role, timestamp, and the hosts and data classes in scope in the case record, and keep it with the evidence manifest rather than in chat.

Forensic Imaging as a Discipline

The point of imaging is not to copy bytes — it is to be able to prove you did not change them. Three principles carry that proof, regardless of which tool performs the acquisition:

Block every write path. A hardware write blocker on the source, or a documented software blocker where hardware is impractical, and no exceptions for "just a quick look".
Image, don't browse. Opening a file on a live volume updates access timestamps and the USN journal. On evidence, analysis happens against the verified copy only.
Hash twice, record both. SHA-256 as the primary digest and MD5 for legacy tooling and interop, captured at acquisition, re-verified before analysis, and re-verified before delivery.

Record the tool name and version, the image format, the write blocker, and the operator for every acquisition; a hash proves the bytes match, it does not prove the bytes were captured correctly. The acquisition commands and the evidence manifest schema live in Evidence Acquisition.

Order of Volatility

Collect evidence from most volatile (disappears quickly) to least volatile:

1. CPU Registers, Cache — Lost immediately when system powers off

2. RAM (Memory) — Lost when powered off or rebooted

3. Network State, Running Processes — Changes constantly, collect before shutdown

4. Disk (Non-volatile storage) — Persists, but can be overwritten

5. Backups, Logs — Most persistent, but may be incomplete

Live Response First

If the system is running, perform live response to collect memory, network connections, and running processes BEFORE pulling the plug. Once powered off, this data is gone forever.

Evidence Acquisition

The acquisition procedure, imaging commands, and the evidence manifest schema this page refers to.

Memory Forensics

Capturing and triaging the most volatile artifact on the list with AVML and Volatility 3.

Disk Forensics

Sleuth Kit partition offsets, NTFS metadata, and recovering deleted files from a verified image.

Incident Response

The containment decisions that trade evidence preservation against business impact.

AI Incident Response

How the same preservation and custody discipline applies to an incident involving an AI system.