If you use Suricata, then you are familiar with the way Suricata generates detection events — historically known as “alerts”. However, the Suricata alert has evolved over the years, and these events now include a lot of other information that many current Suricata users are unaware of. Nowadays, Suricata detection events can also include vast amounts of highly useful network security monitoring (NSM) data, all without the need for additional correlation or other telemetry.

Not every Suricata user knows how to find all the extra information Suricata can gather. That is one of the reasons Stamus Networks includes all the data collected by Suricata — as well as  geoIP and other useful enrichments — and makes it available under a single completely enriched “alert” event for the analyst to view.

In this article we review some of the information that is available when viewing an alert in the Stamus Security Platform (SSP). But first, it is important to note when and how Suricata events have changed in recent years.

Suricata event format: changes and improvements

There are two major conceptual shifts that changed the way events in the Suricata intrusion detection system (IDS) were formatted:

• JSON became the default for event formatting to allow for interoperability and easy extension of exported data
• NSM data began being included in alerts due to Suricata’s ability to understand and log application layer transactions and include this information in a detection event

Beginning in 2014, Suricata began incorporating application-layer metadata with its detection engine events. Since 2016, Suricata has incorporated the metadata of each new application protocol it supports in the detection eventt record, when available. When not available, the correlation is performed later using the flow and transaction identifiers.

So what do Suricata detection events include today?

Let’s start by examining one of the signatures used to detect Trickbot. We can see the definition of this particular signature in the top of the screenshot below:

If an analyst suspected Trickbot was present on their network, then the first thing they would want to do is check all the evidence as quickly and accurately as possible. Suricata can provide all that information in a single detection event log. 

All the information you see on that page comes from a single event without any additional correlation needed. It is important to note, as mentioned earlier, that SSP includes some additional data like geoIP and other enrichments, but the majority of the data here is pure Suricata.

When we zoom in to see the information included in this detection event log, what we see at first is relatively simple, standard, and boring data.

As we look closer at the HTTP metadata, though, we begin to see something concerning. 

We see here that the URL contains “PIXELSHINE”, which is the Windows domain name on this network. This raises some concern because it shows that internal information has been sent to the internet, indicating possible data exfiltration. In this case, incident response would be our next step. 

Now let’s look at the HTTP request body. This data shows us definitely that the credentials of an administrator account have in fact been exfiltrated.

We get all of this information from a single Suricata detection event. There is no need to correlate with a NSM tool, nor is there a need to store terabytes of useless data when there are only a few things that are actually linked to alerts.

note: The latest version of SSP introduced conditional logging, which ensures that only the NSM events on flow with alerts are retained. This captures all subsequent application layer transactions so the user can better understand the sequence of events that lead to a detection event. This is a useful addition, but is especially helpful when analyzing SMB protocol where we see remote modifications of local services have been done, as seen below: 

Conclusion

Some people might still consider Suricata a “legacy” intrusion detection system (IDS), but at Stamus Networks, we don’t see it that way.  It is not only a highly capable IDS but also an impressive tool for gathering NSM data. And Suricata is, in fact, a powerful foundation on which to build a full-featured network detection and response (NDR) system. 

Many Suricata users remain unaware of how they can use and optimize Suricata beyond the basic alerts and primitive signatures. If you are interested in learning how you can unlock the full potential of Suricata, check out “The Security Analyst’s Guide to Suricata”, the world’s first practical guide to threat detection and hunting using Suricata.