LX1.4 Evidence Integrity and Chain of Custody

Evidence Integrity: Hashing, Documentation, and Chain of Custody

Why Integrity Matters for Every Investigation

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

Every evidence file should be hashed immediately after collection. UAC does this automatically — it generates a hashes.sha256 file containing the SHA256 hash of every collected artifact. For manually collected evidence, hash each file as you collect it:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Hash a single file
sha256sum evidence/auth.log > evidence/auth.log.sha256

# Hash all files in a directory recursively
find evidence/ -type f -not -name "*.sha256" -exec sha256sum {} \; > evidence/hashes.sha256

# Verify hashes later
cd evidence/
sha256sum -c hashes.sha256
# Output: each file shows "OK" or "FAILED"

For disk images, the hash is critical because a multi-gigabyte disk image cannot be visually inspected for modifications. Hash the disk image immediately after acquisition:

1
2
3
4
5

# During disk acquisition — hash simultaneously
dc3dd if=/dev/sda hash=sha256 log=evidence/disk_acquisition.log of=evidence/bastion-nge01.raw

# Or hash after acquisition
sha256sum evidence/bastion-nge01.raw > evidence/bastion-nge01.raw.sha256

The dc3dd tool (a forensic version of dd) computes the hash during acquisition — you get the hash at the same time as the image, with no additional pass over the data. This is the preferred method for disk imaging because it saves time and provides the hash in the acquisition log.

Chain of Custody Documentation

The chain of custody records who handled the evidence, when, and what they did with it. For a Linux investigation, the chain of custody document should include:

Collection record — for each evidence artifact: what was collected (filename or description), when it was collected (UTC timestamp), where it was collected from (hostname, IP, path), who collected it (investigator name), how it was collected (tool and command used), and the SHA256 hash at the time of collection.

Transfer record — for each handoff: who transferred the evidence, who received it, when, and how (USB drive, network transfer, cloud storage). If evidence is transferred electronically, hash verification should occur at both ends.

Storage record — where the evidence is stored (encrypted disk, evidence locker, cloud storage with access controls), who has access, and what access controls are in place.

Analysis record — who analyzed the evidence, when, what tools were used, and whether the analysis was performed on the original evidence or a working copy. Best practice: always analyze a copy, never the original. Hash the copy and verify it matches the original before beginning analysis.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# Evidence collection log template
cat << 'LOGEOF' > evidence/collection_log.md
# Evidence Collection Log
# Case: IR-2026-0402
# System: BASTION-NGE01 (192.168.1.50)
# Investigator: J. Morrison
# Collection start: 2026-04-02T03:55:00Z
# Collection end: 2026-04-02T04:32:00Z

## Collection Actions

| Time (UTC) | Action | Tool | Output | SHA256 |
|---|---|---|---|---|
| 03:55 | Record system time | date -u | timestamp.txt | [hash] |
| 03:56 | Capture running processes | ps auxf | processes.txt | [hash] |
| 03:57 | Capture network connections | ss -tnp | network.txt | [hash] |
| 03:58 | Capture /proc process data | custom script | proc_data.txt | [hash] |
| 04:02 | Copy auth.log | scp | auth.log | [hash] |
| 04:05 | Copy syslog | scp | syslog | [hash] |
| 04:10 | Run UAC ir_triage | UAC v2.x | uac_output/ | [manifest hash] |
| 04:32 | Collection complete | — | — | — |

## Notes
- Investigator SSH session began at 03:55 — entries in auth.log
  after this timestamp include investigator activity
- System clock verified accurate (within 2 seconds of NTP reference)
- Evidence stored on encrypted USB drive RC-EVIDENCE-004
LOGEOF

When Legal Proceedings Are Anticipated

For investigations that may involve law enforcement, regulatory action, or civil litigation, evidence handling standards are stricter. The key additions:

Write blockers for bare-metal disk acquisition. A hardware write blocker physically prevents any write operation to the evidence disk. Software write blockers (mounting read-only) are acceptable for cloud disk snapshots and copied evidence, but hardware write blockers are the standard for original physical media.

Two independent hashes (SHA256 + MD5, or SHA256 + SHA1). If one hash algorithm has a collision weakness (MD5 has known collision attacks), the second hash provides independent verification. SHA256 alone is sufficient for most purposes, but dual hashing is the standard for evidence that may be challenged in court.

Witness documentation. A second person witnesses the evidence collection and signs the collection log. This prevents challenges based on the investigator fabricating evidence.

Evidence sealing. Physical media (USB drives, hard drives) are sealed in tamper-evident bags with the case number, date, and hash written on the seal. If the bag is opened, it is visibly obvious.