What Is HuntRule? A Sigma Rule Catalog for Detection Engineers

git clone https://github.com/SigmaHQ/sigma gives you every rule and almost none of what you need to deploy one.

git clone https://github.com/SigmaHQ/sigma
find sigma/rules -name '*.yml' | head -3

You get title, logsource, detection, level and a falsepositives list that is often one word long. What you do not get is whether your Sysmon config already emits the event the rule reads, what you have to switch on if it does not, what the rule quietly misses, and what the last change to it was. That gap is the reason HuntRule exists.

What the catalog is

HuntRule is a browsable catalog of Sigma rules at /rules, where every rule carries a written layer on top of the YAML. One format. Sigma only. The format column is CHECK-constrained to 'sigma' in the database and the shared format vocabulary has exactly one entry, so nothing else is stored.

Rules are grouped by a closed nine-value domain vocabulary rather than free tags:

windows, linux, macos, cloud, network, web, identity, email, container

Severity mirrors Sigma's own level: informational, low, medium, high, critical.

The fields that make a rule deployable

Take a process-creation rule for rundll32 executed with no DLL on the command line. As Sigma, it is short:

title: Rundll32 execution without a DLL argument
status: test
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\rundll32.exe'
  filter_dll:
    CommandLine|contains: '.dll'
  condition: selection and not filter_dll
level: high
tags:
  - attack.defense-evasion
  - attack.t1218.011

That is a rule you can read. Here is the record around it, which is a rule you can decide about:

summary                 one-paragraph plain-English statement of the behaviour
description             the Sigma description field
severity                high
primary domain          windows
logsource               product: windows / category: process_creation
telemetry requirements  Sysmon Event ID 1, or Security 4688
prerequisites           4688 carries no CommandLine unless command-line
                        auditing is enabled in policy
limitations             blind to rundll32 launched where process command
                        lines are not collected at all
false positives         installers and control panel applets that invoke
                        rundll32 with non-DLL arguments
MITRE techniques        T1218.011 System Binary Proxy Execution: Rundll32
threat entities         linked malware, campaigns, actors, tools, CVEs
changelog               per-version, written on the version that changed it
license                 drl-1.1
attribution             <upstream author> (SigmaHQ), DRL 1.1

Telemetry requirements and prerequisites are separate fields on purpose. Telemetry says which event stream the rule reads. Prerequisites say what has to be true of your configuration before that stream contains the fields the detection references. A team that is shipping Security 4688 without command-line auditing turned on will deploy the rule above and see nothing, forever, with no error anywhere. That is the difference the metadata is there to close.

Limitations and false positives are also separate. Limitations are what the rule never sees. False positives are what it sees and should not have. Tuning work goes to one, coverage work goes to the other, and collapsing them into a single "notes" blob is how both get skipped.

Threat entities are typed links, not text: malware, campaign, actor, tool, vulnerability. MITRE technique links carry their tactics through a join table, so a technique on a rule is the real ATT&CK entry rather than a string in a tag.

Where the rules come from, and the license

The bulk of the catalog is synced from SigmaHQ. That is one configured source: url https://github.com/SigmaHQ/sigma, kind git_sigma, publisher SigmaHQ, crawl interval 1440 minutes.

Every rule the sync ingests is written with fixed terms:

{
  "origin": "sigmahq",
  "accessTier": "free",
  "license": "drl-1.1",
  "attribution": "<upstream author> (SigmaHQ), DRL 1.1"
}

This is structural, not editorial. A database CHECK constraint refuses any rule whose origin is not huntrule unless it carries both a license and an attribution, and a community-origin rule must be free. So a SigmaHQ-derived rule cannot exist in the catalog without DRL 1.1 named on it, and the sync writes accessTier: "free" as a fixed term, so it is not put behind a wall. If you want to know what you are allowed to do with a rule you copied out of the page, the answer is on the page.

The sync is delta-only. It classifies added, modified and deleted files with a git diff against the last synced commit, so a rule gets a new version only when its content actually changed under a known Sigma id. Identical content re-syncs to nothing. When an upstream rule disappears from the repository, the matching rule is marked deprecated and the page renders a deprecation notice rather than quietly vanishing.

One honest note on ordering. Sorting by newest orders on publishedAt, and for synced rules that is the upstream rule's own date: field, not the day we ingested it. If you want recently touched records, use ?sort=updated.

Filters, and what they match

The catalog list accepts exactly these parameters: q, domain, format, severity, tier, sort, page. Page size is 20.

/rules?domain=windows
/rules?severity=critical
/rules?tier=free
/rules?domain=cloud&severity=high
/rules?q=powershell
/rules?sort=updated

q is matched against title and summary only. It does not search detection bodies, so a search for a field name or a registry path will not find rules by their logic. Knowing that up front saves you concluding the catalog has no coverage when what you ran was the wrong query.

The same projection is available as JSON at https://huntrule.com/api/rules and https://huntrule.com/api/rules/<slug>. Both are public and unauthenticated. Neither returns rule bodies, and the JSON endpoint accepts q, domain, format, severity, sort and page but not tier.

Anonymous, signed in, paid

An anonymous visitor gets the whole reading surface. Every filter, and on a rule page: summary, description, MITRE techniques, threat entities, telemetry requirements, prerequisites, limitations, known false positives, changelog, severity, license and attribution. No account, no wall on any of that. The only thing an anonymous visitor cannot see is the detection body of a rule marked paid, and every SigmaHQ-synced rule is free.

Signing in with Google adds a dashboard, saved rules, and a my-rules view with two tabs: Unlocked and Saved. The catalog is not duplicated there. Saving a rule is a reading list, not a copy.

Paid rules are opened one at a time by an unlock, and an unlock is permanent for that rule. Re-opening it later, including at a newer version, costs nothing. Plan allowances are on /pricing: 20 unlocks per month on Pro, 40 per seat per month on Team.

Getting a rule out is per-rule. The rule page has Copy and Download buttons, both operating on the body already rendered on the page, producing a single <slug>.yaml.

What this is not

The scope is narrow on purpose, and it is easier to say so than to have you find out by clicking.

• No conversion to Splunk SPL, Elastic, or Sentinel KQL. Sigma goes in, Sigma comes out. Your own pipeline does the backend conversion.

• No rule packs, bundles or curated sets. Downloads are one rule at a time.

• No bulk export of the catalog. The JSON list is paginated and contains no rule bodies.

• No YARA or Suricata rules.

• Correlation rules and filter rules are rejected by the parser as outside the supported subset, along with YAML anchors and aliases.

If you want the format itself explained before the catalog is useful to you, start with what a Sigma rule is.

Summary

HuntRule is a Sigma catalog whose unit of value is the metadata around each rule rather than the rule text, which is already public. Telemetry requirements, prerequisites, limitations, known false positives, MITRE mapping, threat entities, changelog and license sit on every record, and the SigmaHQ origin carries DRL 1.1 attribution as a database constraint rather than as a policy. Reading is open to anonymous visitors in full. One format, one direction, no conversion.

Start here:

https://huntrule.com/rules
https://huntrule.com/rules?domain=windows
https://huntrule.com/rules?tier=free
https://huntrule.com/api/rules