Sigma Rule Builder

About this tool

Sigma is the common format for describing detections in log data, so one rule can be converted to Splunk, Elastic, Microsoft Sentinel and many other systems. A rule is a small YAML file: title, id, status, description, author, date, ATT&CK tags, a log source, a detection (named blocks of field conditions plus a condition that combines them), known false positives and a severity level. The YAML is easy to get subtly wrong: a path with a backslash and a star means something different from a literal, a value like 4688 can be a number or a string, a colon or a hash in a title can change the structure, and the order of modifiers matters. This builder writes the rule from a form. Pick the log source (Windows process creation, PowerShell script blocks, registry, files, DLL loads, network connections, DNS, the Security log, Linux, macOS, proxy, web server, firewall, DNS, AWS CloudTrail and more, or your own category, product and service). Add a block of conditions that must match: each row is a field and a match type (equals, contains, contains all of, starts with, ends with, regular expression, CIDR network, numeric comparisons, or contains in any dash style) with one or more values, any of which may match. Add exclusion blocks (filters) for known benign activity, and choose whether several "must match" blocks are joined with AND or OR; the tool writes the condition for you, such as selection and not filter. A block can also be a list of keywords for plain-text logs. Values are treated as plain text and escaped for Sigma, so a literal star or a backslash before a star is not mistaken for a wildcard; use the match types instead of wildcards. Whole numbers stay numbers, and text that could confuse YAML is quoted correctly. A button makes a rule id (UUID) and today's date, and tags are checked against ATT&CK format. We checked the tool against pySigma, the reference Sigma library, and a YAML parser. 415 plain values (including awkward ones with backslashes, stars and question marks) were escaped and read back by pySigma's own string parser to confirm they are literal and exact. YAML text was read back by PyYAML to confirm every value survives. 55 generated rules covering every match type, every log source, every level and every status were parsed, passed all of pySigma's validators and converted to Splunk and Lucene (Elastic) queries. The conditions with filters, OR and AND were checked on the converted queries. And about 300 randomly generated rules built from deliberately awkward fields, values, dates and tags were all read by PyYAML and pySigma and converted, which is how inputs that pySigma would reject (a field called 1 or null, a network with host bits set, a date like 2026-02-30, a regular expression only JavaScript understands) were found and are now refused. Regular expressions are limited to a conservative set of constructs that Python, PCRE and Splunk read the same way (no named groups, look-around, (?:...) groups or \p escapes). These are broad checks, not a proof for every possible input. The tool does not check that your field names match your own log mapping, and it does not know whether an ATT&CK technique number exists, so test the rule on real logs and check your tags. It writes text only and what you type stays in your browser.

How to use it

1. Give the rule a title and pick the log source.
2. Add what must match: a field, a match type and the values.
3. Add exclusions for known benign activity, and set the level.
4. Copy the YAML or download it as a .yml file, then convert it with your Sigma tooling.

Example

The tool also writes the date, tags, description and other details you fill in.

Windows process creation · Image ends with \cmd.exe · CommandLine contains whoami · exclude User = SYSTEM

title: Suspicious cmd
id: 6f3f3a8b-1c2d-4e5f-8a9b-0c1d2e3f4a5b
status: experimental
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\cmd.exe'
        CommandLine|contains: whoami
    filter:
        User: SYSTEM
    condition: selection and not filter
falsepositives:
    - Unknown
level: medium

Common problems

The converted query matches too much or too little

Check the field names against how your logs are mapped (a pipeline in your Sigma tooling renames fields), and prefer the specific match types over broad contains values.

I want a wildcard in the middle of a value

This builder treats values as plain text so nothing is matched by accident. Use contains, starts with or ends with, or split the value into two conditions.

It refuses my tag

Tags use the ATT&CK form: attack.execution for a tactic, or attack.t1059 and attack.t1059.001 for techniques and sub-techniques.

pySigma reports an escaped-wildcard warning

A literal star or question mark in a value is written with a backslash so it is not a wildcard, and pySigma notes that as a low-level hint. It is correct; use contains, starts with or ends with if you meant a wildcard.