Forensics basics

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 timelineEvery relevant event from every source placed in time order, in UTC, to turn clues into a story. of what happened.

Principles

1. Preserve before you analyse. Work on copies, never the original.
2. Collect the most volatile data first. Some evidence disappears when a machine is rebooted or even when time passes.
3. Prove integrity. Record cryptographic hashes (SHA-256A cryptographic hash recorded for each collected item so you can show later that it has not changed.) of everything you collect, so you can show it has not changed.
4. Keep a chain of custodyA record of who collected each evidence item, when, how, where it was stored and every time it changed hands.. Record who collected each item, when, how, where it was stored and every time it changed hands.
5. 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:

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)The file system times Modified, Accessed, Changed (metadata) and Born (created) used in timelines.: 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:

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 volatilityThe sequence for collecting evidence from most fragile (registers, memory) to most stable (archives and backups)., 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.