Sigma Rule Generator

Creating a Sigma rule with this tool takes approximately 5 minutes. Here is a complete step-by-step walkthrough, including guidance on making effective choices at each configuration step.

Step 1 — Choose a Detection Template (Optional)

Start by selecting one of the four built-in detection templates if your use case matches a common scenario:

Selecting a template pre-populates the Rule definition fields with sensible defaults. You can override any field after selecting a template. If your use case doesn't match a template, leave the template unselected and fill in all fields manually.

Step 2 — Write Your Title

The title appears as the human-readable name for the rule in your SIEM and in any rule repositories where you publish it. Follow these conventions for professional-quality titles:

Step 3 — Write Your Description

The description field is your opportunity to explain what the rule detects, why it matters, and what an analyst should investigate when it fires. A good description reduces mean time to respond (MTTR) because the analyst doesn't need to reverse-engineer the rule logic to understand the alert.

Description template:

Detects [specific behavior] on [platform/log source] which may indicate 
[attack technique or threat actor behavior]. Investigate [what to look at] 
and check for [related indicators].

Example:

Detects use of PowerShell DownloadString method in command-line arguments, 
which is commonly used in download cradle techniques to pull and execute 
payloads from remote URLs. Investigate the source URL and parent process. 
Check for lateral movement or staged payload delivery.

Step 4 — Select Your Log Source

The log source defines which platform and log category the rule applies to. This is one of the most important fields in a Sigma rule because it determines which events the rule is evaluated against during SIEM conversion:

Choosing the right log source is critical. A rule with product: windows will not match Linux auth logs, even if the detection keyword appears in both. If you need to detect the same behavior across multiple platforms, create separate rules for each log source.

Step 5 — Set Severity Level

Choose the severity level that reflects how urgently this rule should be triaged when it fires. The severity field maps to alert priority in most SIEMs:

Calibrating severity honestly: Most new detection rules should start at medium or low until you have observed their false positive rate in your environment. Setting everything to high or critical causes alert fatigue and trains analysts to ignore severity levels.

Step 6 — Select the Detection Field

The detection field specifies which field in the log event the keyword will be matched against. Choosing the right field determines whether the rule will actually fire on the events you're targeting:

Field availability depends on your log collection configuration. CommandLine enrichment requires Windows Security audit policy 4688 with command line logging enabled, or Sysmon Event ID 1. Without the right logging configuration, rules targeting these fields will never fire even if the attack occurs.

Step 7 — Enter Your Detection Keyword

This is the string that will be searched for in the selected detection field using a contains match. The generated rule will use the |contains modifier, which performs a case-insensitive substring match.

Avoid keywords that are too broad. A keyword like powershell in the CommandLine field will match virtually every PowerShell execution in your environment and generate enormous false positive volume.

Step 8 — Add MITRE ATT&CK Tags

Enter MITRE ATT&CK technique IDs as comma-separated values. The tool formats them correctly as attack.tXXXX.XXX in the generated YAML. Tagging rules with ATT&CK techniques enables:

• Coverage mapping in tools like MITRE ATT&CK Navigator

• Automatic technique enrichment in SIEMs that parse Sigma tags

• Filtering and grouping rules by tactic or technique in rule repositories

Tag format examples

You can include both tactic-level tags (e.g., attack.execution) and technique-level tags (e.g., attack.t1059.001) in the same rule for maximum discoverability.

Step 9 — Review the Live YAML

As you fill in the form fields, the YAML preview updates in real time. Review the complete output for:

• Correct field indentation (YAML is whitespace-sensitive)

• Logical accuracy of the detection block

• Appropriate severity for your environment

• Presence of the stable rule UUID (id field)

Step 10 — Copy and Export

Click "Copy YAML" to copy the rule to your clipboard. From there you can:

The Rule ID: The UUID in the id field remains stable until you click the refresh button. Never change a rule's id after it has been deployed — it is the stable identifier used for rule management, deduplication, and versioning across rule repositories and SIEM platforms.