Palo Alto Firewalls Have Been Under Attack Since June — Would Your Alerting Have Caught It in June, or in October?

Firewalls are the one device class most IT teams treat as set-and-forget — and per The Register's October report, that assumption is now actively dangerous. Palo Alto Networks' own threat intelligence team, Unit 42, is investigating network compromises across numerous industries, with multiple ransomware groups attacking the company's firewall OS since June. Read that timeline again: since June. Roughly four months of activity across many victim environments before it became public knowledge.

This isn't only a security story. It's an alert management story. Something was happening on those firewalls for months, and in the environments Unit 42 is investigating, detection clearly didn't arrive via a well-tuned alert — it arrived via threat intelligence research. If your monitoring would only tell you in October what started in June, the problem isn't your firewall vendor. It's your signal path.

The Problem in Depth: Green Dashboards, Four Months of Blindness

Firewalls are monitored as up/down devices — which is exactly wrong

The typical stack around a Palo Alto (or any vendor's) firewall looks like this: the RMM — NinjaOne, ConnectWise Automate, Datto — covers endpoints and servers, not firewalls. The NMS — PRTG, SolarWinds, LibreNMS — pings the firewall and graphs interface utilization. Syslog forwards to a collector or SIEM that quietly stores it. The helpdesk lives somewhere else entirely. Each tool does its narrow job; none of them watch what a firewall in distress actually does:

• Management plane CPU climbing from a ~10% baseline to a sustained 90%+
• Session table utilization trending upward for days
• Config commits at 3:14 AM outside any change window
• Authentication failures hammering the management interface
• HA sync degradation, or a lapsed subscription that silently drops threat prevention while traffic keeps flowing

None of these is "device down." An ICMP check returns green on a firewall whose management plane is being hammered, because forwarding traffic and serving management are different planes. Meanwhile, the syslog that would document all of it accumulates in a system nobody queries until something is already on fire.

Alert volume quietly destroys signal

A busy perimeter firewall produces thousands of syslog events per hour. Forward all of it to email or a generic NMS with default thresholds and you get hundreds of notifications a day. Every practitioner knows what happens next: one flapping VPN tunnel generates 60 alerts overnight; by alert 20 someone writes a filter rule; by alert 60, everything from that device is mentally classified as noise. Then the alert that matters arrives wearing the same subject line and gets archived in under a second.

This is alert fatigue, and it isn't a volume problem — it's a signal quality problem. An alert without context (which client? what changed? what does healthy look like? is this normal for a Sunday night?) forces a human to do investigation triage on every page. Humans optimize by ignoring.

Tool sprawl means nobody ever sees the whole picture

Reconstruct a realistic sequence: probing against a client's VPN in September. What does the stack see?

• NMS: a single CPU alert on fw-clientA, emailed to a shared mailbox
• RMM: nothing — no agents exist on firewalls
• Helpdesk: six tickets over two weeks — "VPN keeps dropping," "network feels slow this morning"
• SIEM: logs stored with 90-day retention, never queried without a trigger

The evidence that something is wrong exists in three systems and connects in zero of them. Why? Because these stacks accreted over a decade — the RMM was bought for patching, the NMS for uptime graphs, the SIEM was mandated by compliance, the helpdesk was chosen by the service desk manager. Each tool optimized for its own silo with a private data model, and the integrations between them amount to email forwarding.

Multiply the scenario by 40 clients for an MSP, and you understand how activity that starts in June becomes a headline in October.

What it actually costs

• Dwell time. From June to October is roughly 120 days. Every one of those days is exposure, lateral movement risk, and incident response cost.
• Quiet failures. The common version isn't dramatic: a subscription lapses, threat prevention silently stops, traffic keeps forwarding, and you find out in a quarterly review — or an incident.
• On-call burnout. A six-tech NOC covering 40 clients can easily absorb 150+ pages a week where fewer than one in ten is actionable. Mean time to acknowledge drifts from minutes to hours because nobody trusts pages anymore. Your best engineer starts interviewing somewhere that advertises a quiet pager.
• Unprovable SLAs. When monitoring data and helpdesk data live in different systems, response time starts when the user called — not when the condition began. You can't demonstrate a 15-minute MTTA if the alert went to a mailbox first.

How AlertMonitor Solves This

Alerts that carry their own investigation

AlertMonitor treats a firewall as a first-class device: SNMP, syslog, and API telemetry all land on the same object alongside its config history, patch state, and position in the network topology. An alert isn't "CPU high on 10.4.2.9." It reads: fw-dc01 (Acme Manufacturing) — management plane CPU 94% sustained 12 minutes against an 11% baseline, session count +38% over the 30-day norm, two config commits in the last hour outside change windows — with the healthy baseline attached and the topology one click away showing exactly what sits downstream. The on-call tech gets context with the page, so acknowledgment takes seconds instead of an SSH session.

Deduplication, maintenance windows, and routing that respect humans

• Smart dedup collapses a flapping tunnel into one alert with an occurrence counter and a renotify interval you choose.
• Maintenance windows suppress pages during your own Saturday change window while still logging everything, and auto-expire so nobody forgets to re-enable alerting.
• Multi-level on-call routing keeps informational signals in the dashboard, routes tier-1 actionable alerts to the primary on-call, and escalates correlated multi-signal events straight to tier-2 with the client contact looped in — with different policies for business hours and 2 AM, because a WAN failover at 14:00 and at 02:00 are not the same event.

One dataset across monitoring, helpdesk, RMM, and patching

When those "VPN keeps dropping" tickets arrive, AlertMonitor links them to the active alert on fw-dc01 automatically — the tech answering the phone sees the alert, the topology, the last config change, and the patch state in a single view. When a vendor advisory drops in October, the version-compliance report across every firewall at every client is a filtered view, not two days of SSH archaeology. And SLA reporting finally measures from detection time, because detection, alerting, and ticketing share the same clock.

The workflow, before and after

Fragmented: NMS email → shared mailbox → someone notices → SSH to the device → open a ticket in the helpdesk → copy context over → update the client → (maybe) close the loop.

AlertMonitor: correlated alert with full context → acknowledge from your phone → runbook remediation or an auto-created ticket already linked to the alert and the client → resolved, with the full timeline recorded for the post-incident review.

Teams feel this as fewer overnight pages, alerts acknowledged in minutes instead of "whenever the mailbox gets checked," and an advisory response measured in minutes of report filtering instead of days of manual version-checking.

Practical Steps You Can Take Today

1. Audit whether your firewalls are actually sending telemetry

Before you can alert on a firewall, confirm the logs are arriving. A collector that quietly stopped receiving in July tells you nothing in October.

# Verify each firewall is reaching the syslog collector.
# Assumes firewall-inventory.csv with columns: Name,Client,SyslogIP
# and a collector log file that rolls daily.
$fwList = Import-Csv .\firewall-inventory.csv
$log    = "D:\Syslog\firewall\current.log"   # adjust to your collector
foreach ($fw in $fwList) {
    $count = (Select-String -Path $log -Pattern $fw.SyslogIP -SimpleMatch).Count
    [PSCustomObject]@{
        Firewall    = $fw.Name
        Client      = $fw.Client
        EventsToday = $count
        Status      = if ($count -eq 0) { 'NO LOGS - FIX FORWARDING' } else { 'OK' }
    }
} | Sort-Object EventsToday | Format-Table -AutoSize

Zero events means blind spot number one: that firewall can degrade or go quiet and nothing in your stack changes.

2. Confirm the management plane is reachable from your monitoring collector

# From your monitoring collector: can we actually poll each firewall?
for ip in $(awk -F, 'NR>1 {print $2}' firewall-inventory.csv); do
  if timeout 4 bash -c "echo > /dev/tcp/$ip/443" 2>/dev/null; then
    echo "$ip: management interface reachable (TCP 443)"
  else
    echo "$ip: UNREACHABLE on 443 - polling and web management will fail"
  fi
done

In AlertMonitor, these checks run continuously as part of each device's health profile; this one-off sweep is how you find the devices no platform was ever able to see.

3. Watch the watcher

The classic failure mode: the log collector's disk fills, syslog stops being written, and the dashboard stays green because the collector process is still running.

#!/bin/bash
# Fail loudly if the syslog collector's disk is nearly full.
THRESHOLD=85
df -H --output=pcent,target | tail -n +2 | tr -d ' %' | while read -r pct mount; do
  if [ "$pct" -ge "$THRESHOLD" ]; then
    echo "WARNING: $mount is ${pct}% full - syslog writes may fail silently"
  fi
done

In AlertMonitor, collector disk, service state, and ingestion rate are themselves monitored — the platform pages you when the pipeline carrying your other alerts degrades.

4. Rebuild escalation around signal quality, not volume

The shape of a policy that on-call engineers don't learn to hate:

# Escalation policy: firewall health that actually warrants a page
policy: firewall-health-critical
scope:
  device_type: firewall
conditions:
  correlated_signals: ">= 2"       # e.g. management CPU + session surge together
  maintenance_window: suppress     # log it, don't page it
dedup:
  window: 15m
  group_by: [device, signal_type]  # one flapping tunnel = one alert
notify:

• level: 1 after: 2m targets: [oncall-tier1]
• level: 2 after: 10m targets: [oncall-tier2, client-technical-contact]

Correlation first, deduplication second, then escalation with deadlines and named humans. In AlertMonitor this is configured in the UI and versioned like any other policy — not scattered across NMS threshold dialogs and a group mailbox's filter rules.

### 5. Run a quarterly advisory drill

Time yourself: when the next PAN-OS advisory lands (or a Fortinet or Cisco one — every vendor has its months), how long until you have a per-client list of affected devices, current versions, and exposure? With fragmented tooling it's days of spreadsheets and SSH. With unified inventory, patch state, and monitoring in one platform, it's a filtered report and a scheduled patch wave — and the updated alert policy rolls out to every site without a per-client script.

## The Takeaway

The Unit 42 finding isn't only about ransomware groups and firewall flaws. It's about a four-month gap between something starting and someone knowing — and knowing is an alerting decision you make in advance, not during the incident. Your firewalls have been telling you things all along. The only question is whether anything you own is configured to page a human when it matters.

## Related Resources

[AlertMonitor Alert Management & On-Call Operations](https://alertmonitor.ai/platform/alert-management)
[AlertMonitor Platform Overview](https://alertmonitor.ai/platform)
[Book a Demo](https://alertmonitor.ai/contact)
[Alert Management & On-Call Operations Resources](https://alertmonitor.ai/blog/alert-management)