Detection Engineering Lesson 3: Detection Hypotheses and Rules
Table of Contents
Return to the Detection Engineering and Incident Response Course
A detection hypothesis predicts observable behavior. A rule implements one part of the hypothesis in a specific data model.
Define the Hypothesis
Use this sentence:
When an Office process starts an encoded PowerShell command, the event deserves review because document-driven script execution is uncommon in the course environment and appears before persistence or outbound traffic in the scenario.
Record five items:
- Behavior: Office parent starts PowerShell
- Observable fields: parent image, child image, command line, user, host, timestamp
- Population: managed Windows endpoints with process creation telemetry
- Expected benign cases: approved document automation and enterprise add-ins
- Escalation evidence: dropped script, scheduled task, suspicious DNS, or outbound connection
Write Portable Logic
The example follows the official Sigma rule structure. Adapt field mappings before deployment.
title: Office Process Starts Encoded PowerShell
id: 908e82a9-4f44-4f20-8da1-9e8af49fdb81
status: test
description: Detects an Office process starting PowerShell with an encoded command.
date: 2026-10-10
logsource:
category: process_creation
product: windows
detection:
parent_office:
ParentImage|endswith:
- '\\WINWORD.EXE'
- '\\EXCEL.EXE'
- '\\POWERPNT.EXE'
child_powershell:
Image|endswith:
- '\\powershell.exe'
- '\\pwsh.exe'
encoded_flag:
CommandLine|contains:
- '-EncodedCommand'
- '-enc '
condition: parent_office and child_powershell and encoded_flag
falsepositives:
- Approved document automation after environment review
level: high
Status test matters. The rule has not earned production status until telemetry mapping, replay tests, volume review, and analyst handling pass.
Build Test Cases
| Test | Event shape | Expected |
|---|---|---|
| Positive 1 | Word starts PowerShell with -EncodedCommand | Match |
| Positive 2 | Excel starts pwsh.exe with -enc | Match |
| Negative 1 | Software Center starts an approved PowerShell file | No match |
| Negative 2 | Word starts a PDF viewer | No match |
| Boundary | Word starts PowerShell without an encoded flag | No match, then review whether separate logic covers the behavior |
Run the Offline Rule Check
Download the five test events and the local checker into the same clean folder. The checker implements the three selections above with Python string comparisons. It does not parse Sigma YAML or validate a SIEM translation. Compare its field names and predicates with the YAML before running it.
python3 check_rule_cases.py rule-test-events.jsonl
Expected result: each named case prints PASS, the last line is 5/5 passed, and the process exits zero. Both positive cases match. Both negatives and the boundary case do not match. Record the output, the mapping from ParentImage, Image, and CommandLine to the three Sigma selections, and a false-positive count of zero among the two negative cases.
If you have a SIEM translator or local Sigma test tool, run the same five cases there as an advanced check. Record its backend query, field mapping, observed results, and any difference from the offline predicate. A valid YAML file or a passing predicate harness alone does not prove production detection behavior.
Define Operations
Every alert needs a short runbook:
- Confirm host, user, parent, child, and command line.
- Decode content in an isolated analysis workflow without execution.
- Search for child processes, file writes, persistence, and outbound connections.
- Compare the parent document hash and origin with approved software records.
- Escalate when related persistence, identity misuse, or network activity appears.
- Close as expected only when an owner and approved behavior record support the decision.
Expected Result: another analyst knows which evidence to collect, which alternate explanations to test, and when to declare an incident.
Troubleshooting
| Problem | Fix |
|---|---|
| No positive events match | Compare backend field names and case handling with the normalized schema |
| The local checker reports a failure | Confirm both downloaded files are unmodified and compare each field with the Sigma selections |
| Approved scripts match | Narrow the parent-child relationship or add a documented filter with an owner and review date |
| The query is too expensive | Filter on indexed parent and child fields before command-line terms |
| Alert volume rises after an update | Compare new parent paths, process names, and management software versions before broad suppression |
Verify Your Work
- Hypothesis names behavior, population, and reason for review
- Rule status stays
test - Two positive and two negative tests exist
- The offline checker prints
5/5 passedwith a zero exit code - Field mappings are recorded
- Runbook includes escalation and closure evidence
- Every suppression has an owner and review date
Primary reference, checked 2026-10-10: Sigma rule structure and logsource guidance .
Next Steps
Continue to Lesson 4: Triage and Scoping . Use the alert as a starting point for an evidence search.
