Suricata keyword highlight: entropy

New in Suricata 8 and later

Motivation or Why does Suricata need another keyword?

Back to Suricon Madrid in 2024. Chris Wakelin’s presentation discussed the power of using Lua – a scripting language – in the rule options. There are many sources of information on Lua – Suricata provides a way to combine the power of Lua scripting with Suricata’s detection capabilities.

Chris highlighted a specific need to determine entropy and presented a comprehensive solution in his presentation based on the Lua scripting language.

His presentation inspired me to add the entropy rule keyword to Suricata’s rule language. Unknown to me at the time, there was an existing Redmine issue requesting this feature. The entropy keyword was merged to Suricata on April 2, 2025, and will be included in Suricata 8.

Suricata Rule Primer

Suricata’s detection capabilities are driven by rulesets. Here’s a brief description of a Suricata rule.

Each rule has information describing:

Action – describing what happens when the rule matches
Header – describing the traffic to which the rule applies
Options – describing the conditions under which the rule will match

Here’s a simple rule: do not use this, as it will generate many alerts that have no value

alert ip any any -> any any (msg:”This is an example rule”; dsize: > 1; sid:1;)

The action:

alert – Tells Suricata what to do when there’s a match (other values: drop, bypass, pass, reject)

The header:

ip any any -> any any – Tells Suricata to apply the rule to all IP packets with any combination of source IP address and port flowing to (right arrow) any combination of destination IP and port

The options:

dsize > 1: Tells Suricata to alert when the packet size is > 1.
sid: 1 – Unique identifier for the rule (signature).

Note: do not use this rule in your deployment! It’s meant to show the building blocks of a rule.

Suricata’s rule language¹ is expressive with many features resulting from community support and requests.

Introduction to Entropy in Cybersecurity

First, why is entropy helpful with some cybersecurity operations? Entropy measures the randomness or predictability of data, with larger values indicating more randomness.
Thus, in cybersecurity, we can monitor the entropy of network packet data to help identify high entropy. This is associated with encrypted and compressed data and obfuscated payloads. Unexpected high entropy values can signal:

Data exfiltration (high entropy in web traffic)
Obfuscated or encrypted data in unexpected places, e.g., shellcode or malware.

The Shannon Entropy² calculation is a common metric and produces values from 0 – 8, with higher values indicating more randomness.

Suricata Entropy keyword

Suricata’s entropy keyword calculates the Shannon entropy metric. Suricata’s entropy calculation generates a floating pointer value greater than or equal to 0 and less than or equal to 8, which is then compared to the value supplied in the rule. When a match occurs, an alert will be generated.

Suricata’s entropy rule keyword is anchored to content or a sticky buffer. In many cases, the sticky buffer file.data will be used:

alert http any any -> any any (msg:"entropy simple test"; file.data; entropy: offset 10, value > 4.14; sid:10;)

This example rule will match entropy values calculated using the file.data of an HTTP request or response – this will be the HTTP request or response body. The entropy value is calculated from all the data in the request/response body beginning at offset 10. When the calculated entropy value exceeds 4.14, a match will occur and an alert will be generated.

The basics

The entropy keyword calculates the Shannon entropy value for content and compares it with an entropy value. Entropy values are expressed as floating-point values.

The full format is:

entropy: [options] value <operator><entropy-value>

where options – comma separated – are:

[bytes <byteval>] [offset <offsetval>]

If offset is not specified, the entropy calculation begins at the first byte of the buffer.

When bytes is not specified, the entire buffer will be used.

When one or both are specified, entropy is only calculated when the slice exists within the buffer starting at offsetval with byteval bytes.

For example, the buffer contains 200 bytes.

Bytes 50 and offset 10 specify a slice of the buffer that fits within the original buffer
Bytes 100 and offset 110 specify a slice of the buffer that doesn’t fit within the original buffer
Similarly, a byte value of 300 is invalid, as is an offset of 200.

Example – match when the file.data (HTTP response or request) has an entropy value greater than or equal to 4:

alert http any any -> any any (msg:"entropy simple test"; file.data; entropy: value >= 4; sid:1;)

This variant specifies to only use a slice of the file.data using 100 bytes starting at offset 10:

alert http any any -> any any (msg:"entropy simple test"; file.data; entropy: bytes 100, offset 10, value >= 4; sid:1;)

Choosing an entropy value

You might wonder, “How do I select a value for the entropy keyword?” That’s a good question, and we are working on a solution for Suricata that will include the calculated entropy value in the alert and/or a log. Having the actual entropy value will be helpful to fine-tune a rule to specific situations.

In the meantime, Cyberchef’s entropy calculator³ can help. Specify the bytes, and it’ll calculate an entropy value. This example shows the Shannon entropy value for an HTTP reply.

Entropy – detect the Emotet DLL

To conclude, we’ll show a brief example of using the entropy keyword to flag an element of the Emotet malware. Briefly, Emotet is an information stealer that was first reported in 2014. It has since evolved – see the reference for more information.

The Emotet process is multi-step and eventually involves downloading a Windows binary to establish a command and control (C2) endpoint.

Here’s a very simple set of rules to detect a high-entropy file object in a web server response. The IPs are not redacted – the Emotet pcaps are publicly available.⁴

I’ll show Suricata rules from Proofpoint’s open rule set that detect a second-stage download. We’ll then show how the entropy keyword could be used to increase confidence that the downloaded executable had high entropy.

These ET rules work together to detect second-stage downloads. The first rule triggers on outbound (intranet -> internet) GET requests to fetch an object. When detected, the first rule sets a flowbit named min.gethttp but doesn’t alert.

The second rule is active only when the flowbit set by the first rule is active and will alert when the file contents (the HTTP response body) contains a portable executable file:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO GET Minimal HTTP Headers Flowbit Set"; flow:established,to_server; flowbits:set,min. gethttp; flowbits:noalert; http.method; content:"GET"; http.header_names; content:!"Accept"; content:!"If-"; content:!"Referer"; content:!"User-Agent"; content:!"Content"; classtype:bad-unknown; sid:2016537; rev:4; metadata:created_at 2013_03_06, updated_at 2020_08_28;)

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET INFO Executable Retrieved With Minimal HTTP Headers - Potential Second Stage Download"; flowbits:isset,min.gethttp; flow:established,to_client; file_data; content:"MZ"; within:2; content:"PE|00 00|"; distance:0; classtype:bad-unknown; sid:2016538; rev:3; metadata:created_at 2013_03_06, updated_at 2013_03_06;)

This rule extends the second listed rule with the entropy keyword to increase confidence that the downloaded executable has high entropy:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"ET INFO Executable Retrieved With Minimal HTTP Headers - Potential Second Stage Download"; flowbits:isset,min.gethttp; flow:established,to_client; file_data; content:"MZ"; within:2; content:"PE|00 00|"; distance:0; entropy: value 6-8; classtype:bad-unknown; sid:2016538; rev:4; metadata:created_at 2013_03_06, updated_at 2025_05_18;)

Note that entropy values can be specified as a range – the Shannon entropy calculation produces values between 0 and 8, with 8 having the most entropy.

About me

I’ve been a member of the Suricata team at the OISF since 2019. I’ve been involved with network security since my career beginnings. Like many others, I’ve found that the open source process differs greatly from commercially driven programs in a way that appeals to me; giving me the opportunity to work with people from the entire globe and have been able to contribute to community goals in small and not-so-small ways. I am also a Principal Engineer at Corelight working on Suricata solutions for Corelight’s platforms.

If you would like more information about this blog post or would like to get in contact,, feel free to email me at Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser..

Thanks to my OISF colleagues for reviewing drafts and making impactful suggestions!