Writing a Sigma Rule for a CVE or Technique: From Behavior to Detection That Does Not Drown the SOC

A report describes a new technique: the exploitation of a CVE, the abuse of a legitimate system binary, a post-exploitation behavior. You want to know whether it is happening in your environment. Sigma is the pivot format for that: a readable YAML, SIEM-agnostic, that you write once and convert to Splunk, Elastic or Sentinel. But writing the rule is one thing; writing a rule that fires on the real behavior without burying the SOC under false positives is another.

An important point up front: Sigma detects a behavior in logs, not a vulnerability on the wire. For a CVE, that means detecting the exploitation (what the attack does on the host (a process launched, a registry key modified, a characteristic command)) not the flaw itself. This article shows how to go from a described behavior to a rule that holds in production, and how to prove it.

The anatomy of a Sigma rule

A Sigma rule comes down to a few blocks:

title: Suspicious MSHTA execution from a temporary directory
id: 7c9d2e10-4a3b-4f8e-9c1a-000000000000
status: experimental
description: Detects mshta.exe launching a script from a temporary path, an execution technique observed after exploitation.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\mshta.exe'
        CommandLine|contains:
            - '\Temp\'
            - '\AppData\Local\Temp\'
    filter_legit:
        ParentImage|endswith: '\msiexec.exe'
    condition: selection and not filter_legit
falsepositives:
    - Legitimate software deployments via MSI
level: high
tags:
    - attack.execution
    - attack.t1218.005

The logsource says where to look (here, Windows process-creation events). The detection block combines a selection (the criteria that characterize the technique) and, often, a filter (what to exclude). The condition assembles it all. The falsepositives, level and tags fields are not decoration: they make the rule triageable and usable by the SOC.

The logsource is half the work

A Sigma rule is only worth anything if the data it queries exists. Two traps before you even write the detection:

• The right category. process_creation, registry_event, network_connection… pick the wrong one and you write a rule that will never apply to the right events.
• Your actual telemetry. If your Sysmon configuration does not log command lines, no rule based on CommandLine will fire, however correct it is. Detection starts with collection: confirm your logs contain the field you depend on.

Start from the behavior, not a copied rule

As with all detection, the starting point is the fact, not someone else's expression. An analysis report describes the observable: the process launched, its parent, the characteristic argument, the key written. That fact belongs to no one, the rule you derive from it is your own work. Copying a rule published under a copyleft license or with no license into a closed or resold set, on the other hand, would contaminate its rights.

Concretely: read the report, isolate the minimal, reliable action that proves the technique, and build the selection around it, not around everything the attacker did, only the most discriminating sign.

The false-positive discipline

This is where most rules fail in production. A selection that is too broad (CommandLine|contains: 'powershell') fires thousands of times a day on legitimate activity. Three reflexes:

• Tighten the selection. Combine several fields (Image and CommandLine and ParentImage) rather than a single vague pattern.
• Filter known-legitimate. The filter block removes clean uses that would match anyway (an admin tool, an MSI deployment). The falsepositives field documents what remains.
• Beware common tokens. A lone word that appears in authentication events or mundane service names produces an alert storm. Always prefer a specific combination over a single token.

Map to ATT&CK

Fill the tags with the MITRE ATT&CK tactic and technique (attack.execution, attack.t1218.005). This is not cosmetic: it is what lets the SOC triage, measure its coverage and correlate the rule with the rest of its detection. A rule with no ATT&CK tag is an orphan rule.

Validating is not enough: you have to prove

The pySigma tooling checks syntax and consistency:

sigma check rule.yml

But "valid" does not mean "fires at the right moment." The proof is empirical, in two steps:

1. Does the rule fire on the real technique? Convert it to your SIEM (via the pySigma backend), trigger the technique in a test environment (a project like Atomic Red Team replays hundreds of ATT&CK techniques in a controlled way) then confirm the alert appears. If nothing fires, the rule is useless.
2. How much noise on normal traffic? Run the converted rule against a day of real, benign logs. The number of hits tells you whether it is deployable or will drown the analyst.

A rule that fires on the technique and stays quiet on the everyday is worth infinitely more than a merely "valid" one. That is the difference between "it compiles" and "it detects, proven."

The traps that cost you

• The lone token on a common event. The number-one cause of false-positive storms. Combine; never rely on a single word.
• The wrong logsource. A rule filed under the wrong category applies to nothing, a silent false negative.
• Field names. After conversion, Image becomes process.executable in ECS, something else elsewhere. Check that the mapping matches your schema, or the query matches nothing.
• The over-broad selection. A single vague contains deployed in production, and the SOC calls you back within the hour.

In summary

Writing a good Sigma rule for a CVE or technique is a method: detect the exploitation (the behavior in logs, not the flaw), start from the fact in the report, tighten the selection and filter the legitimate, map to ATT&CK, and prove empirically that the rule fires on the technique without drowning the everyday. The rest (syntactic validation, tags, level) is hygiene.

That is exactly the discipline we apply at scale in the ThreatClaw Sigma feed: every rule is tested on its real firing, mapped to ATT&CK, and shipped ready to convert to your SIEM. You get the detection, not a YAML you still have to prove out.