Your Firewall Already Saw the Attack: Bringing AI Detection to Network Logs

Posted on Oct 18 • Originally published at logster.ai

Endpoint agents are good at seeing what happens on a machine. But a lot of an attack happens between machines: the scan that finds an exposed service, the exploit that lands on it, the malware download, the call home, the data leaving the building.

And plenty of what sits on a network will never run an agent: printers, cameras, appliances, unmanaged laptops, and the firewalls themselves.

The firewall, though, logs all of it. Every session, every denied connection, every IPS hit, every admin login. The problem has never been missing data. The problem is that the data is huge, vendor-specific, and noisy, so it mostly gets read after an incident, not during one.

At Logster we've spent the last few weeks building AI network detection: extending the AI-driven detection that today explains attacks on Windows and Linux endpoints to firewall and flow logs. It's not generally available yet, but it runs end to end, and we want to share how it works, how it performs, and what broke along the way.

In one sentence: Logster reads the logs your firewalls and routers already produce, finds the activity that looks like an attack, and tells you, in plain language, what happened and why it thinks so.

The naive version of AI network detection is to send every log line to a large language model. That doesn't survive contact with a real network: a single busy workstation can produce thousands of sessions in a few minutes. So the pipeline is layered, with cheap deterministic work first and the AI only where it adds value.

Every vendor speaks its own dialect. FortiGate says close, server-rst, ip-conn; Cisco ASA says TCP FINs, TCP Reset-I, SYN Timeout; NetFlow just gives you TCP flag bits. We map all of them onto one small vocabulary of connection states:

CLOSED_NORMAL finished cleanly ESTABLISHED open / still running RESET_BY_CLIENT / RESET_BY_SERVER / RESET NO_REPLY SYN never answered TIMEOUT idle / aged out REJECTED actively refused POLICY_DENY blocked by a rule THREAT_BLOCK killed by IPS Enter fullscreen mode Exit fullscreen mode Direction matters just as much. Every event records who started the conversation, which side each byte count belongs to, which zone each side sits in, and the NAT translation, so an inbound attack on a web server behind a public address is attributed to the internal server, not to the public IP.

Activity is grouped per IP address into short sliding windows (three minutes), re-evaluated every 30 seconds. Firewall admin and configuration events are grouped under the firewall itself, so tampering with the device gets its own verdict.

Each window runs through a set of fast, explainable checks. A few examples:

Each signal has a strength tier. A window with no signals at all is recorded as benign and never reaches the AI. In our tests that was 96–98% of windows, which is what makes AI network detection affordable at network scale.

We know that a screening step is also a risk: an attack that trips no signal is never shown to the AI. So we measure it. For every labelled attack in our test data we track how many of its windows the screen let through, and the safeguards we're adding next (spending spare AI budget on cleared windows, random audits, periodic per-host reviews) exist specifically so the screen can't silently hide something.

Windows with signals become a compact graph: the host in question, its peers, flow edges with states, applications and bytes, and IPS-alert edges. The graph and the signals go to the AI with a network-specific prompt. Here is a real verdict, unedited, for a web server under attack:

host:192.168.250.70: 1. Recon - External host 40.80.148.42 performed extensive vulnerability scanning (Acunetix.Web.Vulnerability.Scanner, tier B). 2. Exploitation - The scanner successfully delivered multiple high-severity exploits, including Bash RCE (Bash.Function.Definitions.Remote.Code.Execution, tier A), PHP CGI Argument Injection (tier A), and HTTP XXE (tier A), all of which were allowed by the firewall.

And one for an infected workstation a few minutes after a malware download:

host=192.168.250.100: 1. Recon - The host performed massive external scanning via UDP port 6892 (SCAN_HOSTS tier A) and port 137 (SCAN_HOSTS tier A) across thousands of external IPs. 2. Command and Control - The port 6892 traffic is identified as Cerber.Botnet, indicating active botnet communication. 3. Novelty - The host established connections to 6,421 new external peers (NEW_EXTERNAL tier B).

This is roughly what the AI was looking at for that workstation: a completed download the firewall's IPS flagged as malware and let through, then thousands of unanswered connections labelled Cerber.Botnet.

The AI's "attack" is not the last word. An alert also needs either one strong signal or signals from at least two independent families. One odd connection is never enough to wake someone up.

This is the part we're most excited about.

When Logster's endpoint agent flags a machine and the firewall flags that machine's IP address, those are two views of the same incident. In most SOCs, connecting them means someone looking up which host had that IP at that time, by hand.

Logster does it automatically. It learns which machine owns which address from the endpoint's own network activity (an address that appears in most of a host's connections is that host's address) and from DHCP lease logs. When a network alert arrives for an IP, it's linked to the open endpoint alert for the machine behind it, in both directions.

In our test replay of a real-world style infection, the endpoint alert ("this desktop's processes look malicious") and the network alert ("this IP downloaded malware and is now spraying the internet") arrived 24 seconds apart, already linked as one incident. The analyst gets the process tree and the network picture side by side, without matching anything by hand.

We built a replay harness that pushes labelled public datasets through the full AI network detection pipeline, the same services that run in production, and scores detection, time to first alert, false alarms, and AI cost. Two of the datasets were held out entirely: we never tuned on them.

5 of 5 attacks detected, 0 false alarms, 2–4% of windows sent to the AI.

To be clear about what this is: public datasets, replayed through the real pipeline — which is the kind of evidence we think every detection vendor should be asked for. Validation on live networks is the next step, and some detections (brute force, lateral movement, beaconing, exfiltration) are built and unit-tested but not yet proven on a real-world dataset, because none of the ones we've run contain those attacks.

The scariest bugs in AI network detection are the quiet ones: the attack is in the logs, nothing errors, and nothing is detected either. Our harness found three of them.

1. The attack that was never in a window. Windows slide by event time. When logs arrive faster than windows are evaluated (a burst, a backlog after a restart), events can slide out of the window before anything has looked at them. In one replay, the malware download itself was trimmed before any evaluation saw it. The fix: a network window now holds on to events until an evaluated snapshot has actually contained them, with a hard bound so it can't grow forever.

2. The DNS server that "scanned" the network. NetFlow often reports each direction of a conversation as a separate record, and deciding which side started it is surprisingly hard. Our first version guessed from port numbers, and promptly flagged a proxy and a DNS server as port scanners: their replies to hundreds of clients looked like outbound connections to hundreds of hosts. The fix was layered evidence: scan-like TCP flags first, then well-known ports, then how many distinct peers use each port, and only then a guess.

3. The clock that went backwards. A window evicts events older than its newest event minus its length. If a device's clock jumps backwards, say after an NTP correction, or when two devices with skewed clocks report the same IP, the newest timestamp is stuck in the future, and every new event looks too old and is silently dropped. It only recovers after a pause in traffic that a busy host never takes. We found it when replaying two datasets in date order reversed: one server got zero verdicts for an attack that was detected fine on its own. A backward jump now restarts the window, at most once per window length, so two out-of-sync clocks can't make it flap.

And one about the harness itself: for a while, our "wait until the pipeline is quiet" step returned immediately, because a query error was being swallowed. Every number from before that fix was re-measured. If you build an evaluation harness, test the harness.

Each of these is now pinned by an automated test.

The AI network detection pipeline runs end to end today. Next:

Logster started by explaining what happens on your machines. Soon it will explain what happens between them, and tell you when both views are describing the same attack.

If you run a SOC, manage firewalls, or just have opinions about AI network detection, we'd love to hear from you. Tell us which vendors and which attacks you'd want covered first.

Datasets: Splunk Boss of the SOC v1 (CC0), CTU-13 by the Stratosphere Lab at the Czech Technical University (CC BY), and Splunk attack_data (Apache 2.0). Thanks to their authors for making realistic security data public.