PermitANY
Tool · Security

Sigma Rule Builder

Fill the form, get valid Sigma YAML — and a review of the mistakes a converter will not tell you about. Nothing leaves your browser.

logsource — decide que pipeline aplica el backend

detection

rule.yml
title: 'Rundll32 executing a DLL from a user-writable path'
id: 5450364b-a442-470d-8f01-eba31fa3dc4d
status: experimental
description: 'Rundll32 loading a DLL from a temporary or user profile directory, a common proxy-execution pattern.'
date: 2026-11-02
tags:
    - attack.defense_evasion
    - attack.t1218.011
logsource:
    category: process_creation
    product: windows
    service: sysmon
detection:
    selection:
        Image|endswith: '\rundll32.exe'
    selection_path:
        CommandLine|contains:
            - '\AppData\Local\Temp\'
            - '\Users\Public\'
    condition: selection and selection_path
falsepositives:
    - 'Installers that legitimately stage a DLL in %TEMP%'
level: medium

1 note

  • ●"selection_path" tiene 2 valores: una LISTA es OR. Si querias que se cumplan todos, el modificador es |all.

Why a valid rule can still match nothing

Sigma converts to a backend query. A rule can be perfectly valid YAML, convert without a single error, and never fire — which is the worst failure mode in detection, because the dashboard looks healthy. The review panel flags the four that cause it most:

  • A condition that names a selection you did not define. Nothing in the YAML is wrong; there is simply no such block, so the converted query filters on nothing.
  • A list is OR, a map is AND. This is the single most misread thing in Sigma. Four values under one field match if any of them does. If you need all four, the modifier is |all — and |all on a single value does nothing at all.
  • A missing or wrong logsource. It is what decides which pipeline the backend applies when mapping field names. Without it, the fields never get translated to whatever your SIEM actually calls them.
  • Backend field names instead of Sigma taxonomy. process.executable is Elastic, Processes.process_name is Splunk CIM. Sigma uses the name the original log uses — Image, CommandLine — and the pipeline maps it. A rule written against one backend's names only ever works there.

Two more things the generator handles rather than leaving to you: the id is a UUID and is the rule's identity across versions, so it is generated once and not regenerated while you edit; and values are quoted with single quotes, because in double quotes a backslash is an escape and C:\Windows\System32\ would not survive.

On the condition field: it suggests, but it does not constrain. A condition is an expression language — not, parentheses, 1 of selection_*, all of them — so a closed dropdown would make half the real rules unwritable. The suggestions are generated from the selections you have defined right now, which makes them correct for this rule instead of generic. They also encode the convention that a block named filter* is excluded with not — using one to include does not break anything, and that is the problem: whoever reads the rule next will assume the convention and understand the opposite of what it does.

For writing the rule in the first place, the sigma-rule-builder prompt turns a technique into a draft with its tuning plan. To check rules you already have, in bulk, sigma-rule-validator runs the same class of checks over a directory. And detection-engineering covers measuring the noise before you deploy.