Writing Suricata rules to detect command-and-control traffic

Command-and-control traffic is one of the more useful places to apply network detection, because it often leaves repeatable patterns even when the payload is encrypted. Suricata is well suited to this work when you treat it as part of a wider detection stack rather than a single answer. For UK SMEs, the practical goal is not to catch every possible beacon. It is to build a set of rules that identify suspicious network behaviour with enough fidelity to support triage, investigation, and containment.

If you already have endpoint telemetry, identity logs, and a SIEM, Suricata adds another layer of visibility that can expose activity missed by host-based controls. That is especially valuable when malware uses standard protocols such as HTTP, DNS, or TLS to blend in. If you want the broader context first, our article on detecting command-and-control traffic at the network layer covers the detection problem from a wider architecture perspective.

What Suricata can and cannot detect in command-and-control traffic

Suricata is an intrusion detection and intrusion prevention engine that inspects packets and flows against signatures and protocol parsers. In practice, that means it is strong where the traffic has stable structure, repeated indicators, or protocol-level anomalies. It is weaker where the adversary uses highly variable infrastructure, custom encryption, or short-lived infrastructure that changes faster than your rules can be maintained.

For command-and-control, Suricata works best when you target behaviours such as beaconing intervals, suspicious HTTP headers, unusual DNS query patterns, TLS certificate oddities, or connections to rare destinations. It is less effective if you expect a single static string to identify a family of malware across every environment. The most reliable detections usually combine several weak signals into one higher-confidence rule.

Where Suricata fits is in the middle of the stack. Endpoint detection and response can tell you which process made the connection. SIEM correlation can tell you whether the same host also showed suspicious logons, PowerShell activity, or privilege changes. Suricata can tell you that the network conversation itself looks wrong. That combination is usually more useful than any one control on its own.

Where Suricata fits in a layered detection stack

For a small security team, the most practical deployment is usually at an internet edge, a core choke point, or a mirrored segment that sees outbound traffic from user subnets and servers. If you can only place one sensor, prioritise the path that carries outbound connections to the internet. That is where command-and-control usually appears first.

Suricata alerts should not live in isolation. Feed them into your SIEM, enrich them with asset context, and map them to a case workflow. If your team already uses Sigma for log-based detections, keep the same operational discipline: define the use case, document the expected behaviour, tune for your environment, and measure false positives over time. Our guide to building SIEM detections using Sigma rules is useful for that broader detection engineering approach.

Common command-and-control patterns that are suitable for rule-based detection

Rule-based detection is most effective when the traffic has one or more of the following characteristics:

• Repeated connections to the same host or domain at regular intervals.
• HTTP requests with unusual user agents, paths, or header combinations.
• DNS queries for algorithmically generated or low-reputation domains.
• TLS sessions with suspicious certificate properties or rare JA3-like fingerprints.
• TCP sessions with small, periodic payloads and limited session variation.

These are not proof of malicious activity on their own. They are indicators that deserve correlation. A good Suricata rule should reflect that by being specific enough to reduce noise, but not so specific that it only matches one sample in a lab.

Suricata rule structure for defenders

Suricata rules have a header and a set of options. The header defines protocol, source and destination addresses, ports, and flow direction. The options define what to look for inside the packet or stream, how to classify the event, and how to manage alert volume.

A simple rule structure looks like this:

alert http any any -> any any (msg:"Suspicious HTTP beaconing pattern"; flow:to_server,established; content:"User-Agent|3a|"; http_header; content:"curl/"; nocase; classtype:trojan-activity; sid:1000001; rev:1;)

That example is intentionally simple. In production, you would usually add more context, such as a specific URI pattern, a rare header order, a known suspicious host group, or a threshold to avoid repeated alerts from the same endpoint.

Rule header, flow direction, and protocol selection

The protocol should be as specific as possible. If you know the traffic is HTTP, use the HTTP app-layer keyword rather than raw TCP content matching. The same applies to DNS and TLS. App-layer inspection gives you cleaner matches and better resilience to packet fragmentation or reassembly issues.

Flow direction matters too. For command-and-control, most rules should focus on to_server traffic, because the client initiates the connection. Use established where appropriate so you are not matching incomplete handshakes or noise from scans. If you are hunting for callback traffic, that directionality helps reduce false positives.

Core options: content, pcre, flowbits, thresholding, and metadata

content is the workhorse for exact or near-exact string matching. It is fast and easy to reason about. Use it for header names, URI fragments, DNS labels, or certificate fields when the pattern is stable.

pcre gives you regular expression matching, which is useful for variable structures such as encoded paths, suspicious subdomain patterns, or repeated numeric tokens. Use it carefully. A broad regular expression can become expensive and noisy very quickly.

flowbits lets you correlate events across packets or rules. That is useful when one rule marks a flow as suspicious and another rule fires only if a second condition appears later in the same session. For example, you might mark a flow after a rare user agent is seen, then alert only if the same flow also shows a suspicious URI pattern.

threshold, detection_filter, and suppression controls help you manage alert volume. They are essential for beaconing detections, because a single host may generate many similar events in a short period. Metadata fields such as classtype, reference, and metadata help with triage and reporting, especially when you map detections to MITRE ATT&CK techniques.

Detection ideas that work well for command-and-control

The most effective Suricata C2 rules usually target protocol-specific clues rather than generic malware language. That is because command-and-control traffic often tries to look ordinary at the packet level. Your advantage is that ordinary traffic still has structure, and that structure is often inconsistent with the host, application, or destination involved.

HTTP, DNS, TLS, and TCP patterns worth targeting

HTTP is a good place to start because many malware families still use it for callbacks, tasking, or staging. Useful indicators include uncommon user agents, missing or malformed headers, suspicious cache-control behaviour, or repeated small requests to the same path. A rule that looks for a rare user agent on a host that should not be running a browser is often more useful than a generic string such as Mozilla or curl.

DNS detections can focus on long labels, high entropy, repeated subdomain structure, or unusual query types. A common pattern in DNS-based command-and-control is a stream of queries that look syntactically valid but operationally odd, such as many unique subdomains under the same parent domain. Suricata can detect these patterns, but the best results usually come from pairing DNS signatures with domain reputation or rarity data in the SIEM.

TLS is more challenging because the payload is encrypted, but the handshake still exposes useful metadata. Certificate subject and issuer fields, validity periods, SNI values, and fingerprinting can all help. If you already use JA3 or JARM elsewhere in your stack, Suricata can complement that by alerting on certificate anomalies or unusual handshake characteristics. For a wider view of how network telemetry supports detection, see our guide to designing Integrated Network Detection and Response.

TCP-only detections are usually the least precise, but they can still help when you see regular small payloads, fixed intervals, or odd session lifetimes. These are often better used as enrichment signals than as standalone alerts.

Using protocol anomalies, rare destinations, and suspicious user agents

One of the most useful ideas in detection engineering is rarity. A destination that is rare for your environment is more interesting than a destination that is merely external. The same applies to user agents, TLS issuers, DNS patterns, and ports. Suricata can help you identify those rare events, but you need environment knowledge to decide whether they matter.

For example, a finance team laptop making repeated HTTP requests with a command-line user agent is more suspicious than a software build server doing the same thing. The rule may be identical, but the context is not. That is why good Suricata engineering always includes asset scoping, host grouping, or downstream enrichment.

Building higher-fidelity rules with context

High-fidelity detections are usually built from combinations, not single indicators. A rule that matches one suspicious string may be useful during hunting, but it is rarely robust enough for production alerting. The aim is to make the rule reflect a behaviour pattern that is hard to explain away as normal business activity.

Combining multiple indicators in one rule

Suppose you want to detect HTTP beaconing. A stronger rule might require a rare user agent, a small request body, a fixed URI pattern, and repeated connections to the same destination. None of those signals alone is definitive. Together, they are much more compelling.

In Suricata, you can chain multiple content matches, use distance and within to control proximity, and use pcre for flexible structure. You can also scope the rule to a specific port or protocol parser. The more you can anchor the rule to protocol semantics, the less likely it is to break when packet ordering or encoding changes.

Using flow state and correlated events to reduce false positives

flowbits is especially useful when you want to separate a weak first signal from a stronger second signal. For instance, one rule can tag a flow when it sees a suspicious DNS query. Another rule can alert only if the same host then opens a TLS session to the resolved destination within a short time window. That kind of correlation is often more resilient than a single monolithic signature.

Another useful pattern is to combine Suricata alerts with SIEM correlation rules. Suricata can flag the network event, while the SIEM checks whether the same host also triggered endpoint telemetry, authentication anomalies, or unusual process creation. That is often the best way to turn a network alert into a useful investigation lead.

Practical examples of Suricata rule patterns

The examples below are illustrative patterns rather than drop-in production rules. They show the kind of logic that tends to work well for command-and-control detection. You would still need to tune them to your own environment, asset mix, and traffic profile.

Example approaches for HTTP beaconing and DNS-based C2

For HTTP beaconing, a useful pattern is to look for a small, repeated request with a rare user agent and a fixed URI structure. A rule might inspect the HTTP header for a non-standard user agent, then inspect the URI for a short, repeated path fragment. If you see the same host making the same request every few minutes, that is worth investigating even if the content itself is not obviously malicious.

For DNS-based command-and-control, focus on query patterns rather than single domains. A rule can look for long subdomains, repeated label structure, or query names that contain a high proportion of digits and random-looking characters. If your environment uses legitimate dynamic DNS or software update services, you will need to suppress those known-good patterns early.

Example approaches for TLS fingerprint and certificate anomalies

TLS detections often work best when they identify what is unusual for your estate. Examples include self-signed certificates on outbound connections where you would normally expect public trust, certificates with very short validity periods, or SNI values that do not match the destination pattern you would expect from the application. A rule can also flag rare TLS fingerprints if you have a baseline of normal client behaviour.

Be careful not to overfit to a single fingerprint. Malware authors can change libraries, and legitimate software can share the same TLS stack. Use fingerprinting as one signal among several, not as a sole indicator of compromise.

Tuning rules for production use

Production tuning is where many otherwise good detections fail. A rule that is technically correct but generates constant noise will be ignored. The aim is to preserve the signal while reducing the operational burden on the team.

Thresholding, suppression, and alert grouping

Use thresholding to control repeated alerts from the same source or destination. For beaconing, it is often better to alert on the first few occurrences and then suppress repeats for a defined period. That gives analysts enough evidence to triage without flooding the queue.

Suppression should be used carefully. Suppressing by source IP can hide real activity if the address is reused or spoofed internally. Suppressing by asset group, application, or known service account is usually safer. Alert grouping in the SIEM can also help, especially if you want one case per host rather than one event per packet.

Reducing noise from legitimate software and cloud services

Modern environments generate a lot of traffic that looks odd at first glance. Software update agents, remote management tools, backup systems, and cloud connectors can all resemble command-and-control if you only look at packet shape. Build an allow list for known-good services, but keep it narrow and reviewed. Overly broad exclusions are one of the fastest ways to lose visibility.

It is also worth segmenting rules by asset class. A server subnet, a user workstation subnet, and a developer environment will all have different normal behaviour. If you do not account for that, your false positive rate will be higher than it needs to be.

Testing and validating detections safely

Testing is not optional. A Suricata rule that has never been validated against real traffic, lab traffic, and known-good baselines is just a hypothesis. The safest way to test is to replay packet captures in a controlled environment, compare the alerts to expected outcomes, and then adjust the rule before production rollout.

Using pcap replay, lab traffic, and known-good baselines

Packet capture replay is useful because it lets you test the rule against exact traffic without risking live systems. You can use representative samples from your own environment, then add synthetic lab traffic that mimics suspicious patterns. The key is to include both positive and negative cases. A rule that only works on malicious-looking traffic is not enough; it must also stay quiet on normal business traffic.

Keep a baseline of common destinations, user agents, DNS patterns, and TLS fingerprints for your estate. That baseline becomes your reference point when you tune the rule. If a detection fires on something that is common in your environment, the rule probably needs more context rather than more sensitivity.

Checking alert quality against MITRE ATT&CK techniques

Mapping detections to MITRE ATT&CK helps you understand what behaviour you are actually covering. For command-and-control, you are usually looking at techniques in the C2 and exfiltration-adjacent areas, depending on the protocol and behaviour. That mapping is useful because it forces you to describe the detection in operational terms rather than just naming a malware family.

It also helps with coverage reviews. If one rule covers HTTP beaconing but you have no DNS or TLS coverage, you can see the gap quickly. For a broader framework view, our article on the NIST Cybersecurity Framework for UK SMEs shows how detection fits into a wider resilience model.

Operational considerations for small security teams

Small teams need detections that are maintainable. That means clear naming, version control for rules, change tracking, and a simple process for reviewing alerts. If your Suricata rules are not treated like code, they will become difficult to trust over time.

Where to deploy Suricata sensors for useful visibility

Place sensors where they see meaningful east-west or north-south traffic without creating blind spots. For SMEs, that often means the internet edge, a core switch mirror, or a virtual sensor in a cloud environment. If you have branch offices or remote workers, think about where their traffic exits and whether that path is visible to your sensor.

Do not assume one sensor sees everything. If your environment uses split tunnelling, cloud SaaS, or remote access gateways, some command-and-control traffic may bypass the point you are monitoring. That is not a reason to abandon network detection, but it is a reason to define its coverage honestly.

How to feed alerts into SIEM or case management workflows

Suricata alerts are most useful when they arrive with enough context to support triage. Include source and destination, protocol, rule metadata, and any flow or signature identifiers that help analysts pivot. If possible, enrich the alert with asset criticality, user identity, and geolocation or reputation data in the SIEM.

For a small team, the best workflow is usually simple: alert, enrich, triage, contain, and document. If the same pattern repeats, feed the outcome back into rule tuning. That continuous improvement loop is what turns a noisy IDS into a useful detection capability.

Common mistakes when writing Suricata C2 rules

The most common mistake is writing rules that are too broad. A generic string match on curl, python, or Mozilla will usually create more noise than value. Another common mistake is making the rule so specific that it only matches one sample and fails as soon as the attacker changes a minor detail.

Another issue is ignoring encrypted traffic. Even when payloads are hidden, the handshake, certificate, SNI, and flow behaviour still provide useful signals. If your rules only inspect cleartext HTTP, you will miss a large part of modern command-and-control.

Fragmentation, compression, and protocol edge cases can also break brittle rules. Use the app-layer parser where possible, and test against traffic that reflects real-world conditions rather than ideal lab packets. Finally, remember that environment-specific noise is not a nuisance to be ignored. It is the main thing that determines whether a rule is operationally useful.

When to extend beyond Suricata rules

Suricata is valuable, but it should not be the only detection mechanism you rely on. If you need to understand process lineage, script execution, identity misuse, or post-exploitation behaviour, endpoint telemetry and SIEM correlation will usually give you better context. Suricata tells you what the network did. It does not tell you everything about why the host did it.

That is why the strongest programmes combine network detections with endpoint, identity, and threat hunting workflows. If you are already using EDR, use Suricata to add network corroboration. If you are using a SIEM, use Suricata to enrich cases and reduce blind spots. If you are building a detection engineering practice, keep the rules under version control and review them the same way you would review any other security control.

For teams that want to improve their overall visibility, it is often worth pairing Suricata work with endpoint hardening and logging improvements. Our article on endpoint hardening using CIS Benchmarks is a useful companion piece because better host hygiene usually means cleaner network detections.

If you are assessing how these controls fit into a broader assurance or improvement programme, a practical review of your logging, detection, and response design can help you prioritise the next step. For UK SMEs, the aim is usually not to build the most complex detection stack. It is to build one that is understandable, maintainable, and capable of surfacing the activity that matters.

If you would like help shaping Suricata detections into a wider monitoring strategy, Speak to a consultant.

Frequently asked questions

Can Suricata detect command-and-control traffic over HTTPS?

Yes, but usually not by inspecting the encrypted payload. The useful signals are in the TLS handshake, certificate properties, SNI, session behaviour, and destination rarity. In practice, HTTPS detections work best when Suricata is combined with other context such as endpoint telemetry or SIEM correlation.

How do I reduce false positives in Suricata C2 rules?

Make the rule more specific, scope it to the right protocol and flow direction, and add context such as multiple indicators, thresholding, or asset-based suppression. It also helps to test against your own traffic baseline so you can exclude legitimate software, cloud services, and management tools that resemble command-and-control.