What Are Hunting Rules? Queries Too Noisy to Alert On

The category, defined

SigmaHQ's rules-threat-hunting/ folder holds 140 rules. The rules/ folder beside it holds 3,137. Both describe attacker behaviour in the same YAML format, against the same log sources, with the same field names. The split is not about quality. It is about what happens when a query returns 900 rows.

A hunting rule is a query that is too noisy to alert on and too valuable to run once. Three things separate it from an alerting rule, and none of them are the detection logic:

• Volume tolerance. An alerting rule that fires 40 times a day is broken. A hunting rule that returns 40 rows a week is working.

• The consumer. An alerting rule ends up in front of whoever holds the pager. A hunting rule ends up in a queue that somebody works on Tuesday afternoons.

• The success metric. An alerting rule is judged on precision. A hunting rule is judged on interesting findings per run, and a run that surfaces one misconfigured service account is a good run.

Sigma encodes the third point directly. Look at the falsepositives field on the hunting version of the net.exe rule:

falsepositives:
    - Likely
level: low

That is the whole entry. Not a list of exceptions to tune away, just an admission that the author expects noise and shipped the rule anyway.

What SigmaHQ puts in the hunting folder

The repository split into typed folders in May 2023: rules/, rules-threat-hunting/, rules-emerging-threats/, rules-compliance/ and rules-dfir/. The announcement names the actual variable:

During said activity the false positive appetite of the "hunter" is above the average "triaging analyst", hence why separating rules of such type is important from a detection pipeline and Sigma user perspective to set the right expectations.

Nasreddine Bencherchali, SigmaHQ blog, May 2023

Membership is machine-readable. All 140 rules in rules-threat-hunting/ carry the tag detection.threat-hunting, and exactly one rule outside the folder carries it. If your pipeline routes hunting content away from the alerting engine, that tag is the hook. You do not have to parse paths.

The severity distribution says the same thing. Across the 140 hunting rules there are 56 at low, 81 at medium, 2 at informational and 1 at high. There is no critical. In rules/ there are 1,420 at high and 72 at critical. Log source is skewed too: 61 of the 140 are process_creation, because command lines are where broad hypotheses are cheapest to express. Counts are from master at commit 1aacbedf7, 28 July 2026, and they move every week.

The same behaviour, twice

Here is a real pair: Excel loading an XLL add-in, written once for hunting and once for alerting. The hunting rule, rules-threat-hunting/windows/image_load/image_load_office_excel_xll_load.yml:

title: Microsoft Excel Add-In Loaded
id: c5f4b5cb-4c25-4249-ba91-aa03626e3185
tags:
    - attack.execution
    - attack.t1204.002
    - detection.threat-hunting
logsource:
    category: image_load
    product: windows
detection:
    selection:
        Image|endswith: '\excel.exe'
        ImageLoaded|endswith: '.xll'
    condition: selection
falsepositives:
    - The rules is only looking for ".xll" loads. So some false positives are expected with legitimate and allowed XLLs
level: low

Now the alerting rule, rules/windows/image_load/image_load_office_excel_xll_susp_load.yml:

title: Microsoft Excel Add-In Loaded From Uncommon Location
id: af4c4609-5755-42fe-8075-4effb49f5d44
related:
    - id: c5f4b5cb-4c25-4249-ba91-aa03626e3185
      type: derived
tags:
    - attack.execution
    - attack.t1204.002
logsource:
    category: image_load
    product: windows
detection:
    selection:
        Image|endswith: '\excel.exe'
        ImageLoaded|contains:
            - '\Desktop\'
            - '\Downloads\'
            - '\Perflogs\'
            - '\Temp\'
            - '\Users\Public\'
            - '\Windows\Tasks\'
        ImageLoaded|endswith: '.xll'
    condition: selection
falsepositives:
    - Some tuning might be required to allow or remove certain locations used by the rule if you consider them as safe locations
level: medium

What changed and why

Four things, and the ATT&CK technique is not one of them. Both rules are T1204.002.

1. One field was added, ImageLoaded|contains with six path fragments. That single key is the entire difference in matching. It turns "Excel loaded an add-in" into "Excel loaded an add-in from a directory a user can write to".

2. level went from low to medium, because the output is now small enough to route somewhere with an SLA.

3. The detection.threat-hunting tag was dropped, so a pipeline filtering on that tag stops excluding it.

4. A related: block with type: derived points back at the hunting rule's UUID. The lineage lives in the rule, not in a wiki.

What the hunting version catches and the alerting version misses: an XLL dropped into C:\ProgramData\, into a nested application directory, or into any path not on that list of six. An attacker who reads the list will not use it. What it costs: every legitimate add-in in the estate, on every Excel launch, forever. Neither rule sees loads that never reach image_load telemetry, which on Sysmon means anything your ImageLoad exclusions drop. That gap is invisible from the rule text.

The promotion path

Promotion is what happened to the XLL pair, and the related: derived link is the receipt. Across the repository, 33 hunting rules carry a related: link into rules/. Not all are promotions. Some are the same behaviour against a different log source, like the Linux and Windows Python path configuration file rules.

The RunMRU pair is cleaner. The hunting rule watches every value written under the run dialog's MRU key:

detection:
    selection:
        TargetObject|contains: '\Microsoft\Windows\CurrentVersion\Explorer\RunMRU'
    condition: selection and not 1 of filter_main_* and not 1 of filter_optional_*
level: low

The derived alerting rule keeps the key and adds scope: the value must contain powershell or pwsh together with one of -enc, iex, Invoke-, http, Hidden, or contain wmic together with shadowcopy or process call create. It ships at level: high and tags T1059.001. That scoping came from the fake CAPTCHA lures that talk users into pasting a command into the run dialog. Somebody ran the broad version, looked at what showed up, and wrote the narrow version from the results.

The sequence in practice:

1. Run the broad rule on a schedule for a few weeks.

2. Baseline what comes back. Not "tune it", baseline it. Write down what normal looks like in your estate.

3. Find the discriminator. In the XLL case it was write-permission on the source path.

4. Fork, do not edit. The broad rule keeps running. The narrow one goes to the alerting pipeline with a related: derived link back.

The demotion path

The opposite direction is more common and less discussed. Sigma's net.exe rule lived in rules/ from January 2019, first as win_susp_net_execution.yml. On 12 February 2024, in PR #4702, it moved:

R082  rules/windows/process_creation/proc_creation_win_net_susp_execution.yml
   -> rules-threat-hunting/windows/process_creation/proc_creation_win_net_execution.yml

The title lost the word "Suspicious". The detection logic barely moved. It still matches net.exe or net1.exe with a command line containing accounts, group, localgroup, share, start, stop, user or view. That is most of what net.exe is for, which is exactly the problem: net share and net user are attacker discovery and they are also every login script written since 2003.

The narrow rules that survived in rules/ show what tuning bought. Suspicious Group And Account Reconnaissance Activity Using Net.EXE requires group or localgroup plus a high-value group name (domain admins, enterprise admins, Exchange Trusted Subsystem, Remote Desktop Users), and excludes command lines containing /add so it does not fire on account creation. New User Created Via Net.EXE requires user and add together and maps to T1136.001.

Demotion is the honest end state for a rule that cannot be tuned. Deleting it destroys the hypothesis along with the noise. Moving it keeps the hypothesis, the references, the ATT&CK mapping and the UUID, and changes only who reads the output.

Most hunting rules never get promoted

Fewer than a quarter of the 140 hunting rules have a related: link into rules/ at all, and some of those are siblings rather than promotions. The rest sit there being broad forever.

That is the correct outcome, not a backlog. Some behaviours have no discriminator to find. net.exe execution is legitimate too often for any command-line pattern to split it, and no amount of baselining changes that. The rule still earns its place by being written down, versioned, mapped and runnable by an analyst on a Tuesday. Treat unpromoted hunting rules as work in progress and a team eventually deletes the ones that never graduate, which costs the hypothesis and gains nothing.

We measured this only on SigmaHQ's public repository, so treat the ratio as one open-source data point.

ATT&CK techniques referenced

Summary

A hunting rule is not a failed alerting rule. It is a different contract with a different reader: broader logic, a schedule instead of a pager, success measured in findings rather than precision. SigmaHQ makes that contract explicit through folder placement, the detection.threat-hunting tag, capped severity and related: derived links. Promotion happens when baselining turns up a discriminator you can name. Demotion is what you do instead of deleting a rule you cannot tune. A library where every rule eventually became an alert is a library that stopped asking questions.

Start at the broad end of the catalog. Low severity is roughly hunting-grade, and Windows is where the process creation hypotheses live. If the YAML above is unfamiliar, what Sigma rules are covers the format.

• Low severity rules

• Windows rules

Fields to collect before any of this is runnable:

process_creation   Image, OriginalFileName, CommandLine, ParentImage, User
image_load         Image, ImageLoaded, Signed, SignatureStatus
registry_set       TargetObject, Details, Image
sysmon config      verify ImageLoad (Event ID 7) is not excluded for office binaries
sigma tag          detection.threat-hunting  (route away from the alerting pipeline)