In this section
TR1.7 Chain of Custody and Evidence Integrity
From TR1.6 you know the preservation decision tree — whether to preserve or contain first based on the attacker's current state. But the evidence you capture is only as trustworthy as the documentation that accompanies it. The chain-of-custody discipline: SHA256 hashing at collection, integrity verification at every handoff, the six-field evidence log, and the storage procedures that keep evidence defensible for investigation, regulatory compliance, and legal proceedings.
Scenario
Three days after the NE triage, the investigation team opens the memory dump from WS-FIN-042. They extract the Cobalt Strike beacon configuration, identify the C2 infrastructure, and prepare a report for Rachel. Rachel asks: "Can we prove this memory dump hasn't been modified since Priya captured it? If legal asks us to demonstrate evidence integrity for the GDPR notification, can we?" The answer depends entirely on whether Priya computed a SHA256 hash at the moment of capture, whether that hash was verified when the evidence was transferred to the investigation team, and whether the chain-of-custody log documents every handoff. If any of those steps were skipped, the answer is "we think so, but we can't prove it."
Figure TR1.7 — The evidence integrity chain. SHA256 is computed at collection and verified at every subsequent transition. The original is never modified — all analysis uses copies.
SHA256: the integrity fingerprint
Every evidence file captured during triage must have a SHA256 hash computed at the moment of collection. The hash is a 64-character hexadecimal string that serves as the file's unique fingerprint — any modification to the file, even changing a single byte, produces a completely different hash. This property is what makes hash verification trustworthy: if the hash matches, the file is byte-for-byte identical to the original. If it doesn't match, something changed.
Why SHA256 specifically? MD5 and SHA-1 are both deprecated for integrity verification because researchers have demonstrated practical collision attacks — producing two different files with the same hash. In a forensic context, a collision attack would allow an adversary to swap evidence with a modified version that produces the same hash, defeating the integrity check. SHA256 has no known practical collision attacks and is the standard specified in NIST SP 800-86 for digital evidence integrity.
Some organisations use SHA-512 for additional margin, but SHA256 is universally accepted in both legal and regulatory proceedings.
The hash is computed once at collection, recorded in the evidence manifest, and verified at every subsequent handoff. When the triage responder transfers evidence to the investigation team, the receiving analyst recomputes the hash and compares it against the manifest. When the investigation team copies evidence to the analysis workstation, the hash is verified again before analysis begins.
Any mismatch at any transition means the file was modified — the modified copy cannot be used, and the chain-of-custody log must document the failure and the transition point where the mismatch was detected.
NIST SP 800-86 formalises this as part of the four-step forensic process: collection, examination, analysis, and reporting. The integrity requirement applies from collection through every subsequent phase. The triage responder's specific responsibility is the collection phase — hash at capture, store on controlled media, and execute a documented handoff with hash verification by the receiving party. The examination and analysis phases are the investigation team's responsibility, but they inherit the integrity guarantees established during collection.
If the collection phase lacks integrity verification, every subsequent phase is built on an unverified foundation.
Evidence transfer: the handoff procedure
The physical transfer of evidence from the triage responder to the investigation team is the most vulnerability-prone step in the chain. During the NE incident, the handoff occurs at 07:15 — Priya and Tom have captured evidence across Windows and Linux, Marcus has initiated cloud evidence exports, and the IR lead is ready to receive the evidence package.
The handoff procedure has three steps. First, the triage responder shares the evidence manifest — the list of evidence files with their collection timestamps, SHA256 hashes, source systems, and collection tools. The manifest is the receiving party's verification checklist. Second, the evidence is transferred — physically (USB handoff) or electronically (secure copy to the evidence share). Third, the receiving party independently computes SHA256 hashes for every transferred file and compares them against the manifest.
If every hash matches, the transfer is verified and both parties sign the chain-of-custody log. If any hash fails to match, the specific file is flagged, the transfer route is investigated, and the triage responder provides the original from the controlled storage media.
For remote incidents where the triage responder and investigation team are not in the same location, the transfer happens over encrypted channels — SFTP to the evidence share, or an encrypted blob upload with hash verification over a separate communication channel. The hash should never travel over the same channel as the evidence: if the transfer channel is compromised and the evidence is modified in transit, sending the hash over the same channel allows the attacker to modify both.
Sharing the hash manifest via a separate authenticated channel (a signed email, a message in the incident Slack channel, or a direct phone verification) ensures the receiving party can detect tampering.
The chain-of-custody log
The chain-of-custody log tracks every person who handled the evidence, when they received it, and whether the integrity hash verified at each transition. Without this record, the evidence is a file of unknown provenance — useful for internal intelligence but not defensible for regulatory submissions, insurance claims, employment actions, or legal proceedings.
Six fields are required for every evidence item: what was collected (description and file size), who collected it (analyst name), when it was collected (UTC timestamp), where it was stored (media identifier — USB serial number, evidence share path, or cloud storage location), the SHA256 hash at collection, and the transfer record (who received it, when, and whether the hash verified). The production triage scripts from later modules generate the first five fields automatically.
The transfer record is manual — the receiving analyst verifies the hash and both parties acknowledge the handoff.
The timeline shows an 18-minute window from decision to containment, with hash computation happening at the point of collection for each environment independently. The handoff at 07:15 is where the formal chain of custody transfers — the IR lead verifies every hash in the manifest, and both parties sign the transfer acknowledgment. From this point forward, any modification to the evidence is detectable and attributable.
Evidence storage and write protection
Evidence storage determines whether the chain of custody holds after the handoff. Evidence stored on a shared network drive where colleagues have write access is not defensible — anyone with access could have modified the files, intentionally or accidentally. Evidence on a USB drive that was not write-protected after imaging may have been modified by auto-mount behaviour, antivirus scanning, or filesystem journaling on the analyst's workstation.
The standard is to store evidence on controlled media separate from the compromised system. For USB drives, hardware write-protection (a physical switch on the drive) or software write-blocking prevents any modification after the evidence is written.
The Wiebetech USB WriteBlocker and Tableau Forensic USB Bridge are purpose-built hardware write-blockers used in forensic acquisition — but for triage purposes, a USB drive with a physical write-protect switch (available on some industrial USB models) or a software write-blocker built into the triage toolkit is sufficient.
The critical requirement is that write-blocking is engaged after evidence is written, not before the analyst begins — a common mistake is enabling write-protection on the empty USB before use, preventing the analyst from writing evidence to it at all.
For network evidence shares, access control should restrict write permissions to a single evidence management account — no shared access, no "everyone can edit" permissions. A dedicated evidence share at \\evidence\IR-2026-0419\ with write access limited to the triage team's evidence account and read access for the investigation team provides separation of duties. The share's access log records every file operation, providing an additional audit trail alongside the chain-of-custody log.
For cloud evidence storage (Azure Blob, S3), immutable storage policies prevent modification or deletion for a configured retention period. Azure Blob's time-based retention policy can be configured as WORM (Write Once, Read Many) — once evidence is uploaded, it cannot be modified or deleted until the retention period expires, even by the storage account administrator. AWS S3 Object Lock provides the same capability.
These policies provide cryptographic-strength integrity guarantees that exceed what USB or network share storage can offer, because the storage platform itself enforces immutability rather than relying on access control alone.
The analyst works on a copy of the evidence, never the original. The original is preserved with its collection-time hash intact. If the analysis tool modifies a file on access (some tools update timestamps when opening files), only the working copy is affected. The original remains verifiable against the collection hash indefinitely.
Evidence retention timelines should be established before the incident, not during it. GDPR breach notifications must be filed within 72 hours, but the regulatory investigation that follows may take months. Cyber insurance claim reviews commonly extend 6–12 months after the incident. Employment law proceedings involving insider threats can take years. The evidence preserved during triage must remain available, with chain of custody intact, for the full duration of any downstream process.
NE's evidence retention policy specifies a minimum 2-year hold for all incident evidence, with the legal team's approval required for any deletion. The cost of retaining 50 GB of evidence for two years on immutable cloud storage is negligible compared to the cost of discovering that evidence was deleted before a regulatory inquiry completed.
When chain of custody fails
The most common failure is not malicious tampering — it's an analyst who forgets to record what they did. You export logs from three systems during triage, place them in a shared folder, and move on to containment. Three days later, the investigation team asks which system each file came from, when it was exported, and what tool was used. If you did not record this at collection time, you're reconstructing from memory — and memory is unreliable evidence.
The 30-second discipline of recording the six fields at collection time prevents hours of uncertainty during investigation.
Consider the NE scenario specifically. Tom captures evidence from web-prod-01 — container exports, /proc state, auth.log, nginx access logs. If Tom places these files in /evidence/linux/ without a manifest, the investigation team later finds four files with no metadata explaining which server they came from, what tool collected them, or whether the capture was complete.
If NE has two Linux servers in scope (web-prod-01 and db-prod-03), the investigation team cannot determine which server each file belongs to without re-examining the file contents — wasting investigator hours on provenance that should have been recorded in seconds.
The second most common failure is forgetting to hash the evidence at collection time. If you realise the gap 20 minutes later, hash the evidence now and document the gap: "Hash computed at 07:35, approximately 20 minutes after collection.
Evidence stored on USB WD-123456 in the SOC evidence cabinet during the gap." A late hash is less ideal than an immediate hash — it cannot prove the evidence was unmodified during the 20-minute gap — but it establishes integrity from that point forward. A late hash is vastly better than no hash at all, because it still allows the investigation team to verify integrity for all subsequent transfers.
The third failure mode is collecting evidence to a location the attacker can reach. If the evidence is written to a folder on the compromised system, the attacker may modify or delete it before containment completes. If the evidence is written to a network share the compromised account has access to, the attacker may discover the evidence collection and tamper with it.
In the NE scenario, svc-backup has broad read access across file shares — writing evidence to any share that svc-backup can reach means the attacker could access the evidence using the same compromised credential. Evidence storage must be on media or shares that the compromised identity and system cannot access.
Chain of custody serves multiple purposes beyond criminal prosecution. GDPR Article 33 requires demonstrating the measures taken to address a breach — documented evidence handling proves the organisation responded professionally. Cyber insurance claims require evidence of the incident and response quality — unchained evidence may be challenged by the insurer. Employment actions involving insider threats require an evidence chain that supports the HR process. Even for purely internal investigations, the investigation team needs to trust that the evidence is authentic and unmodified. A 30-second evidence log entry per item provides that trust. Skipping it saves 30 seconds during triage and undermines every subsequent use of the evidence.
Triage Principle
Hash everything at the moment of collection. Verify the hash at every transition. Document who had the evidence, when, and where. Store evidence on controlled media the compromised system cannot reach. Work on copies, never originals. These five habits take 30 seconds per evidence item during triage and make the difference between evidence the investigation team can trust and evidence they cannot.
Get weekly detection and investigation techniques
KQL queries, detection rules, and investigation methods — the same depth as this course, delivered every Tuesday.
No spam. Unsubscribe anytime. ~2,000 security practitioners.