Running Sigma rules in shadow mode before they page anyone

Anyone who has switched on a detection pack in one go remembers the next morning. Hundreds of alerts, most of them about the backup job, the vulnerability scanner and the admin who logs in from a new laptop. By the end of the week the team has learned to skim the queue, which is exactly the habit an attacker needs.

The rules aren't the problem. The SigmaHQ community writes excellent detections, but it writes them for everybody's environment, and yours has its own scripts, tools and habits. A rule needs to meet your data before it meets your pager. In Threat detection, that is what shadow mode is for.

What ships in the pack

The Sigma core pack holds 3,665 SigmaHQ rules from one pinned SigmaHQ release, covering 170 MITRE ATT&CK techniques. By SigmaHQ's own levels, 174 are critical, 1,661 high, 1,470 medium, 332 low and 28 informational. Most come from SigmaHQ's main rule set; 465 cover emerging threats, and 140 are threat-hunting rules, written for hunting rather than alerting.

Every rule keeps its original YAML and its author, and an alert from a SigmaHQ rule shows the author and the rule's license, the Detection Rule License 1.1. Pack rules install turned off: none of them runs until you choose it.

Three stages

Each rule sits at one of three stages, and each stage decides what happens to a match:

Rules that SigmaHQ itself marks experimental or test start at Test. The others start as drafts.

What shadow mode actually does

A rule at the test stage runs as a monitor, exactly like it would in production: same query, same schedule, same data. The difference is that Tracix treats a shadow monitor like one under a permanent downtime. Every match is evaluated and recorded as an alert, and every path out of the alert is cut:

• no notification to the monitor's channels, and no notification policy match;
• no page through an escalation policy;
• no problem correlation and no automatic case;
• no triage or investigation by the SOC agents;
• no playbook.

What you get instead is evidence. The rule's Shadow hits · last 24 hours panel lists what it matched, and Security › Alerts keeps every shadow alert in its own Shadow lane, out of the queues analysts work from.

The detail we care most about is what happens at promotion. An alert recorded during the test stage stays quiet for its whole life, even if it is still open when you promote the rule. Only matches that start after promotion notify anyone. Promoting a rule never replays its test period as an alert storm.

Before shadow: can the rule see anything?

A rule that can't see its data is worse than no rule, because it looks like coverage. So before a rule runs at all, Tracix checks the plumbing.

Every Sigma rule names a log source, such as Linux process creation or a firewall. Tracix routes each log source to the data in your workspace that carries it. A rule whose log source has no route is saved switched off, with the reason, and can't be enabled until something routes it. Open a rule to see the fields it reads, with unmapped ones flagged, and select Check log source (24h) to see whether its source sent anything in the last day.

Then backtest it. A backtest replays the rule over the last 24 hours, 7 days or 30 days of your data, with its exceptions applied, and shows how many events and entities it would have matched. A pack rule that would have fired 4,000 times last week tells you what you need to know before it runs once.

A rule, start to finish

Take a simple rule. This one is our own example, not a SigmaHQ rule:

title: Local user account created
id: 2150f1d2-7bc6-41d6-9976-1330d0878d72
status: experimental
description: Detects useradd or adduser creating a local account on a Linux host.
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    Image|endswith:
      - '/useradd'
      - '/adduser'
  condition: selection
falsepositives:
  - Configuration management and provisioning scripts
level: medium
tags:
  - attack.persistence
  - attack.t1136.001

Creating local accounts is a classic persistence step. It is also what every provisioning tool does when it sets up a service account, which is the false positive the rule itself warns about.

1. Check the source. With the Linux Endpoint Security integration, the collector sends process events that Sigma's Linux rules read without any mapping. Check log source (24h) confirms events are arriving.
2. Backtest. Over seven days, the rule matches a burst every time your provisioning runs. Now you know before anyone is paged.
3. Promote to test. Select Promote to test. The rule runs in shadow and its hits collect in the Shadow lane.
4. Tune. Add an exception in the rule's exceptions editor, or reference a value list, for the hosts or parent processes your provisioning uses. Test the edited exceptions against the last 24 hours before you save.
5. Watch. Give it a week of normal operations. What remains in the shadow lane should be things you'd want to know about.
6. Promote to production. Select Promote to production and confirm. From now on, new matches notify through your notification policies and reach the SOC agents.

Every stage move, like every edit, is a new version of the rule. Its history shows what changed, and can restore an earlier version. Demote to test sends a rule back into shadow if it starts misbehaving.

One switch to watch

The rule list has an on and off switch for each rule. Turning a draft rule on with that switch runs it in production straight away, skipping shadow mode. That suits a rule you have already tuned elsewhere. For anything new, open the rule and use Promote to test.

Your own rules get the same treatment

Shadow mode isn't only for the pack. Import rules takes Sigma YAML pasted or uploaded, YAML files from a Git repository, and a translation of supported Splunk SPL and Microsoft Sentinel KQL query shapes into Sigma, with warnings for what it can't translate. Every import goes through the same review: whether each rule compiles, which fields are unmapped, whether its log source sent data in the last 24 hours, and an optional backtest. New rules arrive switched off unless you enable them in the review.

To start, install the pack under Security › Detection rules, open Security › ATT&CK Coverage to choose the techniques that matter most to you, and follow Detection rules and shadow mode. When a rule in production finds something, Response actions covers what you can do about it.

MITRE ATT&CK® technique data © The MITRE Corporation. ATT&CK® is reproduced and distributed with the permission of The MITRE Corporation.