Linux Forensics Fundamentals

Forensics answers one question: what actually happened? Files remember much more than their contents — this note covers the story hidden in metadata, why deletion is a lie, and how to handle evidence properly.

File timestamps: MACB

Every file carries four timestamps, visible with stat:

stat my-script.sh
 
# Output
  File: my-script.sh
  Size: 128        Modify: 2026-11-06 10:00:12.000000000 +0100
                   Access: 2026-11-06 10:05:41.000000000 +0100
                   Change: 2026-11-06 10:00:12.000000000 +0100
                   Birth:  2026-11-01 09:12:03.000000000 +0100

• Modify (M) — contents last written
• Access (A) — contents last read (with relatime, often only coarsely updated)
• Change (C) — metadata (owner, permissions, name) last changed — note that chmod/chown update it, as described in Permissions & Ownership
• Birth (B) — file creation, on filesystems that support it

Caveats that matter during an investigation:

• touch -a / touch -m can rewrite A and M — timestamps are evidence, not proof
• C cannot be set arbitrarily by users, which makes it the most trustworthy of the four
• the sequence of MACB changes across many files reconstructs an attack timeline surprisingly well

Deleted ≠ gone

Deleting a file is just a promise: the filesystem marks the blocks as free but writes nothing over them until they’re reused. Until then:

• tools like extundelete or TestDisk/PhotoRec can carve the old contents back
• journaling filesystems (ext4) keep extra traces of recent changes
• this is exactly why the plan’s “delete and recover” exercise is eye-opening — and why stolen laptops with “deleted” files are a recurring news story

Handling evidence the right way

1. Never work on the live disk — boot read-only (mount -o ro) or from a live USB
2. Image first, study later: dd if=/dev/sda of=evidence.img bs=4M (or dc3dd for court-grade hashing), then hash the image with sha256sum to prove it never changed
3. Chain of custody: a written log of who handled the evidence, when, and why. Boring paperwork that decides whether the findings hold up anywhere serious
4. Everything else — timestamps, undelete, log correlation — happens on the image, never the original (Logs & Auditing helps correlate times across sources)

The same principles scale down to everyday work: a corrupted production file, a suspicious cron entry, a “we never shipped this” commit — all small forensics cases.