Digital forensics
Evidence handling, chain of custody, the order of volatility, and disk, memory and network forensics.
~4 min read
What forensics is for
Digital forensics is the identification, preservation, analysis and presentation of digital evidence in a way that stands up to a court, a tribunal, or an internal disciplinary process. The discipline exists because evidence is fragile and easily challenged: do it sloppily and a guilty party walks, or an innocent one is wrongly blamed. Even in incident response where no prosecution is planned, forensic rigour answers the questions that matter: what did the attacker do, how far did they get, what did they take?
The guiding principle (from the Forensic Science Regulator and ACPO/UK practice): wherever possible, don't alter the original evidence, and where you must, be able to explain exactly what you did and why.
Chain of custody
Chain of custody is the documented, unbroken record of who handled a piece of evidence, when, why, and what they did to it, from seizure to court. A gap lets the other side argue the evidence was tampered with or mixed up, and it can be thrown out. In practice it means labelled evidence bags, signed handover logs, tamper-evident storage, and a record for every access.
Integrity via hashing underpins this: at acquisition you compute a cryptographic hash (e.g. SHA-256) of the evidence. Anyone can later re-hash the copy and confirm it matches, proving it hasn't changed since seizure. This is the practical, real-world use of the hash properties from the cryptography topic. A write blocker (hardware or software) lets you read a drive without the act of examining it writing anything back, preserving the original.
Order of volatility
Evidence decays at different rates, and you should collect the most fragile first. The order of volatility, most to least volatile:
- CPU registers and cache: gone in moments.
- RAM (memory): running processes, encryption keys, network connections, malware that never touched disk. Lost the instant power is cut.
- Network state: active connections, ARP cache, routing tables.
- Running processes / temporary files.
- Disk: the hard drive; relatively stable.
- Logs and archived/backup media: most durable, often off-site.
The headline consequence: pulling the plug destroys memory evidence. That clashes with the IR instinct to isolate a machine fast, so it's a deliberate decision. For a fileless-malware or ransomware case, a live memory capture before shutdown can be the only place the key evidence exists. This trade-off (live acquisition vs immediate containment) is a classic exam discussion point.
Disk forensics
Analysis of storage media. Key ideas:
- Forensic imaging: create a bit-for-bit copy (an image) of the drive and work on the copy, never the original. Hash both to prove they match.
- Deleted files: "deleting" usually just unlinks a file and marks its space free; the data persists until overwritten, so file carving can recover it from unallocated space. Slack space (the unused remainder of an allocated block) can also hold fragments of old data.
- Metadata and timelines: filesystem timestamps (created/modified/accessed, known as "MAC times") let an examiner build a timeline of activity.
- Anti-forensics: attackers wipe logs, alter timestamps (timestomping), or use full-disk encryption (which is exactly why a live capture, while the disk is unlocked and the key is in RAM, can matter).
Tools you might hear named: Autopsy/The Sleuth Kit, FTK, EnCase.
Memory forensics
Analysing a RAM capture reveals what disk analysis can't: running processes (including hidden ones a rootkit conceals from the live OS), network connections, command history, injected code, and encryption keys and plaintext passwords sitting in memory. Against fileless and in-memory malware it is often the only thing that works. Volatility is the standard analysis framework.
Network forensics
Reconstructing events from network data:
- Full packet capture (PCAP, via Wireshark/tcpdump): the actual traffic, allowing reconstruction of what was sent, including data exfiltration and C2 communication.
- Flow data (NetFlow): metadata about connections (who talked to whom, when, how much) without full content; lighter to keep at scale and often enough to spot exfiltration or beaconing.
- Logs: firewall, proxy, DNS and server logs that place activity in time.
The catch: you can only analyse what you captured, so network forensics depends entirely on having logging and capture in place before the incident. That loops back to Preparation and to OWASP's logging/alerting category.
Log analysis and the bigger picture
Most investigations are, in the end, log analysis: correlating events across systems to reconstruct the attacker's path. A SIEM centralises logs so this correlation is possible, and timestamps must be synchronised (via NTP) across systems or the timeline falls apart. Tampered or absent logs are themselves a finding, and the reason logs should be shipped off-box where an attacker can't edit them.
Quick recall
- Forensics preserves and analyses evidence defensibly; don't alter the original, and document anything you must do to it.
- Chain of custody = unbroken who/when/why/what record; broken chain = inadmissible. Hashing proves integrity; write blockers prevent accidental writes.
- Order of volatility: registers/cache → RAM → network state → processes → disk → backups. Pulling power destroys RAM evidence, so live capture vs fast containment is a real trade-off.
- Disk: image the drive, work on the copy; deleted data survives in unallocated/slack space (file carving). Memory: captures running processes, keys, fileless malware (Volatility).
- Network forensics needs capture in place beforehand (PCAP vs NetFlow). Sync clocks with NTP; ship logs off-box.