In this section
LX1.4 Evidence Integrity and Chain of Custody
Evidence Integrity: Hashing, Documentation, and Chain of Custody
Evidence integrity is not just a legal requirement. It is a professional standard that distinguishes reliable investigation from guesswork. When you present findings to a CISO, a legal team, or a regulator, the first question is not "what did you find?" — it is "how do you know the evidence has not been modified since you collected it?" If you cannot answer that question with cryptographic proof, your findings are assertions rather than evidence.
The mechanism is simple: cryptographic hashing. When you collect a file, you compute its SHA256 hash. When you analyze the file days or weeks later, you recompute the hash. If the hashes match, the file has not been modified — not by you, not by anyone. If the hashes differ, the file was changed after collection, and you need to determine when and how.
Hashing Collected Evidence
# Hash a single file immediately after collection
sha256sum evidence/auth.log > evidence/auth.log.sha256
# Output: e3b0c44298fc1c149afb... evidence/auth.log
# Hash all files in a directory recursively
find evidence/ -type f -not -name "*.sha256" -exec sha256sum {} \; > evidence/hashes.sha256
# Creates a manifest of every file — verify the entire collection in one command
# Verify hashes before beginning analysis (days or weeks later)
cd evidence/
sha256sum -c hashes.sha256
# Output: each file shows "OK" or "FAILED"
# Any "FAILED" = the file was modified after collection → investigate
# Hash comparison for a specific file
sha256sum evidence/auth.log
# Compare output against the hash recorded in the collection log
# Must match character-for-character# During disk acquisition — hash simultaneously with dc3dd
dc3dd if=/dev/sda hash=sha256 log=evidence/disk_acquisition.log of=evidence/bastion-nge01.raw
# dc3dd computes SHA256 during the copy — no second pass needed
# Hash appears in the log file alongside acquisition metrics
# Standard dd + separate hash (if dc3dd is not available)
dd if=/dev/sda of=evidence/bastion-nge01.raw bs=4M status=progress
sha256sum evidence/bastion-nge01.raw > evidence/bastion-nge01.raw.sha256
# Two-pass approach: slower but achieves the same result
# Verify the image before mounting for analysis
sha256sum evidence/bastion-nge01.raw
# Must match the hash recorded during acquisition# Dual hashing for legal-standard evidence
sha256sum evidence/bastion-nge01.raw > evidence/bastion-nge01.raw.sha256
md5sum evidence/bastion-nge01.raw > evidence/bastion-nge01.raw.md5
# Both hashes recorded in the collection log and on the evidence bag label
# Verify both hashes before analysis
sha256sum -c evidence/bastion-nge01.raw.sha256 # Must show OK
md5sum -c evidence/bastion-nge01.raw.md5 # Must show OK
# Both must pass — if one fails, the evidence may have been modifiedMyth: "If you did not use a hardware write blocker, the evidence is inadmissible in court."
Reality: Hardware write blockers are the gold standard for physical disk acquisition, but their absence does not automatically render evidence inadmissible. Courts evaluate the totality of the evidence handling: was the collection documented, were hashes computed, can the investigator explain what modifications occurred and demonstrate they did not affect the evidence being analyzed? Cloud disk snapshots, for example, have no concept of a hardware write blocker — they are created by the cloud provider's API and are immutable by design. Software write blocking (mounting read-only) combined with hash verification is accepted for analysis of copied evidence. The standard is not perfection — it is documented, defensible handling with cryptographic verification.
Try it yourself
Create a test evidence directory on your forensic workstation.
Create a test evidence directory on your forensic workstation. Copy a few log files into it. Hash the directory: find evidence/ -type f -exec sha256sum {} \; > evidence/hashes.sha256. Now modify one file (add a blank line to the end of a log file). Verify the hashes: sha256sum -c evidence/hashes.sha256. One file should show "FAILED" — the file you modified. Now restore the file and verify again — it should show "OK". This is the integrity verification workflow you will perform on every investigation. Practice it until the commands are automatic: hash on collection, verify before analysis, document any discrepancy.
Beyond this investigation
Evidence integrity is not a one-subsection topic — it is a discipline that runs through every module in this course. In LX2 (Filesystem Forensics), you will hash disk images before and after timeline generation to prove the analysis did not modify the evidence. In LX14 (IR Reporting), the chain of custody log becomes a required section of the IR report. In LX15 (Insider Threat), the elevated evidence handling standard is mandatory because the investigation may lead to employment tribunal proceedings. In every investigation scenario (LX4-LX13), the collection phase begins with hashing and the analysis phase begins with verification — this subsection teaches the discipline that the rest of the course assumes you practice.
Check your understanding:
1. You collected auth.log from a compromised system three weeks ago and hashed it (SHA256: abc123...). You are now beginning analysis. What is your first step before opening the file? 2. Why does dc3dd provide a more reliable acquisition process than standard dd? 3. The chain of custody log shows a gap — evidence was transferred on March 28 but the recipient's verification hash was not recorded until March 31. Why is this a problem, and what should you document? 4. You need to analyze a 50GB disk image. Should you analyze the original or a copy, and why? 5. You are investigating an insider threat that may lead to an employment tribunal. What evidence handling standard do you use, and what additional steps does it require beyond a standard internal investigation?
You are investigating a Linux server and discover evidence of both a cryptominer (resource abuse) and an SSH key theft (lateral movement preparation). The cryptominer is consuming 95% CPU and impacting production. Which do you address first?
Address the lateral movement first. The cryptominer is visible, noisy, and contained to this server — it is causing performance impact but not spreading. The SSH key theft is silent, potentially already exploited, and may have given the attacker access to additional servers. Contain the lateral movement risk: rotate the stolen SSH keys, check the target servers for unauthorized access, and apply network restrictions. Then address the cryptominer: kill the process, remove the binary and persistence mechanisms. Prioritizing the noisy but contained threat over the silent but spreading threat is the most common Linux IR prioritization mistake.
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.