Skip to content
Reverse Engineering
Anti-Forensicintermediate

Syslog / Journald Tampering

Intruders delete or truncate /var/log and journald files to hide activity, but sequence numbers, forwarders, and inodes expose the cut.

On Linux, the record of an intrusion lives in /var/log (auth.log, syslog, secure, messages) and, on systemd hosts, in the binary journal under /var/log/journal. An attacker who installed a rootkit, added an SSH key, or ran a miner wants those records gone. Tampering ranges from the blunt — rm -rf /var/log/* — to the surgical: truncating a file to drop the noisy lines, or selectively editing journald to remove specific entries while leaving the file plausibly intact.

The approach matters because the cleanup methods leave very different residue. A truncation resets a file's size and modification time; a full delete breaks the inode and link count; a selective edit of the journal corrupts its internal hashing. Each leaves a defender a different thread to pull, and on most real systems a copy of the deleted data exists somewhere the attacker never reached.

How it works

The common patterns truncate text logs in place and force a fresh journal:

bash
# Truncate auth.log to hide a session without deleting the file
: > /var/log/auth.log          # or: truncate -s 0 /var/log/auth.log

# Drop journald entries and rotate to a clean file
journalctl --rotate && journalctl --vacuum-time=1s

Redirecting : (or truncate) zeroes a text log while keeping the inode, which looks less anomalous than an rm. For the binary journal, --vacuum-time/--vacuum-size and --rotate discard old journal files; cruder actors simply rm the *.journal files or overwrite individual entries, which breaks the per-file forward-secure sealing (FSS) hash chain.

Detection & analysis

Static analysis:

  • For text logs, look for truncation tells: a file whose size is far below its rotation threshold, a modification time that postdates the last visible entry, or a logrotate sequence with a missing .1/.gz archive. Compare against the auth.log/secure timeline expected from wtmp/btmp/lastlog, which are separate binary files attackers often forget.
  • For journald, run journalctl --verify to detect a broken FSS hash chain, and inspect each *.journal file's Head/Tail sequence numbers — monotonic sequence numbers with a gap, or a journal file whose boot ID does not match recorded boots, indicates removed entries.
  • Recover deleted journals and logs from /var/log/journal/*/system@*.journal~ rotated remnants, the filesystem journal, and unallocated space. ext4magic, extundelete, and raw carving for the journal LPKSHHRH magic header frequently restore vacuumed files; rotated .gz archives often survive a live rm in shadow backups or on a separate /var snapshot.

Dynamic analysis:

  • The strongest recovery source is remote forwarding: entries shipped via rsyslog/syslog-ng to a SIEM or a systemd-journal-remote collector are out of the attacker's reach on the host. Reconcile the local timeline against the collector to enumerate exactly which entries were removed.
  • auditd records the tampering itself — truncate, unlink, and open for write against /var/log/* — in audit.log, which (if forwarded or on a separate volume) names the process and PID that performed the wipe.

Detection rule hint: Alert on any non-logrotate, non-rsyslogd process truncating, unlinking, or opening files under /var/log for write, and on journalctl --vacuum*/--rotate or rm of *.journal outside maintenance. Always pull the same window from your remote syslog collector and run journalctl --verify; reconstructing the removed entries from the forwarder and carving rotated journals is what re-establishes the intrusion timeline.

Votes

Comments(0)