During IR you find a suspicious gap in the authentication logs. What do you conclude and do?

A clean, unexplained gap in authentication logs during an active incident is itself a piece of evidence — and the most dangerous mistake is to read it as "nothing happened." Clearing or selectively editing logs is a documented anti-forensics technique (MITRE ATT&CK T1070, Indicator Removal). Attackers do it precisely so a less experienced responder concludes the window was quiet.

The correct conclusion and action

Treat the gap as a possible integrity event, not a fact about activity. Then:

• Corroborate with sources the attacker likely couldn't reach. Centralized/forwarded logs (already off the host), EDR telemetry, network flow data, and upstream device logs (firewall, VPN, identity provider) frequently still show what local logs no longer do.
• Hunt for tampering artifacts. On Linux, journal rotation anomalies, gaps that align with attacker activity elsewhere, or inode/timestamp inconsistencies can betray a wipe even when the entries are gone.
• Document the integrity gap as an explicit finding, with the time window and what corroborating evidence does or doesn't fill it. This matters for both scoping and admissibility.

Why the distractors fail

• "The server was idle" assumes the missing log faithfully reflects reality — but the attacker may control exactly that source. Absence of evidence is not evidence of absence.
• "Trust the gap as proof nothing happened" is the conclusion the attacker is engineering; it's the trap, not the answer.
• "Delete the rest of the logs to tidy up" destroys remaining evidence and could constitute spoliation — catastrophic for an investigation and any legal case.

What the interviewer is probing

Whether you instinctively distrust convenient gaps, reach for independent, tamper-resistant telemetry, and preserve rather than destroy evidence — the senior judgment that separates "the logs say nothing happened" from "the logs were made to say nothing happened."