Log wipers get caught by the sound of the wipe

The scenario is fictional (RFC 5737 IPs). Windows/auditd details are from the book and not sandbox-tested.

In a Holmes story, the dog that didn't bark is the clue. In logs, what is missing is evidence.

What you'll learn

Three systems for detecting log deletion
The Windows and Linux "sounds of deletion"
A tested one-liner for silence (gap) detection
Why "no logs" must be reported as unverified

The story at a glance

Time	What happened
02:40	`history -c`, `systemctl stop auditd` on `web03`
After	No local logs recorded
Investigation	Local `auth.log` empty from 02:00 to 02:40

Three systems

System	Look for
Deletion event	Windows Security 1102, System 104; auditd `DAEMON_END`/`DAEMON_ABORT`/`CONFIG_CHANGE`
Deletion command	Sysmon 1 `wevtutil cl Security`, `Clear-EventLog`; EXECVE `systemctl stop auditd`, `rm .bash_history`, `unset HISTFILE`
Silence	heartbeat stops, Record ID gaps, time gaps

Silence detector

awk '{split($3,t,":");s=t[1]*3600+t[2]*60+t[3];
      if(NR>1 && s-p>300) printf "GAP %s -> %s (%d min)\n", pt,$3,(s-p)/60;
      p=s; pt=$3}' collector.log

On a synthetic log it prints GAP 02:04:10 -> 02:38:10 (34 min) and nothing for a clean log. (Single-day logs only.)

Not every gap is an attack

Planned archiving (known admin, bastion, change record), reboots/outages (other systems show downtime), or an attacker (unrelated account like svc_web at 02:40). Judge by who, when, from where.