Introduction to Linux Forensics

Linux powers most of the internet. Web servers, cloud infrastructure, Docker containers, Kubernetes clusters, IoT devices, and increasingly laptops run on it. When one of those systems is compromised, or a crime is committed using one, a forensic examiner has to answer three questions: what happened, when, and who did it. Linux forensics is the discipline of answering those questions from the evidence a Linux system leaves behind.

Why Linux forensics?

For a long time the digital forensics world revolved around Windows. But the reality of modern deployments is that Linux is everywhere:

• Over 90% of public cloud workloads run on Linux-based infrastructure.
• Servers under attack are almost always Linux — from SSH brute-force to web app exploits.
• Attackers frequently land on Linux boxes and pivot through them.
• Forensic challenges and CTFs routinely use Linux artifacts as the target.

The good news for examiners is that Linux is unusually transparent. Most services log by default, the filesystem records metadata you can inspect without proprietary tools, and almost every forensic tool that exists for Linux is open source — which means you can read the source of both the tool and the code being analyzed.

What evidence does Linux produce?

A running Linux system is constantly writing evidence. The main categories are:

Add to this the artifacts applications create: browser history, shell command history, editor swap files, package-manager logs, thumbnails, trash directories, and the many side-effects of the "everything is a file" design. Each one is a breadcrumb.

Core principles

Every decision in an investigation should be guided by a handful of principles:

1. Preserve the evidence

The single most important rule. A forensics workstation should never have the suspect drive auto-mounted, and analysis must happen on a copy (an image), never the original. Even reading a filesystem mounts and modifies it.

2. Document everything

Every command you run, every file you open, every hash you compute must be recorded. If it isn't written down, it didn't happen — and your report will be torn apart by whoever opposes you in court.

3. Work from copy, image to evidence

Use dd or dcfldd to image the evidence drive to a forensic image, verify the hash (SHA-256 / MD5) matches, and only then analyze the image.

4. Volatility first

Evidence has a lifetime. RAM vanishes the moment you power down the machine. Follow the order of volatility: memory, network state, live processes, temporary files, then disk.

The chain of custody

If a case reaches court, you must be able to prove that the evidence you analyze is the evidence that was seized, unchanged. That means:

1. Seal and label every piece of hardware when you seize it.
2. Record who handled it and when, in a custody log.
3. Compute and store hashes at each step: on seizure, on imaging, on each copy.
4. Work only from verified images and keep the original sealed.

# on the live target (as root), hash the drive BEFORE imaging
sha256sum /dev/sda > original.sha256

# on the forensic workstation, hash the image AFTER imaging
sha256sum -c original.sha256   # expects path match

Where to start

A practical investigation on a Linux box follows a natural sequence, each stage covered elsewhere on this site:

1. Decide live or dead acquisition and capture memory if needed.
2. Image the disk and build a timeline.
3. Examine system logs for authentication and service events.
4. Dig through user and system artifacts.
5. Recover deleted files and carve unallocated space.
6. Correlate everything into a timeline and write the report.

← Back to home  ·  Next: Live vs. Dead Acquisition →