Evidence Collection: Order of Volatility & Chain of Custody

Prerequisites

• CIR-K001: The PICERL Lifecycle

Why This Lesson Matters

Digital evidence is not like a fingerprint on a door handle — it does not just sit there waiting to be collected. RAM contents disappear the moment you power off the system. Network connections close. Log files rotate. An investigator who collects evidence in the wrong order may arrive at a powered-off machine and realise the most valuable evidence — what was running — is gone forever.

The order of volatility and chain of custody are not bureaucratic formalities. They are what make digital evidence usable — in court, in a regulatory investigation, and in your own post-incident analysis.

1. The Order of Volatility

The order of volatility ranks evidence sources from most ephemeral (disappears soonest) to most persistent (survives reboots, even disk wiping).

Most volatile (collect first)
│
│  1. CPU registers & cache          — lost on any context switch
│  2. RAM contents                   — lost on power-off; lost partially on reboot
│  3. Network state                  — connections close when sessions end
│  4. Running processes              — process list changes constantly
│  5. Open file handles              — change as programs open/close files
│  6. Routing table / ARP cache      — times out, refreshes
│  7. Temporary filesystem (/tmp)    — cleared on reboot
│  8. Swap / virtual memory          — partially survives reboot in some configs
│  9. Disk image                     — survives power-off; overwritten by activity
│  10. Remote logs / SIEM            — most persistent; survives local wipe
│  11. Archived backups              — most durable; may be weeks old
│
Most persistent (collect last, but do collect)

Practical rule: Power off = lose everything above #8. Never power off a running compromised system until you have collected what you need from it.

2. Live Response: Collecting Volatile Evidence

Live response means gathering evidence from a running system before you touch anything else.

2.1 What to Collect and How

# === Run these commands on the live compromised system ===
# Store output on a CLEAN USB or network share, NOT on the local disk

# 1. Current timestamp (first thing — creates timeline anchor)
date -u > /media/usb/evidence/timestamp.txt

# 2. Running processes (who is running?)
ps auxf > /media/usb/evidence/processes.txt
# Windows: tasklist /v > processes.txt

# 3. Network connections (who is the system talking to?)
ss -antp > /media/usb/evidence/network_connections.txt
# Windows: netstat -bno > network_connections.txt

# 4. Open files / file handles
lsof > /media/usb/evidence/open_files.txt
# Windows: handle.exe > open_files.txt  (Sysinternals)

# 5. Logged-in users
w > /media/usb/evidence/logged_in_users.txt
# Windows: query user

# 6. Recent commands (attacker may have cleared history — collect anyway)
cat /root/.bash_history >> /media/usb/evidence/bash_history.txt
cat /home/*/.bash_history >> /media/usb/evidence/bash_history.txt

# 7. Scheduled tasks / cron (persistence check)
crontab -l -u root > /media/usb/evidence/root_cron.txt
ls -la /etc/cron* >> /media/usb/evidence/root_cron.txt
# Windows: schtasks /query /fo LIST /v > scheduled_tasks.txt

# 8. Memory acquisition (do this before any other disk activity)
# Linux: LiME kernel module
sudo insmod lime.ko "path=/media/usb/evidence/memory.lime format=lime"
# Windows: winpmem_mini.exe /tmp/memory.raw

Why store on USB/network share? Every file write to the local disk changes timestamps and may overwrite sectors that contain evidence. Always write to external media.

2.2 Memory Acquisition is Non-Negotiable

RAM contains: - Decrypted credentials (passwords, private keys never written to disk) - Running malware that is fileless (lives only in memory) - Injected code in legitimate processes - Network connections that closed after the fact - Clipboard contents

If you cannot acquire memory, document why in the chain of custody and note the limitation in your report.

3. Non-Volatile Evidence

After live response, collect evidence that persists through reboots:

# Disk image (bit-for-bit copy, NEVER work on the original)
dc3dd if=/dev/sda hash=sha256 log=case_001_disk.log 
  of=/media/usb/evidence/disk.img

# Verify integrity
sha256sum /media/usb/evidence/disk.img
# Must match the hash recorded by dc3dd

# Log files (copy before they rotate)
cp -r /var/log/ /media/usb/evidence/logs/
# Windows: wevtutil epl Security security.evtx
# Windows: wevtutil epl System system.evtx

# Installed packages / software (baseline comparison)
dpkg -l > /media/usb/evidence/installed_packages.txt
# Windows: Get-WmiObject Win32_Product > installed_software.txt

4. Chain of Custody

The chain of custody is the documented record of who had the evidence, when, and what they did with it. It is what stands between your evidence and a defence lawyer who argues "the evidence could have been modified."

4.1 Required Fields for Every Evidence Item

4.2 The Hash is the Proof of Integrity

The hash value is your cryptographic guarantee that the evidence has not been modified since collection. If the SHA-256 of the disk image today matches the SHA-256 recorded at collection time, the image is authentic.

# At collection time — record this
sha256sum disk.img > disk.img.sha256
cat disk.img.sha256
# a3f9b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1  disk.img

# At any later time — verify
sha256sum -c disk.img.sha256
# disk.img: OK   ← evidence is unmodified
# disk.img: FAILED ← evidence has been tampered with

4.3 Write-Blockers

A hardware write-blocker is a device that passes read commands through to the disk but intercepts and blocks any write commands. It is the physical guarantee that your forensic image process did not modify the original evidence.

[Original disk] → [Hardware write-blocker] → [Forensic workstation]
                         ↑
             Blocks ALL write operations
             to the original disk

Software write-blockers (registry settings, mount flags) exist but are not accepted in all jurisdictions. Use hardware write-blockers for any evidence that may go to court.

5. Common Mistakes

Mistake 1: Powering off first, collecting evidence later. This is the single most common and most damaging mistake in IR. Power-off destroys RAM. RAM contains credentials, malware, and network connections. Always collect volatile evidence before any power-off.

Mistake 2: Writing forensic output to the local disk. Every write modifies timestamps and may overwrite unallocated space that contains deleted attacker files. Use external media or a network share.

Mistake 3: No hash recorded at collection time. If you do not record the hash when you collect the evidence, you cannot prove later that it was not modified. Hash everything, immediately, at collection time.

Mistake 4: Incomplete chain of custody for even one transfer. A gap in the chain of custody — a handoff with no signature, a missing date — can make evidence inadmissible in legal proceedings.

6. Practice Exercises

1. You arrive at a compromised Linux server. It is still running. List the first six commands you run, in the correct order, and explain why each comes before the next.

2. An analyst powered off a compromised server before imaging it "to stop the attack." What evidence was destroyed? What should they have done instead?

3. You have collected a disk image. The original SHA-256 at collection was a3f9b2.... You check it three weeks later and get b4c8d1.... What does this tell you? What are the possible explanations?

7. Lab

Assessment mode: quiz

Scenario-based quiz: 6 questions on order of volatility, evidence collection procedure, and chain of custody fields. You must also identify the errors in two described evidence collection procedures.

8. Framework Alignment

9. Further Reading

• RFC 3227 — Guidelines for Evidence Collection and Archiving (3 pages — read it all)
• SANS FOR508 — Advanced Incident Response; the memory acquisition section is publicly summarised online
• Volatility Foundation — https://volatilityfoundation.org — Memory forensics tool and methodology
• LiME (Linux Memory Extractor) — https://github.com/504ensicsLabs/LiME — Open-source RAM acquisition for Linux

["List the order of volatility from most to least ephemeral and explain why RAM must be acquired before disk imaging", "Execute a live response collection sequence on a Linux system using five shell commands that capture processes, network state, and open files to external media without writing to the local disk", "Complete a chain of custody form for a described evidence item and verify a SHA-256 hash to confirm that an image has not been modified since collection"]

Prerequisites → Why this matters (evidence disappears analogy) → Order of volatility (ranked list with rationale) → Live response commands (Linux + Windows with annotations) → Memory acquisition importance → Non-volatile evidence collection (disk imaging, logs) → Chain of custody (required fields, hash as proof, write-blockers) → Common mistakes → Practice exercises → Quiz lab → Framework alignment → Further reading