Linux Forensics

What it is and why it matters

There is no registry on Linux and no single event log. Configuration sits in text files under /etc, accounts in /etc/passwd and /etc/shadow, logs under /var/log and the systemd journal, and the history of what a user typed in a hidden file in their home directory. This openness is a gift to the examiner, because almost everything can be read with ordinary tools, and a trap, because an attacker with root can edit the same files just as easily.

The variety is the other difficulty. A Debian server, a Red Hat workstation, an Android-based appliance and a container host are all Linux, yet they log to different places, use different package managers and may run different file systems. The examiner must identify the distribution and version first and then adjust every expectation, from the name of the authentication log to whether the journal was even persistent.

Linux forensics is most often done in incident response, on a web server that was defaced, a cloud instance that started mining cryptocurrency or a jump host whose SSH keys were stolen. The questions are the same every time. How did they get in, what did they run, what did they take and where else did they go.

Types of digital evidence

Accounts and Authentication
/etc/passwd, /etc/shadow, /etc/group and /etc/sudoers show who could log in and with what rights. The auth.log or secure log and the wtmp, btmp and lastlog binary files record successful logins, failures and sessions with source addresses.
The systemd Journal
Binary journal files under /var/log/journal when persistence is enabled, or only in /run/log/journal until reboot. They hold kernel messages, service starts and stops, sudo use and SSH activity with precise timestamps and the originating process.
Syslog Text Logs
syslog or messages, kern.log, cron logs, mail logs and application logs such as those of Apache, nginx, MySQL and PostgreSQL under /var/log, rotated and often compressed.
Shell History and Dotfiles
.bash_history, .zsh_history, .python_history and the .ssh directory with authorized_keys and known_hosts, which record commands typed and machines reached from this one.
Scheduled and Persistent Tasks
crontab files in /etc and /var/spool/cron, systemd units and timers in /etc/systemd/system, rc.local and shell profile files where attackers plant commands that survive a reboot.
File System Metadata
ext4 inodes with access, modify, change and creation times, the ext4 journal that preserves recent metadata, XFS and Btrfs equivalents and the mount options that decide whether access times are updated at all.
Audit and Security Records
auditd logs in /var/log/audit when the service is enabled, SELinux and AppArmor denial messages and package manager histories in dpkg.log, apt history or dnf.log that date every install and removal.
Live-Only State
Running processes, open files, deleted-but-open executables, network sockets and loaded kernel modules, visible only through /proc and /sys on a running system or in a memory capture.

Devices and data sources

Physical servers and workstations with ext4, XFS or Btrfs root volumes
Cloud instance disks exported as snapshots or raw images from the provider under authority
Virtual machine disks in VMDK, QCOW2 or VHDX format
Container hosts, with their image layers and writable layers under /var/lib/docker or containerd
NAS appliances, routers and set-top boxes running embedded Linux
Memory captures taken with a kernel-module or hypervisor-based tool
Centralised log servers and SIEM archives that hold copies of logs the attacker later deleted
Backups, snapshots and LVM volumes that preserve earlier states of the file system

How an examination runs

The order matters. Each step protects the one after it.

01
Identify the System
Read /etc/os-release, the kernel version and the file system types before anything else. The distribution decides where the logs are, which package manager was used and which parsers will work.
02
Preserve Volatile State First
On a live machine under authority, capture memory, then record running processes, network connections, logged-in users and mounted file systems. Save the output to external media, not to the suspect disk.
03
Acquire the Storage
Image the block devices through a write-blocker, or snapshot the cloud volume and export it. For LVM and LUKS, image the whole device and record the layout. Hash everything.
04
Mount Read-Only
Attach the image to an examination system with read-only and no-execute options, and with access time updates disabled, so that looking at the evidence does not change it.
05
Read the Logs and Accounts
Parse the journal, auth logs, wtmp and btmp, then the web, database and application logs. Match users and sessions to source addresses and to the accounts in /etc/passwd.
06
Check Persistence and Change
List cron entries, systemd units, timers, profile scripts and recently changed binaries. Compare package file hashes with the package manager's records to find modified system files.
07
Build the Timeline
Combine inode timestamps, journal and log entries, shell history and package history into one sequence. Shell history has no timestamps unless configured, so it is placed by its neighbours.
08
Report the Gaps
State which logs were missing, rotated or not persistent, which times could not be set and which findings depend on a single source.

Tools used in this discipline

Independent profiles: what each tool does, where it stops and what you need to know before using it.

Browse the full tools directory

Terminology

Inode: The file system record that holds a file's metadata and block pointers. The name lives in the directory, not in the inode, which is why a file can have several names or none.
atime, mtime, ctime and crtime: Last access, content modification, metadata change and creation times. ctime cannot be set by ordinary commands, so a file whose mtime is older than its ctime has been touched after it was written.
journald: The systemd logging service. It stores structured binary logs that are read with journalctl and may or may not survive a reboot depending on the storage setting.
wtmp, btmp and utmp: Binary files that record logins and logouts, failed logins and current sessions. They are read with last, lastb and who, and are a common target for attackers to clean.
auditd: The Linux audit daemon. When configured it records system calls, file access and commands by user, far beyond what syslog captures.
LUKS: Linux Unified Key Setup, the standard disk encryption format. Its header holds key slots protected by passphrases, and without one of them the volume is unreadable.
LVM: Logical Volume Manager, a layer that pools physical disks into volume groups and carves logical volumes from them. An image must be reassembled through LVM before the file systems are visible.
relatime and noatime: Mount options that limit or disable updates to access times. On most modern systems atime is unreliable as evidence of reading a file.
Web Shell: A script placed on a web server that lets an attacker run commands through the browser. It appears in the web root with an odd name and in the access log as repeated POST requests.

Challenges and limits

What makes it hard

Root can rewrite or delete any log, and attackers with root routinely clear wtmp, auth logs and shell history
Logs may not be persistent, as the journal on many distributions lives in memory until configured otherwise
Shell history is written only when the shell exits cleanly, carries no timestamps by default and can be disabled with one variable
Distributions differ in log names, paths and formats, and a parser for one may fail silently on another
LUKS and cloud provider encryption make the image useless without the passphrase, key file or provider cooperation
Cloud and container systems are short-lived, and evidence can vanish when an instance is terminated or a container restarted
A compromised kernel or preloaded library can lie to live tools, hiding processes and files from a responder on the box

Keeping the evidence intact

Run live commands from trusted binaries on external media and record every command with its output and time
Mount images read-only with noexec and noatime, and verify the image hash before and after the examination
Keep rotated and compressed logs with their original names and hash each file
Compare system file hashes with package manager records to show which binaries were modified
Note the system time zone and whether the hardware clock was set to UTC before interpreting any timestamp

Standards and legal considerations

NIST SP 800-86
The forensic process reference, with sections on operating system data and logs that apply directly to Linux hosts in an incident.
Read the guide
ISO/IEC 27037:2012
Collection and preservation guidance, including the handling of live systems where volatile data must be captured.
Read the guide
ISO/IEC 27043:2015
Principles and processes for incident investigation, which shape how a server breach is examined from readiness to closure.
Read the guide
CERT-In Directions 2022
The Indian requirement to keep logs for 180 days and to report incidents within six hours, which decides what logs an organisation should have kept.
Read the guide

In practice

The Web Shell in the Uploads Folder
An online store's server starts sending spam. The nginx access log shows a PHP file uploaded through an image form, then hundreds of POST requests to it from one address. The file's ctime matches the first request. Shell history for the web user is empty, but auditd recorded the commands the web server process spawned, including the download of a mailer script.
Keys Copied From a Jump Host
A company's cloud servers are accessed from an unknown address with a valid key. On the jump host, auth.log shows the developer's account logging in late at night, and .bash_history records the private key being read with cat. The known_hosts file lists every server the attacker then reached, which sets the scope of the response.
A Journal That Never Reached the Disk
An examiner expects months of journald history but finds only a few hours, because /var/log/journal was never created and the journal lived in memory. The report explains the gap, and the investigation falls back on the central syslog server, which had received the same messages.

This page is educational material, not legal advice. Laws and standards change, commence on different dates and are interpreted differently across jurisdictions. Always read the official text linked on this page and take advice from a qualified professional for a real matter.

Learn it at DFRTI

Free pages explain. These courses teach it on real devices with a mentor.

StorageDigital Storage ForensicsFile System AnalysisRead NTFS, FAT, exFAT, ext4 and APFS at the structure level and build timelines.IntermediateDCFA

NetworkNetwork & Cloud ForensicsVirtual Machine / Hypervisor ForensicsExamine VMDK, VHDX and QCOW2 disks, snapshots, ESXi logs and VM memory files.AdvancedCloud / Network

NetworkNetwork & Cloud ForensicsNetwork Traffic AnalysisRead flows, logs and packets to trace intrusions, beaconing and data theft.IntermediateDCNI

LegalFoundation & Legal CoursesBasics of Cyber ForensicsStart here. Evidence handling, imaging, hashing, chain of custody and your first analysis.BeginnerDCFA

Careers that use it

Computer Forensic Analyst

Questions people ask

Is Linux harder to examine than Windows?

Different rather than harder. The records are plain files and easy to read, but there is less of the automatic caching that gives Windows its execution artefacts. The examiner relies more on logs, timestamps and the package manager, and must know the distribution well.

Can deleted logs be recovered?

Sometimes. ext4 keeps recent metadata in its journal and the log content may survive in unallocated space, since logs are appended and rarely overwritten quickly. A central log server or a cloud logging service is a better source when one exists.

Does the shell history show everything a user typed?

No. It is written when the shell exits, it can be turned off, it has no timestamps unless HISTTIMEFORMAT was set and it belongs to one user and one shell. It is a lead, not a complete record.

What about a cloud server I cannot image physically?

Snapshot the volume through the provider under proper authority, export it and hash the export. Collect the provider's own logs as well, since they record API calls, console access and instance changes that the guest never sees.