CoursesAdvanced Linux securityForensics & incident response

Linux forensic artifacts

Where the evidence actually lives.

Advanced14 min · lesson 16 of 17

Investigating a Linux intrusion is knowing where the evidence lives and reading it in the right order. Once volatile state is captured, the disk holds a rich record of what happened — if you know where to look. The major sources are the logs (auth, journal, application, and shell history), the filesystem timeline (when files were created and modified), the persistence locations you enumerated earlier, and per-user traces. Each answers a different question: who logged in, what ran, what was changed, and how the attacker planned to return.

Where Linux evidence lives
activity & access
/var/log/auth.log, secure
logins, sudo, SSH
journald
service + system events
last, lastb, wtmp/btmp
login history
~/.bash_history
commands run (if not cleared)
change & persistence
file timestamps (MAC times)
a timeline of activity
cron, systemd, authorized_keys
how they persist
AIDE / integrity baseline
what changed vs known-good
Cross-reference sources: a login in auth.log, a command in history, a file created at that timestamp, a persistence entry — the timeline connects them.

Build a timeline

The core forensic technique is timelining: every file has timestamps (modified, accessed, changed — the MAC times), and combining those with log entries produces a chronological reconstruction of the intrusion. You anchor on a known event — the detection that fired, a suspicious login — and pivot outward: what files changed around that time, what commands ran, what connected. Tools like the Sleuth Kit build a filesystem timeline; combined with the off-host log store (which the attacker could not edit) you assemble what happened, in order, even when the local logs were tampered with.

terminal
# anchor and expand: what happened around the suspicious login at 03:14?
$ grep "03:1[0-9]" /var/log/auth.log # logins/sudo in that window
$ last -aFi | head # login history with IPs
$ find / -newermt "2026-07-03 03:10" ! -newermt "2026-07-03 03:20" 2>/dev/null # files changed then
$ cat /home/*/.bash_history 2>/dev/null # commands (attackers often clear this — its absence is a clue)

Trust off-host evidence most

The evidence hierarchy on a compromised host is clear: off-host telemetry (the shipped audit/eBPF events, central logs, network sensor data) is the most trustworthy because the attacker could not reach it; a memory image captured early is next; disk artifacts are valuable but potentially tampered; and the live host’s own tool output is least trustworthy. Weight your conclusions accordingly, corroborate local findings against the off-host record, and remember that the absence of expected evidence — a cleared history, a gap in the logs — is itself a finding pointing at deliberate cleanup.

Missing evidence is evidence
Attackers clean up — they clear .bash_history, delete their tools, and edit or truncate local logs to hide their tracks. So a suspiciously empty history, a log with a gap right around the incident window, or a modified system binary is not "nothing to see" — it is a strong indicator of a capable adversary who was there. This is exactly why off-host logging matters: the central store has the record the attacker deleted locally. Read the gaps, and trust the evidence they could not reach.