Hypothesis-driven hunting and detection-as-code with Sigma, SPL, and KQL.
Module overview
Hunting is proactive, hypothesis-driven search for activity that evaded existing alerts; detection engineering turns successful hunts into durable, tuned rules. This module is pure blue team. You will frame hypotheses against MITRE ATT&CK, query data in Splunk (SPL) and Microsoft Sentinel (KQL), author portable Sigma rules, and build a tuning loop that controls false positives.
Lesson 1
Hypothesis-Driven Hunting with ATT&CK
Deep explanation
A good hunt starts with a falsifiable hypothesis tied to a technique: "If an adversary used encoded PowerShell (T1059.001) for execution, I should see powershell.exe with -enc/long base64 spawned by Office or unusual parents." You pick the technique, identify the data source (process creation, command line, EDR), write the query, triage hits, and either find evil, refine, or convert the query into a detection.
The pyramid of pain guides durability: detections on TTPs/behaviors cost the adversary far more than detections on hashes or IPs they can trivially change.
Examples
Encoded-command hunt: powershell with -enc and a long base64 blob, parent = winword.exe.
LOLBins hunt: rundll32/regsvr32/mshta making outbound network connections.
Commands & tools
# Splunk SPL — encoded PowerShell with suspicious parent
index=win EventCode=1 Image="*\\powershell.exe"
| where match(CommandLine,"(?i)-enc|-encodedcommand")
| stats count by host, ParentImage, CommandLine
# Microsoft Sentinel KQL — same idea
DeviceProcessEvents
| where FileName =~ "powershell.exe"
| where ProcessCommandLine has_any ("-enc","-EncodedCommand")
| summarize count() by DeviceName, InitiatingProcessFileName, ProcessCommandLine
Ingest a provided sample dataset (or your lab Sysmon logs) into Splunk or Sentinel.
Write the encoded-PowerShell hunt in SPL or KQL and run it.
Triage results: separate admin/legitimate encoded commands from suspicious parent-child chains.
Document one true finding (or confirm none) and note the fields that distinguished signal from noise.
Expected output: The query returns encoded-command executions; triage isolates suspicious parents (e.g., Office) from benign automation. You produce a short hunt report with the distinguishing fields.
What to observe: Most encoded-command usage in an enterprise is benign automation; context (parent process, user, frequency) is what separates a finding from noise.
How attackers exploit · how defenders respond
Exploit: Adversaries use encoded/obfuscated PowerShell and LOLBins to blend with admin activity (defense evasion, T1027).
Detect & respond: Behavioral detections on command-line patterns + parent/child context; enrich with user role and asset criticality; prefer TTP-level logic over IOC lists.
Red teamObfuscate command lines, abuse signed LOLBins, mimic admin patterns to evade naive rules.
Blue teamHunt by hypothesis, detect on behavior and context, climb the pyramid of pain toward TTP coverage.
Real-world scenario
A hunt for regsvr32 making external connections (a Squiblydoo-style pattern) routinely surfaces both red-team tradecraft and real intrusions that signature AV missed.
Lesson 2
Sigma Rule Engineering & Tuning
Deep explanation
Sigma is the portable, vendor-neutral detection format: write once in YAML, convert to SPL/KQL/Elastic with a converter (sigma-cli/pySigma). A production rule is more than logic — it carries metadata (ATT&CK tags, severity), false-positive notes, and a tuning history. Detection-as-code means rules live in version control with tests and CI, just like application code.
Tuning is the real job. Every rule needs a feedback loop: measure precision, capture analyst dispositions, and refine conditions/allow-lists so true positives stay high and alert fatigue stays low.
Examples
A Sigma rule for encoded PowerShell maps to T1059.001 and lists known-benign automation paths in falsepositives.
Converting the same rule to KQL and SPL from one YAML source keeps detections consistent across SIEMs.
Write a Sigma rule for a technique of your choice (start from the encoded-PowerShell example).
Convert it to both SPL and KQL with sigma-cli and run both against your dataset.
Introduce a benign trigger, observe the false positive, and tune the rule (allow-list/condition) to suppress it without losing the true positive.
Commit the rule + tuning note to a git repo to model detection-as-code.
Expected output: One YAML rule converts cleanly to two backends and fires on the true positive; after tuning, the benign trigger no longer alerts while the malicious one still does.
What to observe: Portability (write once, deploy everywhere) and tuning (precision over volume) are what make detection engineering sustainable.
How attackers exploit · how defenders respond
Exploit: Adversaries probe for gaps and noisy rules analysts have learned to ignore (alert fatigue is an attack surface).
Detect & respond: Detection-as-code: versioned Sigma rules with ATT&CK mapping, CI tests, measured precision/recall, and a disposition feedback loop.
Red teamExploit coverage gaps and fatigue; vary TTPs to slip beneath untuned thresholds.
Blue teamMaintain a mapped, tested, tuned rule library; track coverage against ATT&CK and close gaps deliberately.
Real-world scenario
Teams that moved detections into git with CI and ATT&CK coverage maps cut mean-time-to-detect and stopped re-introducing previously-fixed false positives.
End-of-module assessment
Tap an answer to check it.
1. A threat-hunt hypothesis should be:
Good hunts are testable and anchored to a technique and a data source.
2. The pyramid of pain says detections are most durable when based on:
TTP-level detection costs the adversary the most to evade.
3. Sigma's main advantage is:
Write once in YAML, convert to SPL/KQL/Elastic, etc.
Key takeaways
Hunt by falsifiable hypothesis mapped to ATT&CK; triage with context, not just keywords.
Climb the pyramid of pain — detect behaviors/TTPs over swappable IOCs.
Treat detections as code: portable Sigma, version control, CI tests, and a tuning feedback loop.
