rulerangeACTIVE

Rule Range

A synthetic-telemetry firing range for Elastic detection rules.

// ./rulerange serve — try it

Live demo — interactive · mock data · no cluster

The actual Rule Range dashboard, wired to canned data so you can drive it. Run theLSASS credential-dumping test on the bench, then explore the ATT&CK matrix. Loads only when you scroll here.

rulerange · localhost:8080 · DEMO — mock data, no cluster

RULERANGE// LIVE-FIRE DETECTION RANGE demo cluster · green

try it

1Run the LSASS test▶ on the Test Bench→
2Watch the verdictpipeline → PASS→
3Explore the other tabsATT&CK · Coverage · Atomics

① Rule under test

Existing enabled ruleNew / custom rule

Selected rule

Credential Dumping via LSASS Memory Access HIGH · 73

Detection query (EQL / KQL)

event.category:"process" and process.name:"rundll32.exe"
  and process.command_line:(*comsvcs* and *MiniDump*)

② Attack / TTP

AutoAtomic Red TeamCustom

ATT&CK technique

T1003.001 — OS Credential Dumping: LSASS Memory

Command that will be mocked (no execution)

rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump <lsass_pid> C:\Temp\lsass.dmp full

③ Run & results

🎯

Nothing fired yet.

Hit Run test — the full pipeline, the verdict, the telemetry it built, and every injected event appear here.

// a sandbox, not the live range.This demo runs on canned data — no Elastic cluster, no real rules, no detonations. The real Rule Range drives Elastic's Detection Engine Preview API against synthetic ECS telemetry for genuine PASS/FAIL verdicts. This shows the flow and the feel; the real thing does the proving.

ZeroBlast radius
Seconds, not scheduled waitsFeedback loop
Atomic Red Team, no executionTests real TTPs

The problem

Validating detection rules the honest way means detonating real malware on victim hosts and waiting for scheduled rules to run. That is slow, dangerous, and hard to put in CI. Most teams simply hope their rules work.

The approach

Rule Range describes an attacker technique as ECS-compliant synthetic events, injects them into a throwaway index, and asks Elastic's Detection Engine Rule Preview API a single question: would this rule fire against this data? It asserts the answer against your expectation and reports PASS/FAIL as JSON and JUnit for CI.

▹ No real malware, no C2, no victim machines — every event is hand-crafted JSON.
▹ Preview runs in a temporary alerts index Elastic discards; nothing touches live alerts.
▹ Design a brand-new rule inline and iterate until it fires on the attack…
▹ …and stays silent on a benign baseline, catching false positives before deploy.

Testing real attacks — without running them

Rule Range compiles Atomic Red Team tests into synthetic telemetry: it reads each atomic's YAML, resolves its inputs, and mocks the observables (process, command line, registry/file artifacts) as ECS events. Nothing executes. Then it tests that telemetry against the rules mapped to the ATT&CK technique and reports coverage — DETECTED, MISSED, or NO_RULE — so gaps surface as data.

What it demonstrates

Detection engineering, the Elastic/ECS data model, ATT&CK-driven coverage thinking, and a disciplined commitment to test authenticity — faithful, two-sided scenarios that never rig a detection to pass.