A working notebook of detection content — Sigma, KQL, SPL, YARA, EQL — derived from real-world threat intel, one case per day.
This repository is my personal detection journal: every day I take one high-impact, technically meaty case from the threat intel feed (vendor write-ups from Mandiant, Microsoft, Volexity, Unit 42, ESET, Talos, Securelist, SentinelOne, CrowdStrike, Dragos, etc., plus DFIR Report and CISA advisories) and translate it into deployable detection content:
- Sigma rules (vendor-agnostic, convertible via
pySigma/uncoder/sigmac) - KQL queries (Microsoft Sentinel and Defender XDR)
- SPL queries (Splunk Enterprise / ES)
- YARA rules (file/process memory)
- EQL queries (Elastic) — when relevant
- PEAK / TaHiTI hunting hypotheses with baselines
Each entry is grounded on a published, sourced case so it stays defensible and reproducible.
- Not a feed for production blocklists. Validate every IOC before wiring it into preventive controls — confidence levels are documented, but circumstances change.
- Not a SigmaHQ replacement. Upstream-quality rules go to SigmaHQ via PR; this is the lab notebook that precedes that step.
- Not weaponized PoCs. All offensive snippets here are publicly documented and live for detection design, not exploitation.
detection-diary/
├── README.md # ← this file
├── INDEX.md # chronological + thematic index
├── LICENSE
├── CHANGELOG.md # short notes per release/day
│
├── days/ # one folder per case, dated
│ └── 2026-05-04_C0063-Poland-Wiper/
│ ├── README.md # case write-up, kill chain, sources
│ ├── sigma/
│ │ └── gpo_startup_script_weaponization.yml
│ ├── kql/
│ │ ├── lsass_dump_via_taskmgr.kql
│ │ └── rubeus_s4u_tgs_burst.kql
│ ├── spl/
│ │ └── rsocx_socks5_egress_and_gpo_writes.spl
│ ├── yara/
│ │ └── DynoWiper_Sandworm_C0063_Heuristic.yar
│ ├── hunts/
│ │ └── peak_h1_h2_h3.md
│ └── iocs.csv # type,value,context,confidence,source
│
├── byActor/ # symlink-style index by cluster
│ ├── G0034_Sandworm/
│ ├── G1027_CyberAvengers/
│ └── ...
│
├── byTechnique/ # MITRE ATT&CK index
│ ├── T1484.001_GPO/
│ ├── T1003.001_LSASS/
│ └── ...
│
├── byPlatform/
│ ├── windows/
│ ├── linux/
│ ├── macos/
│ ├── cloud-azure/
│ ├── cloud-aws/
│ ├── cloud-gcp/
│ ├── ot-ics/
│ └── network-edge/
│
└── tools/
├── lint_sigma.sh # pySigma + sigmac sanity
├── render_kql.py # quick KQL syntax check
└── generate_index.py # rebuilds INDEX.md from days/
The
byActor/,byTechnique/, andbyPlatform/folders are generated fromtools/generate_index.py— never hand-edited. Source of truth is alwaysdays/.
days/YYYY-MM-DD_<short-slug>/
YYYY-MM-DDis the date the class was delivered, not the date the case was disclosed.<short-slug>is the campaign ID, malware family, or actor (kebab-case). Examples:2026-05-04_C0063-Poland-Wiper2026-05-03_BAUXITE-Rockwell-AA26-097A2026-05-02_Nexcorium-TBK-DVR-CVE-2024-3721
Rule files inside follow:
<technique-or-payload>_<platform>.<ext>
Example: gpo_startup_script_weaponization_windows.yml
Every Sigma rule must include:
title: # imperative, < 80 chars
id: # UUID v4
status: # experimental | test | stable | deprecated
description: # 2–4 lines, plain English, what + why
references:
- https://... # primary vendor write-up
- https://... # secondary corroboration
- https://attack.mitre.org/...
author: # your handle
date: # YYYY/MM/DD
modified: # YYYY/MM/DD
tags:
- attack.<tactic>
- attack.<technique-id>
- cve.YYYY-NNNN # if applicable
logsource: # exact provider/service/category
detection:
...
falsepositives:
- ... # always at least one — be honest
level: # informational | low | medium | high | criticalEvery KQL/SPL file starts with a header comment block:
// Title: Lateral Movement via Rubeus S4U2self with TGS Burst
// Id: uuid-v4
// MITRE: T1558.003, T1550.003
// Reference: https://...
// Author: <handle>
// Date: 2026-05-04
// Tested on: Sentinel (DeviceProcessEvents, SecurityEvent)
// FP notes: Legitimate constrained delegation cases; baseline before deploy.Every YARA rule keeps the meta: block populated with author, description, date, reference, confidence, and (where relevant) eset_family / vendor_family.
// Drop the .kql contents into:
// Sentinel → Analytics → Create → Scheduled query rule
// or Defender XDR → Hunting → Custom detection rule# Save the .spl as a Saved Search, scheduled run.
# For Splunk ES, wire into a Correlation Search and assign Risk-Based Alerting.pip install pysigma pysigma-backend-splunk pysigma-backend-microsoft365defender
sigma convert -t splunk days/2026-05-04_C0063-Poland-Wiper/sigma/*.yml
sigma convert -t microsoft365defender days/2026-05-04_C0063-Poland-Wiper/sigma/*.ymlyara -r days/2026-05-04_C0063-Poland-Wiper/yara/*.yar /mnt/triage/Every rule should be exercised — at minimum mentally — against Atomic Red Team tests for the same technique IDs. When the lab covers it, the case folder includes a tests/ subfolder with the Atomic invocations and the expected event window.
When in doubt, follow the PEAK Threat Hunting Framework:
- Prepare — what hypothesis am I testing?
- Execute — run the hunt, baseline, refine.
- Act on Knowledge — promote to detection, document false-positive surface, harden.
A live, auto-generated index lives in INDEX.md. It is sliced three ways:
- Chronological (newest first)
- By actor / cluster (G0034 Sandworm, G1027 CyberAv3ngers, FIN-class, RaaS, etc.)
- By MITRE technique (T1484.001, T1003.001, T1090.002, …)
A typical entry looks like:
2026-05-04 — C0063 Poland Wiper Attacks (DynoWiper + LazyWiper)
Cluster: Static Tundra (CERT Polska, FSB Center 16) | Sandworm/G0034 (ESET, GRU 74455)
Tactics: Initial Access, Lateral Movement, Impact
Techniques: T1133, T1484.001, T1558.003, T1485, T0832, T0857
Platforms: Windows, AD, OT/ICS, network-edge (FortiGate)
Rules: 1 Sigma · 2 KQL · 1 SPL · 1 YARA
- Triangulate. Every case must reference at least two independent sources (vendor write-up + agency advisory, or two vendors with overlap).
- Cite primary. Always link to the original write-up, not aggregator headlines.
- Mark confidence. When attribution is contested (e.g., Static Tundra vs. Sandworm for C0063), document both views and the evidence each anchors on.
- Never invent IOCs, hashes, or CVEs. If a hash isn't published, the rule is heuristic and labelled as such.
This is primarily a personal notebook, but PRs that:
- Reduce false-positive surface on an existing rule
- Add a missing platform conversion (e.g., the SPL twin of an existing KQL)
- Cite a corroborating source on a contested attribution
- Add Atomic Red Team test coverage
…are very welcome. Please keep one rule per PR and include tests/ evidence when possible.
The content here is for defensive and educational use. Snippets that reference offensive tooling (Rubeus, rsocx, etc.) describe behavior already public in vendor write-ups; they exist to teach the blue team what those behaviors look like on the wire and on disk. Do not use this repo to plan or run unauthorized activity.
Detection rules are provided as-is, with no warranty. Tune to your environment and validate against your own baselines before deploying to production. False positives are part of the package — read the falsepositives: block.
MIT — use, modify, redistribute. Attribution appreciated.
- SigmaHQ for the rule format and the community.
- MITRE ATT&CK for the common language.
- Atomic Red Team for the reproducible tests.
- LOLBAS and GTFOBins for the living-off-the-land catalogues.
- The DFIR Report, Mandiant, Microsoft Threat Intelligence, Volexity, Unit 42, Talos, Securelist, ESET WeLiveSecurity, SentinelOne Labs, CrowdStrike, Dragos, Claroty Team82, and CERT Polska — for the daily flow of public, technical, defendable threat intel that makes this notebook possible.