Detection Engineering Lab

5 behaviour-based detection rules for common Windows attacker techniques, written in Sigma, compiled to Elastic and CrowdStrike LogScale, and replayed against synthetic events on a real Elasticsearch in CI, with the line between “the query works” and “the telemetry was really generated” enforced by the build rather than described in a document.

No. It is a portfolio lab. Every event the rules have ever matched is a synthetic fixture, no production telemetry has been ingested, and no false-positive rate is claimed. 5 of 5 rules are at the lifecycle state fixture-validated; 0 are validated, and the page says so on every card.

Detection engineering and SOC analyst or threat-hunting work: authoring Sigma rules with documented blind spots, mapping to MITRE ATT&CK, compiling one rule to two query languages, testing detections in CI with positive and negative controls, and keeping an evidence trail a reviewer can audit. It is not evidence of incident response on production telemetry, and does not claim to be.

Proven: 5 of 5 rules compile to Elastic and 3 of 5 to LogScale; each compiled Elastic query returned exactly its own positives (15 in total) and none of the 15 negative controls on elasticsearch 8.19.20 in CI. Not proven: that any rule fires on Sysmon or Security events generated by a real Windows host. The isolated-VM plan that would prove it is written, per detection, and deliberately unexecuted; until it runs, the promotion gate must fail, and CI asserts that it fails.

Because the pySigma Falcon pipeline has no mapping for registry-set events or for Security event 4624, and it does not raise when it meets one: it passes the Windows field names through untouched. The compiler treats a query without the Falcon event marker as unsupported and records why, rather than committing a query that could never match. That quiet failure was found here and is the first entry in the validation log.

No payload runs anywhere. The fixtures are text, hand-authored to the shape of named Atomic Red Team tests (the GUIDs and access dates are recorded beside each fixture), and nothing from a third party is ingested. The public site links those fixtures, which contain command-line shapes such as a comsvcs MiniDump call; they are detection test data that already appears in the public Atomic catalog, not tooling. The site content policy states the boundary: no payload binaries, no execution path, no secrets, no raw host telemetry.

Yes, as a collaboration between the author and Claude Code rather than a hand-off to either. The author set the problem, the lifecycle boundary, the stop conditions, and the rule that every gate is watched failing once before it counts; Claude Code did much of the implementation and testing under those rules. ROADMAP.md records the division of labour, including the unattended passes and two independent tool-assisted reviews whose confirmed findings are tracked there by ID.

No. This page, the status image in the README, and the compiled queries are all generated from the catalog, the compile manifest, the rules, and the validation matrix, and CI fails if a committed copy differs from a fresh render. The figures in this FAQ are derived from the same sources when the page is built, and a test pins them. The rules are checked against MITRE ATT&CK v19.2 and compiled with pySigma 1.5.0, pinned exactly because a backend upgrade can change the emitted query. One honest caveat: GitHub Pages publishes from the branch on its own, so CI detects drift rather than gating publication.

Two independent tool-assisted reviews on 4 September 2026, both recommending the repository for junior detection-engineering screens. Every substantive finding was verified in code and is tracked in ROADMAP.md by ID: the wording and truth items are closed; the mechanical promotion gate and the isolated-VM run remain, and both are gated on the owner because they change the lifecycle rather than the presentation.

Case sensitivity. Sigma “contains” is case-insensitive, but the compiled Lucene query is only case-insensitive if the index field is lowercase-normalised, and the stock Elastic Windows integration maps the command line as a case-sensitive wildcard field. One test proves both outcomes on the same fixture. The second probe is the Falcon pipeline’s quiet failure above. Both are in the README under findings worth knowing before deploying these queries.

The commit history is the record: built and published on 28 and 29 August 2026, the explorer on 2 September, external review and finalization on 4 September, and the wording pass with this FAQ on 12 September. Speed is not the point. The discipline is that every gate was watched failing once, and the mutation that made it fail is written down in the validation log.

The fixture-validated release is finished and tagged. What remains is the only work that would change the lifecycle: a stronger mechanical promotion gate and the isolated-VM run, both owner-gated and described in ROADMAP.md with their stop conditions. Nothing is promoted to validated as polish, and the inverted CI step stays until the last rule earns it. The backlog is in future-work.md.

The unit and contract suite runs from a clean clone with no SIEM. The query replay needs Docker: a localhost-bound Elasticsearch from the compose lab, then one pytest marker. Nothing is hosted beyond this static page, deliberately: Elasticsearch, Kibana, and any laboratory host stay off the internet.

The DET-001 rule for the logic and its false positives, its write-up for how a SOC would document it, test_siem.py for the two tests that carry every claim, and the validation log for what broke when each gate was tested.