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

Three systems

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.

Defense

Real-time forwarding (WEF, rsyslog TCP+TLS), auditd -e 2, chattr +a, top-priority alerts on 1102 and DAEMON_END.

Reporting

"No logs" is not "safe". Write: "02:04-02:38 not available; activity in that window is unverified."

Next: Windows. A Word document and a 40-second clock.

Adapted from chapter 28 of my Japanese book on server defense.