How to Detect Firewall Logging Gaps That Hide an Intrusion

To detect firewall logging gaps, compare what each firewall sends to your log platform against what it should send: expected event volume per hour, continuous sequence of timestamps, and agreement with independent sources such as flow data or interface counters. A silent firewall is not a quiet firewall. Attackers who reach a firewall often stop or filter its logging first, so a gap is evidence worth chasing.

Why do attackers create logging gaps?

Attackers stop logging so the actions that follow leave no record. On a firewall that means admin logins, configuration changes, new accounts and VPN sessions all happen while the log stream is off or filtered.

The FortiOS CVE-2025-61624 PEERSTITCH intrusion is a clear example. Unit 42 reported that the actor killed the logging and syslog daemons before running malicious scripts, cleared crash logs, deleted the rogue admin accounts it had used, and caused intermittent drops on the management tunnel so central consoles received less telemetry. The implant itself lived inside the logging daemon, as described in what memory-resident malware on a network appliance is.

What does a logging gap look like?

A logging gap is any period where a device should have produced records and your collector received fewer than expected or none. It shows up as missing time, a sudden drop in volume, or one log type disappearing while others continue.

Common shapes:

• Hard silence. No events at all from a device for minutes or hours.
• Selective silence. Traffic logs continue but admin, configuration or VPN event logs stop.
• Volume dip. Events keep arriving at a fraction of the normal rate.
• Clock jumps. Timestamps skip forward, or the device clock changes, so events land out of order.
• Crash markers. The logging process restarts or crashes, followed by a short gap.

Each of these can have an innocent cause, such as a WAN outage, a collector restart or a firmware upgrade. The job is to explain every one, not to assume.

How do you build a baseline for each firewall?

Start with 30 days of history from your SIEM or log collector and work out, for each firewall:

1. Average and minimum events per hour, split by log type (traffic, system, admin or configuration, VPN).
2. The longest normal interval between two events of each type.
3. Normal daily and weekly patterns, such as quiet weekends at branch sites.

Store these as thresholds. A branch firewall that never goes more than five minutes without a traffic log should alert after fifteen. An HQ cluster with constant VPN traffic can use a tighter window.

How do you detect firewall logging gaps in practice?

Most SIEM platforms have a "source stopped reporting" or "silent host" rule. Turn it on for every firewall, then add rules the default does not cover:

• Per log type, not just per device. Alert when admin or system events stop while traffic events continue. That pattern points to selective filtering.
• Volume ratio. Alert when hourly volume falls below a set share of the baseline for that hour of the week.
• Logging service events. Alert on any log that the logging or syslog service restarted, and on configuration changes to log settings or log destinations.
• Management tunnel drops. If firewalls report to a central manager, alert on repeated disconnects from the same device.

Route these alerts to the network team and the security team. A gap that nobody owns never gets explained.

How do you cross-check with independent sources?

A firewall's own logs cannot prove the firewall was honest. Compare them against data the firewall does not control:

• NetFlow or IPFIX from upstream routers or switches. If flow data shows VPN traffic to the firewall during a gap, sessions were happening without records.
• Interface counters polled over SNMP. Bytes moving through an interface with no matching traffic logs is a mismatch.
• Authentication servers. RADIUS, LDAP or identity provider logs show admin and VPN authentications that the firewall should also have logged.
• Configuration backups. Pull configurations on a schedule from a separate system and diff them. New admins, VPN groups or automation scripts that appear and disappear between backups are a red flag, even if no log mentions them.

What should you do when you find a gap?

Treat an unexplained gap as a possible intrusion window:

1. Record the exact start and end times and which log types were affected.
2. Check change tickets, outages and maintenance windows for that period.
3. Pull authentication logs, flow data and configuration diffs covering the window.
4. Review admin accounts, VPN groups and scheduled or automation scripts on the device, including revision history if the platform keeps it.
5. Look for crash records in logging or VPN processes on the device.
6. If anything remains unexplained, escalate to incident response and preserve the device state before rebooting.

If the firewall is centrally managed, check the manager too. An attacker who reached the management platform can reach every device it manages, which is covered in why a firewall manager compromise exposes every device.

How do you make gaps harder to create?

Send firewall logs to at least two destinations, one of them outside the firewall's management domain, so a single change cannot silence both. Restrict who can change log settings, alert on every change, and keep management interfaces off the internet. Our guide on restricting firewall management access to a jump box covers that last step.