Suricata as a Hunt Data Source

Most analysts treat Suricata like a burglar alarm: it rings, you respond, you move on. That’s a fine use of an IDS. It’s a poor use of a hunting platform. Suricata generates a lot more than alerts—protocol logs, flow metadata, file extraction events, TLS details—and almost none of that gets touched unless something first trips a signature.

That’s backwards for hunting purposes. The whole point of proactive hunting is looking at activity that didn’t trip anything. Suricata’s EVE JSON output, when you actually mine it instead of just watching the alert feed, gives you exactly that.

Alerts Are the Least Interesting Part of Suricata for a Hunter

I’ll say something a little unpopular: if you’re only using Suricata alerts for hunting, you’re using 20% of the tool. Alerts fire on known-bad signatures—by definition, things someone already wrote a rule for. A hunter’s job is finding what nobody wrote a rule for yet.

The real value is in the surrounding EVE JSON event types—dns, http, tls, flow, fileinfo, smb, ssh. These fire regardless of whether a signature matched, which means you get visibility into every session on the wire, not just the ones that got flagged.

Take fileinfo events. Suricata logs every file transfer it sees crossing HTTP, SMB, and a few other protocols, complete with hash, size, and MIME type—whether or not a signature triggered. Say your environment doesn’t allow inbound RAR/7z archives via HTTP under normal business use. A fileinfo hunt filtering for those extensions arriving from external IPs, cross-referenced against endpoints that shouldn’t be receiving them, catches staged payload delivery that a signature-only approach would completely miss if the file itself wasn’t a known-bad hash.

Flow Records for Baseline-Breaking

Suricata’s flow.log (or the flow event type in EVE) gives you bytes-to, bytes-from, packet counts, and duration per session—similar territory to Zeek’s conn.log but worth checking even if you’re already running Zeek, because the two tools sometimes catch slightly different edge cases depending on how your sensor placement and rulesets are configured.

A useful baseline-breaking hunt: sort flows by bytes_toclient vs bytes_toserver ratio. Normal web browsing skews heavily toward bytes_toclient (you’re downloading pages, images, video). A session where bytes_toserver dominates—say a host sending 40MB out to a destination that sent back only a few KB—is worth investigating regardless of whether any signature fired. That asymmetry is a classic exfil shape.

Custom Rules Aren’t Just for Blocking—Write Them for Hunting Metadata

Here’s a technique that gets underused: write Suricata rules with alert action but tuned purely to generate metadata for hunting, not to page anyone. Give them low-noise thresholds, tag them clearly (something like hunt_candidate in the rule’s metadata field), and route them to a separate index your hunters check weekly rather than the SOC’s real-time queue.

For example, a rule flagging any DNS query for a domain registered in the last 30 days, hitting from an internal host, generates too much noise for real-time alerting in most environments—but it’s a genuinely useful weekly hunt feed. New domains get abused by attackers constantly because infrastructure is cheap and disposable; a rule like this doesn’t stop anything on its own, but it feeds a human decision process really well.

Correlating Suricata with Endpoint Telemetry

Network alone rarely tells the full story, and this is where a lot of pure-network hunters stall out. A Suricata alert or hunt candidate on its own is a lead, not a conclusion. The move is pivoting from the network event—source IP, destination, timestamp—into your EDR or endpoint logs for the same host and time window.

If Suricata flags outbound traffic to a known-bad IP range from 10.4.2.31 at 14:22:07, the next step isn’t closing the ticket—it’s checking what process on that host initiated the connection, what parent process spawned it, and whether that process has a legitimate reason to be making outbound connections at all. Suricata tells you the network told a story; endpoint telemetry tells you who wrote it.

The Signature Update Trap

One caution worth mentioning: teams that rely heavily on community rulesets (ET Open, for instance) sometimes assume coverage they don’t actually have. Rule authors write signatures reactively, often days or weeks after a technique first appears in the wild. If your hunting program leans entirely on “did Suricata alert,” you’re always hunting yesterday’s threats. The metadata-mining approach described above is slower and requires more analyst judgment, but it’s the part that actually gets you ahead of the signature curve instead of riding behind it.

Suricata’s real strength for a hunting team isn’t detection—plenty of tools detect known bad. It’s the breadth of structured metadata it generates on every single session, whether flagged or not, that gives hunters something to actually dig into.