Preserve evidence in order of volatility, prove integrity with hashes and chain of custody, and build a UTC timeline.
Why it matters
During an incident, people want answers fast: how did they get in, what did they touch, are they still here? Digital forensics answers those questions from evidence, in a way that holds up later in front of management, insurers, regulators or a court. The two skills every responder needs first are preserving evidence without changing it and building a timeline of what happened.
Principles
- Preserve before you analyse. Work on copies, never the original.
- Collect the most volatile data first. Some evidence disappears when a machine is rebooted or even when time passes.
- Prove integrity. Record cryptographic hashes (SHA-256) of everything you collect, so you can show it has not changed.
- Keep a chain of custody. Record who collected each item, when, how, where it was stored and every time it changed hands.
- Document everything with UTC timestamps, including commands you ran.
Serious cases (anything that might involve law enforcement, employee discipline or litigation) need trained forensic examiners and legal advice from the start. What you learn here is the first-responder level.
Order of volatility
RFC 3227, a long-standing guideline for evidence collection, lists data from most to least volatile. A simplified version:
| Order | Evidence | Why it is fragile |
|---|---|---|
| 1 | CPU registers, cache | Changes every instant |
| 2 | Memory (RAM): running processes, network connections, logged-in users | Lost at power-off; malware may live only here |
| 3 | Temporary file systems | Cleared at reboot |
| 4 | Disk | Survives reboot, but changes as the system runs |
| 5 | Remote logs and monitoring data | Rotated or overwritten over time |
| 6 | Physical configuration, network topology | Changes slowly |
| 7 | Archives and backups | Most stable |
This is why "just reboot it" or "pull the plug and reimage" can destroy key evidence. Whether to keep a compromised machine running is a judgement call: isolating it from the network (not powering it off) often preserves memory while stopping the spread.
Collecting from a live Linux system
A first responder's quick capture might look like this. Output goes to an external drive or a network share, never to the suspect disk, and every command is noted.
OUT=/mnt/evidence/web02-2026-10-23
date -u > $OUT/00-time.txt
{ uname -a; uptime; } > $OUT/01-system.txt
{ who -a; last -n 50; } > $OUT/02-users.txt
ps auxww > $OUT/03-processes.txt
ss -tunap > $OUT/04-connections.txt
sudo cp /var/log/auth.log* "$OUT"/
sha256sum "$OUT"/* > "$OUT"/hashes.sha256
Full memory captures and disk images use dedicated tools (for example LiME or AVML for Linux memory, and write blockers plus imaging tools for disks). The open-source Autopsy platform and the Volatility framework are common for analysis.
Building a timeline
A timeline puts every relevant event from every source in time order. It turns scattered clues into a story.
Sources include authentication logs, web server logs, shell history, file system timestamps, SIEM alerts, EDR events and cloud audit logs. File systems record several times per file, often summarised as MAC(B): Modified (content changed), Accessed, Changed (metadata changed) and Born (created). On Linux, stat file shows them.
Tools like plaso (log2timeline) build "super timelines" from hundreds of artefact types automatically. For small cases a spreadsheet works well, with columns time_utc, source, host, event and notes.
Worked example
From a web server, a responder collects auth logs, the web access log, stat output for an odd file and the www-data user's activity:
| time_utc | source | event |
|---|---|---|
| 2026-10-22 23:58:10 | web access log | POST /upload.php from 203.0.113.50 with file img.php |
| 2026-10-22 23:58:11 | file system (Born) | /var/www/html/uploads/img.php created |
| 2026-10-22 23:59:02 | web access log | GET /uploads/img.php?cmd=id from 203.0.113.50 |
| 2026-10-23 00:03:40 | web access log | GET /uploads/img.php?cmd=wget... downloading a script |
| 2026-10-23 00:04:05 | auth.log | new user support2 added |
| 2026-10-23 00:06:31 | auth.log | SSH login as support2 from 203.0.113.50 |
The story is now clear: an unrestricted file upload let the attacker place a web shell, run commands, create a backdoor account and log in over SSH. The timeline also tells responders what to fix (the upload form), what to remove (the shell and the account) and where to look next (anything support2 did).
Common pitfalls
- Time zones. Logs from different systems may use local time, UTC or no zone at all. Convert everything to UTC and note the original.
- Clock drift. A machine whose clock is five minutes off will scramble the order; check against NTP.
- Changing the evidence. Opening files on the suspect system updates access times; installing tools on it overwrites deleted data. Use trusted tools from external media.
- Forgetting the hashes. Without them you cannot prove your copy matches what you collected.
Quick recap
- Preserve first, collect in order of volatility, hash everything and keep a chain of custody.
- Isolating a host often beats powering it off, because memory holds evidence.
- A timeline in UTC, combining logs and file timestamps, turns clues into a story and tells you what to fix.
- Serious cases need trained examiners and legal advice.
Try it
Open the Do tab to collect evidence and build a timeline on your own lab VM.