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 and how it performs.
What AI network detection does
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.
Concretely:
- It ingests firewall syslog and NetFlow/IPFIX, detects the vendor automatically, and converts every format into one common network event. FortiGate and Cisco ASA are tested on real data; Palo Alto and Juniper parsers are in progress.
- It looks for behaviour, not just signatures: scanning, exploitation, malware downloads, beaconing, unusual data volume, tunnelling apps, brute force, and tampering with the firewall itself.
- It gives every verdict an explanation: attack or benign, a confidence, a numbered story of the attack phases, and MITRE ATT&CK techniques.
- It shows the evidence as a graph: who talked to whom, on which ports and applications, how many bytes moved in each direction, how sessions ended (completed, reset, no reply, denied), and what the firewall's own IPS flagged.
- It links network alerts to endpoint alerts when both describe the same machine. More on that below; it's our favourite part.
How it works
Logster turns the logs your firewalls and routers already write into something an AI can reason about, and then checks its own answer before anybody gets paged. Vendor formats are collapsed into one common network event, activity is grouped by host, and what the AI finally sees is a compact picture of that host's behaviour rather than a wall of raw log lines.
Reason with the AI
Each host's recent activity becomes a compact graph: the host in question, its peers, flow edges with states, applications and bytes, and IPS-alert edges. That graph goes to the AI with a network-specific prompt. Here is a real verdict 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). 2. Exploitation - The scanner successfully delivered multiple high-severity exploits, including Bash RCE (Bash.Function.Definitions.Remote.Code.Execution), PHP CGI Argument Injection, and HTTP XXE, 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 and port 137 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.
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.
Guard
The AI's "attack" is not the last word. An alert also needs corroborating evidence, from more than one kind of observation. One odd connection is never enough to wake someone up.
One incident, two views
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.
How it performs
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 and false alarms. Two of the datasets were held out entirely: we never tuned on them.
| Scenario | Dataset | Result |
|---|---|---|
| Web server: vulnerability scan, SQL injection, Shellshock, reverse shell | Splunk BOTS v1 (FortiGate) | detected 73 s after the attack began, at real-time speed |
| Workstation: malware download, then mass scanning | Splunk BOTS v1 | detected 12 s after the download |
| A normal business day | Splunk BOTS v1 | 0 false alarms |
| Spam botnet with command-and-control (held out) | CTU-13 (NetFlow) | detected; 0 false alarms across 81 normal hosts over an hour |
| Firewall tampering: internet admin login, logging disabled (held out) | Splunk attack_data (Cisco ASA) | both episodes detected, in 42 s and 4 s |
5 of 5 attacks detected, 0 false alarms.
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.
What's next
The AI network detection pipeline runs end to end today. Next:
- An Alerts view in the dashboard that shows linked endpoint and network incidents together
- Whitelisting for network rules, so approved scanners, backup jobs and management hosts stay quiet
- Collectors and deployment packaging, plus validation on live lab traffic
- More coverage: more vendors, and real-world validation for brute force, lateral movement, beaconing and exfiltration
- Sharper output: technique IDs checked against the ATT&CK catalogue, and richer graph edges (packet counts, inbound data-theft detection)
Closing
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.
Top comments (0)