Identifying Log Tampering Through Clearance Events and Sequence Gap Analysis

Why This Matters

Log tampering is the attacker's attempt to erase the forensic record of their presence. During post-incident analysis of the 2021 Colonial Pipeline breach, investigators found that attackers had cleared Windows event logs on lateral movement hosts to delay attribution. On Linux systems, attackers routinely truncate auth.log and wtmp to remove SSH login records. An analyst who accepts a quiet log as evidence of a quiet system — rather than evidence of tampering — will produce a fundamentally flawed incident timeline. Detecting the absence of expected log data is as important as analysing the data that remains.

Core Concept

Log tampering covers several attacker techniques: complete log clearing, selective entry deletion, timestamp modification, and log file truncation. Each leaves a characteristic forensic signature.

Windows log clearing generates its own event: Event 1102 ("The audit log was cleared") in the Security log, and Event 104 in the System log. These events include the account name and time of the clearing action — even if the rest of the log content is gone. This self-documenting property means a cleared Windows log is detectable as long as the SIEM forwarded events before clearing occurred.

Linux log truncation using > /var/log/auth.log or truncate -s 0 sets the file size to zero without deleting the inode. The file's ctime (inode change time) is updated. If the ctime post-dates the log's own earliest entry, truncation is confirmed. wevtutil cl Security clears Windows Security log.

Missing sequence numbers in syslog: many syslog implementations (rsyslog with imjournal, systemd-journald) assign monotonically increasing sequence numbers. A gap in the sequence — e.g., entries jump from 14823 to 15100 — indicates deleted entries.

Timestamp gaps: legitimate system logs rarely have multi-hour gaps during business hours. A gap immediately preceding or following a known attacker action window is suspicious.

Technical Deep-Dive

# Detect Windows log clearing events (exported to JSON via wevtutil)
jq '.[] | select(.EventID == 1102 or .EventID == 104)
  | {time: .TimeCreated, user: .SubjectUserName, log: .Channel}' 
  system_security.json

# Linux: compare file size to expected minimum
stat /var/log/auth.log
# Size: 0 → truncated; check ctime vs mtime

# Check inode ctime (change time) — cannot be user-modified easily
stat -c "%y %z %n" /var/log/auth.log
# %y = mtime, %z = ctime

# Detect gaps in journald sequence numbers
journalctl --output=export | grep __SEQNUM 
  | awk -F= '{n=$2; if(prev && n-prev>1) print "GAP: "prev" -> "n; prev=n}'

# Linux: detect truncation via ctime newer than last log entry
CTIME=$(stat -c "%Z" /var/log/auth.log)
LAST_ENTRY=$(date -d "$(tail -1 /var/log/auth.log | awk '{print $1,$2,$3}')" +%s 2>/dev/null)
if [ -n "$LAST_ENTRY" ] && [ "$CTIME" -gt "$LAST_ENTRY" ]; then
  echo "POSSIBLE TRUNCATION: ctime ($CTIME) > last entry time ($LAST_ENTRY)"
fi

-- Splunk: detect Event 1102 (security log cleared) across all Windows hosts
index=wineventlog EventCode=1102
| table _time ComputerName SubjectUserName SubjectDomainName
| sort _time

-- Splunk: detect suspicious gaps in log ingestion from a host (no events for >2 hrs during business hours)
index=wineventlog
| bucket _time span=1h
| stats count BY _time ComputerName
| where count == 0 AND date_hour >= 8 AND date_hour <= 18

Analytical Methodology

1. Begin every investigation by checking for Event 1102 and Event 104 on all hosts in scope. If present, note the clearing account, timestamp, and whether SIEM had forwarded events before the clear occurred.
2. Check SIEM ingestion gaps: query for each in-scope host and look for time windows with zero events during expected business hours. A two-hour gap on a Windows host during the working day warrants explanation.
3. On Linux hosts, run stat on key log files: /var/log/auth.log, /var/log/syslog, /var/log/secure, /var/run/utmp, /var/log/wtmp. File size of zero or ctime substantially newer than the last log entry timestamps indicates truncation.
4. If systemd-journald is used, export journal entries and check __SEQNUM for gaps. Non-contiguous sequence numbers indicate deleted journal entries (journalctl --verify also reports integrity failures).
5. Cross-reference gaps in local logs against SIEM-forwarded copies. If the SIEM has events for a period that the local log does not, the local log was tampered after SIEM forwarding — SIEM becomes the authoritative record.
6. Check wtmp and btmp (binary login records) with last and lastb. Truncated or missing records for known-active accounts during the incident window confirm log clearing.
7. Look for the clearing tool in process logs (Sysmon Event 1 or auditd execve): wevtutil, Clear-EventLog, bash redirection operators (> /var/log/), or shred. Their presence in process history corroborates tampering.
8. Document all detected gaps and anomalies explicitly in the incident report. Acknowledge what cannot be known due to tampering; estimate the affected window using SIEM-side forwarding timestamps as brackets.

Common Analytical Errors

• Accepting zero log size as normal: Administrators sometimes rotate logs and start fresh. Check logrotate configuration and scheduled tasks to distinguish planned rotation from attacker truncation. Rotation creates a timestamped rotated file (e.g., auth.log.1); truncation does not.
• Missing Event 1102 because the Security log itself was cleared: If the SIEM did not forward Event 1102 before the log was cleared, the clearing event is lost. Check the SIEM's last received event timestamp for that host — a sudden stop followed by a large gap is itself evidence.
• Not checking wtmp/utmp on Linux: auth.log truncation is frequently caught, but attackers also edit binary login records using utmpdump and utmpset. Always verify last output against auth.log entries for consistency.
• Forgetting Windows System log (Event 104): Analysts often monitor only the Security log. Event 104 (System log cleared) in the System channel also signals attacker activity and is frequently overlooked.

NICE Framework Alignment

Further Reading

• SANS: "Detecting Malicious Log Clearing" (DFIR blog)
• Microsoft Docs: Windows Security Event 1102 and System Event 104 — field definitions
• rsyslog documentation: imjournal module — sequence number tracking and gap detection
• Brian Carrier, "File System Forensic Analysis" — inode timestamps and ctime semantics (Chapter 5)
• MITRE ATT&CK T1070.001: Clear Windows Event Logs — detection and mitigation controls