Sigma Syntax Viewer

A Sigma rule's detection logic lives in two places that have to agree: the search identifiers under detection, and the condition that combines them. Reading the YAML tells you what each one contains. It does not tell you whether the condition actually uses them, which is the thing most worth knowing.

Declared is not the same as used

A selection the condition never names is not a syntax error. The rule is valid YAML, converts to a query, and quietly ignores that block — so a filter written to exclude signed binaries excludes nothing, and the rule fires on exactly the cases its author believed they had carved out. Every declared identifier is marked used or unused here.

Field modifiers are shown, not judged

|contains, |endswith, |re, |base64offset and the rest are split off the field name and displayed. They are deliberately not checked against a list of known modifiers: that list has grown across Sigma versions and differs by backend, so a tool that told you your working |expand was unknown would be asserting something it cannot support.

Values are not retyped

The parser resolves YAML 1.2's core schema, so 2026-09-19 stays the string you wrote rather than becoming a date object, and yes stays yes rather than becoming true. A viewer that silently changed a rule's value types would be showing you something other than your rule. Nothing is executed — the parser has no constructor for a function tag and rejects one outright.

The first sample is a complete rule: metadata, a logsource, a selection with two modified fields, a filter, and a condition that uses both.

The second is a rule with a third block, filter_admin, that the condition never mentions. Nothing about it looks wrong and it converts to a query without complaint — it simply does not exclude anything. Both rules are written for this page and describe a fictional scenario; they are illustrations of structure, not detection content.