WRG Sigma Rules is an MCP server for authoring, validating, and converting Sigma detection rules, with a published rule corpus and coverage resources.
draft_rule: generate a Sigma YAML scaffold from a natural-language threat description, with optional title, severity, platform, MITRE TTPs, and references.
validate_rule: check Sigma YAML for schema correctness, pySigma compatibility, and best-practice linting; strict=True promotes warnings to errors.
convert_rule: compile Sigma rules to Splunk SPL, Elastic/Kibana Lucene, Elastic ES|QL/EQL, OpenSearch Lucene/PPL, and a Wazuh target that returns Elasticsearch Lucene with warnings.
Access a corpus of 294 rules across 16 MITRE ATT&CK tactic/category directories, including template_* and observed_* rules.
Read MCP resources such as canonical detection patterns and an ATT&CK coverage matrix computed from the corpus.
Use it in Claude Code, Codex, Cursor, or any MCP-capable stdio client.
Sigma detection-rule authoring, validation and multi-backend conversion, delivered as a Model Context Protocol (MCP) server with a published rule corpus. It runs under Claude Code, Codex, Cursor and any MCP-capable client.
draft_rule turns a natural-language description into a Sigma YAML scaffold.
validate_rule checks a rule against pySigma plus a best-practice linter.
convert_rule compiles a rule to a Splunk, Elastic, OpenSearch or Kibana query.
The corpus holds 294 rules in 16 categories. It covers ransomware and threat-actor activity as well as vulnerabilities disclosed in AI/LLM applications and MCP servers.
git clone https://github.com/WRG-11/wrg-sigma-rules.git
cd wrg-sigma-rules
pip install -r requirements.txt
claude plugin marketplace add .
claude plugin install wrg-sigma-rules@wrg-11That installs the server as a Claude Code plugin. Codex, Cursor and other MCP clients
take the same server; docs/install.md has the steps for each and the
notes on which interpreter runs it. Captured output from the tools is in
DEMO.md.
The plugin is installed directly from this repository, which is also its own Claude Code and Codex marketplace; it is not yet listed in Anthropic's plugin directory.
Related MCP server: Wazuh SIEM Agent System
There are three Claude Code skills: sigma-rule-writer, sigma-rule-reviewer and
threat-coverage-gap-analyzer. The packaged Codex variants retain the same
evidence boundaries: coverage counts do not establish missing ATT&CK scope,
conversion does not establish deployed semantics, and observed_* public
contributions require the sourcing bar in CONTRIBUTING.md.
Conversion runs on pySigma 1.x and targets Splunk SPL, Elastic and Kibana Lucene,
Elastic ES|QL and EQL, OpenSearch Lucene and PPL, plus a wazuh target that
reuses the Elasticsearch Lucene backend and says so in its warnings. The
Lucene-family targets cannot express Sigma correlation rules, so convert_rule
reports the
correlation rules in the corpus as a capability gap and names the backends that
can convert them (esql and eql are the Elastic route).
Correlation conversions say where the query stops meaning the rule. Valid syntax
is not the same rule: measured on the pinned backends, opensearch-ppl drops the
time window of every count correlation, and eql turns a distinct-value count
into a join on one repeated value. Each correlation result carries
correlation_semantics, the deviations the converter checks for (dropped or
fixed window, unenforced order, threshold one short); see
Demo 5.
Validate and convert a corpus rule end to end, from the repo root:
pip install -r requirements.txtimport sys, json
sys.path.insert(0, '.')
from tools.validate_rule.validate_rule import validate_rule_body
from tools.convert_rule.convert_rule import convert_rule_body
rule = open('resources/examples/command_and_control/observed_mini_shai_hulud_npm_supply_chain_c2_t1071.yml', encoding='utf-8').read()
print(json.dumps(validate_rule_body(rule), indent=2))
print(json.dumps(convert_rule_body(rule, target='splunk'), indent=2))
print(json.dumps(convert_rule_body(rule, target='elasticsearch'), indent=2))Full captured output (validate JSON, Splunk SPL, Elasticsearch Lucene) is in
DEMO.md.
Every rule lives under resources/examples/<tactic>/: one directory per MITRE ATT&CK
Enterprise tactic (v19 names) plus code_review for source-code review rules. Each rule
is one of two kinds:
template_*: a canonical detection shape to adapt to your own environment.
observed_*: derived from a specific, cited incident. CONTRIBUTING.md sets
the bar these must clear.
resources/examples/INDEX.json enumerates every
rule, and the wrg-sigma://coverage/mitre-attack-matrix resource computes the
technique-by-tactic breakdown from the corpus at read time. Some rules add a
prose write-up under docs/detection-notes/.
This corpus uses Sigma's status: field literally rather than aspirationally:
| Count | Meaning here |
| 46 | Mostly |
| 248 | Both |
| 0 | Unused, deliberately |
stable in the Sigma specification means a rule runs in production and is well
tested. Nothing here has earned that, so nothing claims it. Treat every rule as a
starting point to bind to your own logsource and tune; each rule's
falsepositives: block names the benign activity to expect first.
wrg-sigma://patterns/canonical-5 and wrg-sigma://patterns/canonical-5/{01..05}:
canonical detection-pattern definitions.
wrg-sigma://coverage/mitre-attack-matrix: an ATT&CK coverage rollup computed
from the corpus at read time. Its Rules-content SHA-256 identifies the
exact corpus bytes behind a count, so installed and checkout runtimes can be
compared without treating different releases as measurement drift.
modules cover rule validation and tool-integration smoke tests.
pySigma 1.x compatibility is verified against the Splunk, Elasticsearch and OpenSearch backend packages.
CI runs the full suite on Ubuntu, Windows and macOS runners on every push to
main and every pull request against it.
The Docker CI smoke exchange compares the container coverage resource's corpus fingerprint with the checked-out corpus, so an otherwise healthy image cannot silently serve stale rule data.
README counts are stamped from ground truth: a test runs the same check as
python readme_stamp.py --check and fails CI on any drift, so the numbers here cannot silently go stale.
python scripts/runtime_identity.py --runtime-root <runtime-path> --expect-same-as . compares an installed Codex runtime with this checkout
without modifying either.
These local reports make review queues and conversion boundaries visible. They
are advisory: none promotes a rule, proves an actor attribution, or replaces
reading the cited source.
docs/evidence-review-audits.md lists the
commands and describes each report, its --json output and what its numbers
do and do not establish.
Contributions are welcome. Add YAML under resources/examples/<tactic>/ with an
ATT&CK mapping in tags: (for example attack.t1071), the observed_* or
template_* prefix, and a passing validate_rule. Corpus CI rejects broad empty
matches, unsafe regex, unroutable logsource blocks, draft scaffolding and
deprecated aggregation-pipe syntax.
Read CONTRIBUTING.md before submitting an observed_* rule.
It sets the sourcing bar (attribution, platform and manifestation, each matched
against the cited source) and documents the three upstream rejections that
produced it.
WRG Sigma Rules is a local, deterministic detection-engineering workbench. It helps an MCP-capable client draft, validate and convert Sigma rules; it does not deploy detections, collect telemetry, operate a hosted service, or claim that a generated rule is production-ready.
Out of scope:
A hosted multi-tenant MCP service or remote telemetry collection.
Automatic deployment or activation of generated detections.
Marking generic public rules stable without production evidence.
Growing the corpus with uncited, duplicate or merely plausible detections.
MIT; see LICENSE. One license covers both the tooling (server.py,
tools/, scripts/) and the corpus (resources/). That is a deliberate choice
for frictionless reuse by SOC teams adapting a rule into their own tooling, over
the attribution-preserving split that some Sigma corpora use.
Runtime dependencies bring in LGPL-2.1/3.0 packages (pySigma and its backends)
alongside MIT, BSD and Apache ones. Importing an LGPL library does not make this
repo's own code LGPL. The dependency-licenses CI job carries the re-derivable
list.
mcp-objauthz-lab: a vulnerable-by-design MCP server for learning BOLA and IDOR.
osint-trust-envelope: trust envelopes for OSINT results.
Full index at github.com/WRG-11.
Convert a sigma YAML rule into a SIEM-native query string.
Use when the caller has a validated sigma rule and needs the equivalent query for Splunk SPL, Elasticsearch / Kibana Lucene, or Wazuh. Returns the primary converted query plus conversion lossiness warnings (e.g. unsupported modifiers). Missing pySigma or missing backend packages return actionable error envelopes with the exact pip install command.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml_content | Yes | ||
| target | No | splunk | |
| config | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses successful output (converted query + warnings) and failure modes (missing pySigma or backend packages yield actionable pip install commands). Does not discuss auth or rate limits, but these are irrelevant for a conversion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and uses a clear structure: purpose, usage, details. It is concise with three sentences, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema (not shown), the description covers purpose, usage, primary output, and error handling. It lacks parameter explanations but is adequate for a simple conversion tool when combined with the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only implicitly associates yaml_content with the sigma rule and target with backend names, but does not explain the config parameter or enumerate target options. It adds limited semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it converts a sigma YAML rule to a SIEM-native query string, specifying three target backends. It distinguishes from sibling tools 'draft_rule' and 'validate_rule' by focusing on conversion rather than drafting or validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the caller has a validated sigma rule' and lists target SIEMs. Does not explicitly exclude alternatives, but the context is clear. Mentions return of conversion warnings and error envelopes for missing dependencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draft a sigma detection YAML rule from a natural-language threat description.
Use when the caller needs a starting-point sigma rule and only has a plain-English threat summary plus optional MITRE TTP hints. Returns a structured envelope with the YAML body, a pySigma round-trip validation result, the inferred MITRE technique IDs, and draft notes covering redactions + open issues. Tool is deterministic and local -- no network, no LLM call.
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | ||
| rule_type | No | process_creation | |
| references | No | ||
| target_platform | No | windows | |
| severity | No | medium | |
| mitre_ttps | No | ||
| title | No | ||
| author | No | WRG sigma-rule-writer |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: deterministic, local, no network or LLM call, and describes the return envelope contents. No annotations are provided, so the description carries the transparency burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It efficiently communicates usage context and behavior without unnecessary words, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters (1 required) and no schema descriptions, the description adequately covers the main input and optional MITRE hints but lacks detail on other parameters. The output schema is mentioned, which adds completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains the 'description' and 'mitre_ttps' parameters. Other parameters like rule_type, references, target_platform, severity, title, and author are left unspecified, requiring inference from defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drafts a sigma detection YAML rule from natural language, distinguishing it from sibling tools convert_rule and validate_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when a starting-point sigma rule is needed from a plain-English threat summary. Does not mention when not to use or discuss alternatives explicitly, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a sigma YAML rule for schema correctness, pySigma compatibility, and best-practices linting.
Use when the caller has a sigma rule (drafted, pasted, or
read from disk) and needs to know whether it is parseable, spec
compliant, and free of common quality smells (empty references,
missing falsepositives, missing MITRE tag, vague condition).
``target_backend`` is informational at this layer; the linter is
backend-agnostic. ``strict=True`` promotes warnings into the
error list.
| Name | Required | Description | Default |
|---|---|---|---|
| yaml_content | Yes | ||
| target_backend | No | default | |
| strict | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes specific checks (empty references, missing falsepositives, missing MITRE tag, vague condition). It also notes strict mode behavior and that target_backend is informational. No side effects mentioned but no destructive hints either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at ~80 words, front-loaded with purpose. Every sentence adds value. No repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (not shown), return values need not be explained. Description covers validation specifics, sibling differentiation, and parameter roles. Could briefly mention that it returns a list of issues, but output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates. It explains yaml_content is the rule to validate, target_backend is informational, and strict promotes warnings to errors. Adds meaningful context beyond bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates sigma YAML rules for schema correctness, pySigma compatibility, and best-practices linting. It distinguishes from siblings (convert_rule, draft_rule) by focusing on validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are given (rule drafted, pasted, or read from disk). It mentions when to use it: to check parseability, spec compliance, and quality. Does not explicitly state when not to use it but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0convert_ruledraft_rulevalidate_ruleScored across 3 tools
Each tool has a clear, non-overlapping purpose: drafting, validating, and converting Sigma rules. There is no ambiguity between them.
All tool names follow the consistent verb_noun pattern (convert_rule, draft_rule, validate_rule), making them predictable and easy to understand.
Three tools perfectly cover the core lifecycle of Sigma rules (create, validate, convert) without being too few or excessive.
The tool set provides a complete workflow for handling Sigma rules: drafting from description, validating for correctness, and converting to SIEM queries. No obvious gaps exist.
55 tools, 7 Resources, Sigma rules, email SPF/DMARC, MITRE, CVE/KEV, risk_score. No key.
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
Zero-install security baseline for AI coding agents — OWASP/CWE-cited rules over MCP.
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
