# Sigma rule matcher

Run Sigma detection rules against parsed Windows event JSON, filter by severity/status, and return report, table or JSON detections.

## Run it

- **CLI:** `gizza tool sigma-rule-matcher "title: Encoded PowerShell
level: high
detection:
  sel:
    EventID: 4104
    ScriptBlockText|contains: '-enc'
  condition: sel" 'events=[{"EventID":4104,"ScriptBlockText":"powershell -enc SQBFAFgA"}]'`
- **Web:** https://gizza.ai/tools/sigma-rule-matcher/
- **Agents:** machine-readable descriptor (parameters JSON Schema) at https://gizza.ai/tools/sigma-rule-matcher/tool.json

## Inputs

- `rules` — Sigma rules (YAML) _(field)_
- `events` — Parsed events (JSON array or NDJSON) _(field)_
- `min_level` — Minimum level _(field)_
- `status` — Rule status _(field)_
- `output` — Output _(field)_
- `max_matches` — Max matches shown _(field)_
- `show_event` — Include full matching event _(field)_

## Output

- Result (text)

## Query parameters

Open the tool pre-filled and auto-run via URL:

- `rules` — Sigma rules (YAML)
- `events` — Parsed events (JSON array or NDJSON)
- `min_level` — Minimum level
- `status` — Rule status
- `output` — Output
- `max_matches` — Max matches shown
- `show_event` — Include full matching event

Example: `https://gizza.ai/tools/sigma-rule-matcher/?rules=title%3A%20Encoded%20PowerShell%0Alevel%3A%20high%0Adetection%3A%0A%20%20sel%3A%0A%20%20%20%20EventID%3A%204104%0A%20%20%20%20ScriptBlockText%7Ccontains%3A%20%27-enc%27%0A%20%20condition%3A%20sel&events=%5B%7B%22EventID%22%3A4104%2C%22ScriptBlockText%22%3A%22powershell%20-enc%20SQBFAFgA%22%7D%5D&min_level=any&status=any&output=report&max_matches=500&show_event=true`

---

## About this tool

Sigma rules are portable detection rules used by security teams to describe suspicious Windows activity. This matcher lets you paste one or more Sigma YAML rules and already-parsed Windows event records, then see which events match without uploading data or running a SIEM backend.

Use it after an EVTX-to-JSON step, while developing a rule, or when you need a quick triage pass over a small set of event records. The output can be a readable report, a Markdown table, or structured JSON for another tool.

### Worked example

Rules:

```yaml
title: Encoded PowerShell
level: high
detection:
  sel:
    EventID: 4104
    ScriptBlockText|contains:
      - '-enc '
      - '-EncodedCommand'
  condition: sel
```

Events:

```json
[{"EventID":4104,"ScriptBlockText":"powershell.exe -enc SQBFAFgA"}]
```

Result: one high-severity detection, with the matching rule title and event index in the report.

### Limits and model fit

This tool evaluates parsed JSON events, not raw `.evtx` files. It implements common Sigma detection selections, modifiers, and condition expressions, but intentionally skips aggregation/correlation rules, bundled rule-set updates, backend query conversion, and filesystem directory scans. Inputs are capped at 1 MiB of rule YAML, 8 MiB of event JSON, 500 rule documents, 50,000 events, and 10,000 displayed matches.

<details>
<summary>Can this read raw Windows EVTX files?</summary>

No. Feed it JSON that was already parsed from EVTX. Keeping EVTX parsing separate makes this matcher deterministic and browser-local instead of mixing binary log decoding with rule evaluation.

</details>

<details>
<summary>Which Sigma features are supported?</summary>

The matcher supports common detection maps, list values, keyword searches, wildcards, `contains`, `startswith`, `endswith`, regex, CIDR, numeric comparisons, `exists`, `fieldref`, `all`, case-sensitive matching, base64/UTF-16/wide encodings, windash variants, and condition expressions with `and`, `or`, `not`, parentheses, and `1 of` / `all of` selection groups.

</details>

<details>
<summary>What happens to unsupported rules?</summary>

Unsupported rule documents are skipped with a reason in the report instead of being silently treated as no-match. Correlation and aggregation rules are listed as unsupported because they need stateful windows or backend pipeline context.

</details>

<details>
<summary>Why do some event fields match even when nested?</summary>

Real Windows event JSON often nests fields under `Event`, `System`, `EventData`, `UserData`, `winlog`, or `data`. The matcher searches exact keys, case-insensitive keys, dot paths, and those common containers so common EVTX-shaped JSON works without a separate field-mapping file.

</details>

## Related tools

- [Hash Identifier](https://gizza.ai/tools/hash-identifier/): Paste a hash and instantly identify its likely algorithm — bcrypt, Argon2, MD5, SHA-1/256/512, NTLM, sha512crypt, PHPass and more. Runs entirely in your browser.
- [Decode otpauth-migration exports](https://gizza.ai/tools/otpauth-migration-decoder/): Decode an otpauth-migration export payload into standard otpauth provisioning URIs, offline.
- [URL Safety Inspector](https://gizza.ai/tools/url-safety-inspect/): Paste a URL to rate phishing risk from structural heuristics: IP hosts, @ tricks, deep subdomains, punycode and lookalike TLDs. Runs locally.
- [Validate a PEM certificate chain offline](https://gizza.ai/tools/cert-chain-validate/): Check a pasted PEM certificate chain offline for leaf-to-root ordering, signature linkage and expiry windows.
- [AES cipher](https://gizza.ai/tools/aes-cipher/): Encrypt or decrypt text with AES in CBC, CTR, GCM or ECB mode and 128/192/256-bit keys, with hex/base64 I/O — in your browser. Nothing is uploaded.