Introduction

Linux powers the majority of the world's servers, cloud workloads, containers, IoT devices, and network appliances. Yet when a security incident occurs, many incident response teams find themselves underprepared for Linux forensics. Most IR training and tooling has historically focused on Windows, and responders who are comfortable navigating the Windows registry, event logs, and prefetch files often struggle to locate equivalent evidence sources on Linux systems.

This guide is a practical reference for incident responders investigating Linux systems. It covers the essential forensic artifacts — where they live, what they contain, how to collect them, and what they tell you about adversary activity. It is designed as a companion to our Windows Forensic Artifacts Cheatsheet, providing equivalent coverage for Linux environments.

A critical caveat before we begin: Linux is not a single operating system. It is a family of distributions with meaningful differences in default logging configurations, file locations, and available tools. This guide focuses on the most common distributions — Debian/Ubuntu and RHEL/CentOS/Fedora — but always verify the specifics of the system you are investigating. Check the distribution version, the init system (systemd vs SysV init), the logging daemon (rsyslog, syslog-ng, journald), and the filesystem type (ext4, xfs, btrfs) before making assumptions about artifact locations.

96% Of the world's top 1 million web servers run Linux. Cloud workloads, containers, and IoT devices overwhelmingly run Linux, making Linux forensic skills essential for modern IR teams.

Authentication & Access Logs

Authentication logs are typically the first artifact examined during an incident because they answer the most fundamental question: who accessed this system, when, and how?

/var/log/auth.log and /var/log/secure

On Debian-based systems (Ubuntu, Debian), authentication events are logged to /var/log/auth.log. On Red Hat-based systems (RHEL, CentOS, Fedora), the equivalent file is /var/log/secure. Both files record the same categories of events through the PAM (Pluggable Authentication Modules) subsystem:

Check rotated log files as well: /var/log/auth.log.1, /var/log/auth.log.2.gz, etc. Log rotation configuration in /etc/logrotate.conf and /etc/logrotate.d/ determines retention periods. Attackers frequently clear or truncate these logs, so a suspiciously small file size or a gap in timestamps is itself an indicator of compromise.

wtmp, btmp, and utmp

These binary login record files predate modern syslog-based logging and provide a structured record of user sessions:

SSH Artifacts

SSH is the primary remote access protocol for Linux systems, and it leaves artifacts in multiple locations:

Shell History & User Activity

Shell history is one of the most valuable forensic artifacts on a Linux system because it records the exact commands an attacker executed. It is also one of the most fragile — easily deleted, truncated, or disabled.

Command History Files

By default, Bash records command history to ~/.bash_history and Zsh to ~/.zsh_history. Check the history file for every user account, including root, service accounts, and any account with a valid shell. The following commands identify all accounts with valid login shells:

grep -v '/nologin\|/false' /etc/passwd | cut -d: -f1,6

Critical considerations for shell history forensics:

Shell Configuration and Profile Files

Shell configuration files are a common persistence vector. Examine the following files for modifications, especially recently modified entries or appended commands:

System Logs

systemd Journal

On modern Linux distributions using systemd (which is the vast majority of systems deployed in the last decade), the systemd journal is the primary logging mechanism. The journal stores log data in a binary format in /var/log/journal/ (persistent) or /run/log/journal/ (volatile, lost on reboot). Query it with journalctl:

The journal's structured format includes rich metadata — process ID, user ID, executable path, systemd unit — that traditional syslog does not capture. The json-pretty output mode exposes all available fields. Check whether the journal is configured for persistent storage: if /var/log/journal/ does not exist, journal data is stored only in the volatile /run/log/journal/ directory and is lost on reboot.

Traditional Syslog Files

Scheduled Tasks & Persistence

Persistence is the attacker's mechanism for surviving reboots, service restarts, and credential rotations. Linux offers multiple persistence vectors, each of which must be examined during an investigation.

Cron Jobs

Also check /var/log/cron (RHEL) or grep syslog for CRON entries (Debian) to see cron execution history — this shows when scheduled tasks actually ran, which is critical for establishing a timeline.

Systemd Services and Timers

Systemd provides a more modern persistence mechanism through service units and timer units:

Other Persistence Vectors

File System Artifacts

MAC Timestamps

Linux file systems track multiple timestamps for each file. On ext4 (the most common Linux file system), each file has four timestamps:

Use stat <filename> to display all available timestamps for a file. For investigations, use find to locate files modified within a timeframe of interest: find / -mtime -7 -type f (modified in the last 7 days). Combine with -not -path to exclude noisy directories like /proc, /sys, and /run.

Staging Directories and Suspicious Locations

Attackers commonly stage tools, payloads, and exfiltrated data in directories that are world-writable, infrequently monitored, or designed to be temporary:

Search for SUID/SGID binaries, which can be used for privilege escalation: find / -perm -4000 -type f 2>/dev/null. Compare results against a known-good baseline — any unexpected SUID binary is a serious finding.

Package Management Logs

Network Artifacts

Network configuration and connection artifacts reveal how the attacker communicated with the compromised system and what network modifications they made.

Process & Memory Artifacts

The /proc filesystem is a virtual filesystem that provides a window into every running process. For live system forensics, /proc is an invaluable source of information about active adversary processes.

For full memory acquisition, use LiME (Linux Memory Extractor), a loadable kernel module that acquires a raw memory dump. The dump can then be analyzed with Volatility or Rekall for deeper analysis — process listings, network connections, loaded kernel modules, and injected code that may not be visible through /proc alone. Memory acquisition should be performed as early as possible in the investigation, before any remediation actions that might terminate attacker processes.

Container-Specific Artifacts

Containers add layers of complexity to Linux forensics. The containerized process runs on the host kernel but operates in isolated namespaces, and its filesystem is a layered overlay.

Docker

Kubernetes

Quick Reference Table

The following summary maps common investigation questions to the artifacts and tools that answer them:

"In Linux forensics, the absence of an artifact is often as informative as its presence. An empty history file, a missing log, or a suspiciously recent ctime on a file that should not have changed — these negative indicators are signals that should drive your investigation, not dead ends."