Sigma rules are YAML-based, platform-independent detection definitions used to identify suspicious activity in log data. They standardize how events such as process creation, registry modification, or file access are described, enabling consistent detection across different SIEM platforms. Built for operational efficiency, Sigma rules help SOC teams automate threat detection, minimize false positives, and improve overall alert accuracy.
This blog is a hands-on guide to writing Sigma rules. It walks through a real example step by step, explaining how each part works and how to turn threat behaviors into effective, platform-independent detections.
To write a Sigma rule, start by defining the behavior you want to detect, then translate it into Sigma’s YAML format. A well-written rule clearly describes what to look for in logs, which data source to use, and how to minimize false positives.
Each Sigma rule follows a structured format that ensures it can be easily shared and converted for different SIEM or detection tools.
Header: Include essential metadata such as the title, description, author, and status. This section documents what the rule detects and who maintains it.
Log Source: Specify where the data comes from, including the product and service that generate logs. For example, a rule might target Windows logs collected by Sysmon.
Detection: Define the detection logic using three elements:
Fields: List which log fields should appear in alerts when the rule matches. This helps analysts quickly understand and investigate the event.
Tags: Add keywords and framework identifiers such as MITRE ATT&CK technique IDs. Tags make the rule easier to organize, search, and correlate with known threat behaviors.
A clear structure and precise detection logic are key to writing effective Sigma rules. Start with a specific adversary behavior, define the related log source, and build selections and filters that capture malicious activity while minimizing noise.
Sigma rules are the building blocks of modern detection engineering. They define suspicious activity in a simple, SIEM-agnostic format, a kind of “universal detection language” that helps security teams turn raw log data into actionable detections.
Let’s break down a real Sigma rule line by line to understand how it works and why each part matters.
|
title: Suspicious Outlook VbaProject.otm Creation/Modification |
These provide the first layer of context.
|
title: Suspicious Outlook VbaProject.otm Creation/Modification |
title: Gives a clear summary of what’s being detected.
description: Explains the detection logic and its relevance.
In this case, the rule detects the creation or modification of Outlook’s VbaProject.otm file, a known persistence vector used by threat actors.
The status field indicates the rule’s maturity.
|
status: experimental |
Including this helps SOC teams manage rule lifecycles.
author: Specifies who wrote or maintains the rule. Used for traceability, version tracking, and ownership within detection repositories.
references: Cites external technical sources, such as MITRE ATT&CK techniques (e.g., T1137.001, T1204.002) or threat research, to justify the detection logic and link it to documented adversary behavior.
|
author: Picus Security |
Together, these fields make Sigma rules transparent, verifiable, and machine-readable.
The logsource field defines where the Sigma rule should look for telemetry.
Here, the rule applies to Windows Sysmon logs, a powerful source of detailed system activity. Sysmon (System Monitor) records events such as process creation, file modification, network connections, and registry changes.
By specifying:
|
logsource: |
product: windows → The rule targets Windows operating systems.
service: sysmon → It focuses specifically on Sysmon event logs.
This setup ensures high-fidelity telemetry for detecting behaviors like the creation or modification of files in sensitive paths.
Detection logic is the core of a Sigma rule. This is where you define exactly what to match, what to ignore, and how to combine those conditions. It consists of three main parts:
selection: conditions that must be met (i.e., what to look for)
filter: conditions that must not be met (i.e., what to ignore)
condition: the logical expression that ties selection and filter together
|
selection: |
Here:
EventID: 11 refers to Sysmon Event ID 11, which tracks file creation or overwrite operations.
TargetFilename|endswith: '\Microsoft\Outlook\VbaProject.otm' means we are looking specifically for a file with that exact ending path, which corresponds to Outlook’s VBA project file. Threat actors may modify this file to achieve persistence or execute malicious macros.
|
filter: |
Here:
The filter excludes events where the Image (i.e., the process executable) ends with OUTLOOK.EXE, EXCEL.EXE, WINWORD.EXE, or POWERPNT.EXE.
These are legitimate Office processes; excluding them helps reduce false positive alerts when user-driven macro activity occurs normally.
|
condition: selection and not filter |
This defines the logic: the rule triggers when the selection criteria are true and the filter criteria are not true.
In plain English: “Raise an alert if Outlook’s VbaProject.otm file is created or modified by a process other than the standard Office executables.”
|
falsepositives: |
This section acknowledges safe operations that might still trigger alerts. It helps SOC analysts tune detections intelligently without weakening coverage.
|
level: high |
Severity level indicates the risk level.
“High” means this event is likely to represent a real persistence attempt and deserves priority review.
Tags connect detections to MITRE ATT&CK tactics (e.g., persistence, execution, defense evasion).
They improve searchability, reporting, and validation during CTEM assessments.
For example, a CTEM validation cycle can automatically verify whether detections like this one are firing correctly across relevant ATT&CK categories.
In a nutshell, Sigma rules provide the following benefits for simplifying and standardizing threat detection:
Continuous Improvement: Benefits from regular updates and community-driven enhancements.
As an open-source community project, Sigma rules enable security operations teams to write queries in a single, standardized format instead of vendor-specific SIEM languages. This means that one rule can be automatically translated into SIEM-specific code with a single click.
For example, the following Sigma rule detects suspicious modification of Windows Volume Shadow Copy Service (VSS) registry keys using esentutl.exe.
Adversaries often exploit this technique to create, modify, or delete shadow copies for data exfiltration or persistence. When converted, the rule would appear as follows in Microsoft Sentinel (Azure SIEM):
|
"displayName": "Detect VSS Registry Key Modification via Esentutl", |
And the same rule would automatically be translated into the following query for Splunk:
|
(index="windows" EventCode=13 TargetObject="*System\\CurrentControlSet\\Services\\VSS*" Image="*esentutl.exe*") |
In practice, this means that a detection created in Sigma format for one SIEM instantly becomes usable for all others, allowing SOC teams to share, adapt, and deploy threat detections universally, without ever rewriting a single line of logic.
The Picus Mitigation Library is a comprehensive repository of validated prevention and detection content that helps organizations strengthen and maintain their security posture.
Figure 1. Picus Platform Provides Both Prevention and Detection Content
It delivers tailored mitigation coverage for a wide range of security technologies, enabling teams to close exposure gaps quickly and effectively.
The library includes:
80,000+ vendor-specific prevention signatures tailored for security controls such as Next-Generation Firewalls (NGFWs), Intrusion Prevention Systems (IPS), and Web Application Firewalls (WAFs).
4,400+ validated vendor-specific detection rules and 600+ vendor-neutral Sigma rules for major SIEM and EDR technologies to detect endpoint and network-based attacks.
Figure 2. Picus Platform Detection Content Library
Log source recommendations to enhance visibility, optimize SIEM performance, and strengthen detection coverage across the environment.
Ready to put your defenses to the test and apply real-world mitigation?
Start your demo now to simulate attack scenarios, validate which controls stop threats, and instantly apply tailored mitigation suggestions through the Picus platform.