SigmaHQ/sigma

A Sigma rule does not execute. It is a backend-agnostic description of a detection, compiled to a target query language — Splunk SPL, Elasticsearch, Sentinel KQL, and a few dozen others — by a converter before it runs anywhere.

That indirection is the whole point and the whole risk. The rule you read here is not the query that will run in your SIEM; the query depends on the backend and on the field mapping you give it. Two organizations deploying the same rule can end up with materially different searches.

YAML, with a stable shape:

title: DNS Query To Ufile.io
status: test
description: Detects DNS queries to "ufile.io" ...
tags:
    - attack.exfiltration
    - attack.t1567.002
logsource:
    product: windows
    category: dns_query
detection:
    selection:
        QueryName|contains: 'ufile.io'
    condition: selection
falsepositives:
    - DNS queries for "ufile" are not malicious by nature ...
level: low

• logsource — product, category and/or service. This declares what telemetry the rule assumes, and it is where most deployment failure lives: a rule is only as deployable as your ability to map its logsource onto your own data.
• detection — one or more named selections, plus a condition combining them with and/or/not, all of, 1 of. Field modifiers (|contains, |startswith, |re) do the matching work.
• level and status are declared explicitly rather than inferred, which is unusual across this index and makes Sigma one of the few sources where the status distribution on this page means something.

Whatever the compiled query matches in your backend. Sigma itself defines no threshold, no window and no aggregation beyond what the condition expresses.

falsepositives is a first-class field, and it is worth reading before deployment — the authors usually name the benign software that will trip the rule.

The rule's detection block is shown as its logic and falsepositives as tuning notes. ATT&CK comes from tags in attack.t1567.002 form, normalized to the technique IDs used across this site.

The index covers rules/ (3,132), rules-emerging-threats/ (457), rules-threat-hunting/ (139), rules-placeholder/ (17) and rules-compliance/ (3). Upstream's deprecated/ and unsupported/ directories are deliberately not ingested, so unlike some sources here, nothing in this ruleset is retired content.

• A Sigma rule is not portable for free. It looks universally applicable because it names no product, but converting it still needs a field mapping for your backend. "Supported by Sigma" is not "works in your SIEM".
• Rules under rules-placeholder/ contain values you are expected to replace with environment-specific ones. They will not work as shipped — that is by design, not a defect.
• status: test is by far the most common value here, not stable. It reflects SigmaHQ's review process rather than a judgment that the rule is unreliable.