/engineering-detections

name: engineering-detections
description: Build, test, and tune detection content — Sigma, YARA, Suricata, and EDR/SIEM queries — mapped to MITRE ATT&CK with explicit false-positive analysis and detection-as-code practices. Use when writing or reviewing a detection rule, converting IOCs or TTPs into alerts, measuring detection coverage, or reducing alert fatigue.
verified: 2026-07-27

Engineering Detections

A detection is a hypothesis about attacker behaviour, expressed as a query, that a human will be paged for. Two properties decide whether it is worth deploying: does it fire on the behaviour, and does it stay quiet otherwise. Most rules fail the second test, and the cost is paid by whoever is on call.

When to Use

• Writing a new detection rule from a TTP, a sample, or an incident
• Reviewing or tuning an existing rule that is noisy or silent
• Converting threat intelligence into deployable detection content
• Assessing detection coverage against ATT&CK
• Setting up detection-as-code: repo layout, testing, CI, deployment

When NOT to Use

• **Searching for an unknown compromise right now** — use `hunting-threats`
• **Working an active incident** — use `responding-to-incidents`
• **Analyzing the sample the detection is for** — use `analyzing-malware`
• **Authoring a file/memory signature** — use `writing-yara-rules`; a

log/SIEM rule — use `writing-sigma-rules`

• **Preventive controls and hardening** — hardening is not detection; a rule

is not a substitute for closing the path

Route to a Depth Skill

| Focus | Skill | | --- | --- | | Authoring a portable Sigma rule specifically — field taxonomy, modifiers, backend conversion, SigmaHQ standards | `writing-sigma-rules` |

This skill covers the whole detection lifecycle across Sigma, YARA, and Suricata; reach for `writing-sigma-rules` when the task is the Sigma rule itself and its conversion to a target SIEM.

Detect Behaviour, Not Artifacts

Rank what you write by how expensive it is for the adversary to change:

Hash              trivial to change      → block, don't alert
IP / domain       days                   → block + low-severity alert
Filename / path   trivial                → weak signal, combine only
Tooling artifact  weeks (recompile)      → good, decays
Behaviour / TTP   expensive              → this is the target

The pyramid-of-pain reasoning is the whole discipline: a rule on `mimikatz.exe` is worthless; a rule on a process opening a handle to LSASS with `PROCESS_VM_READ` catches every tool that does the same thing.

The Rule Development Loop

1. Hypothesis   → what behaviour, by whom, visible where?
2. Data check   → is the required telemetry actually collected and retained?
3. Draft        → write the logic against real data
4. FP analysis  → run over 30+ days of production data, characterize every hit
5. Tune         → narrow with attacker-independent conditions only
6. Test         → prove it fires on an emulated true positive
7. Document     → triage steps, response, and known limits
8. Deploy       → with a severity that matches the actual response
9. Review       → re-test after telemetry, environment, or tooling changes

Step 2 kills more rules than any other. Before writing logic, confirm the field exists, is populated on the platforms you care about, and is retained long enough to matter. A rule on a field your agent does not ship is a coverage illusion — worse than no rule, because it appears on the map.

Writing Sigma

Sigma is the portable format; write once, convert per backend.

title: LSASS Memory Access from Unusual Process
id: 9f2b1c4e-0000-4000-8000-000000000001
status: experimental
description: >
  Detects a process obtaining a handle to lsass.exe with read/clone access,
  the common precondition for credential dumping regardless of tooling.
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: secskills
date: 2026-07-26
logsource:
  product: windows
  category: process_access
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess|contains:
      # QUERY_LIMITED_INFORMATION 0x1000 | QUERY_INFORMATION 0x0400
      # VM_READ 0x0010 | VM_WRITE 0x0020 | VM_OPERATION 0x0008
      - '0x1010'   # QUERY_LIMITED | VM_READ        — minimum to read lsass
      - '0x1410'   # QUERY_LIMITED | QUERY_INFO | VM_READ
      - '0x1438'   # the classic mimikatz mask: adds VM_WRITE | VM_OPERATION
  filter_legitimate:
    SourceImage|startswith:
      - 'C:\Program Files\<your EDR>\'
      - 'C:\Windows\System32\wbem\WmiPrvSE.exe'
  condition: selection and not filter_legitimate
falsepositives:
  - EDR and backup agents; enumerate yours and filter by full path
  - Windows Error Reporting on crash
level: high
tags:
  - attack.credential-access
  - attack.t1003.001

Conversion:

sigma convert -t splunk -p sysmon rules/lsass_access.yml
sigma convert -t esql -p ecs_windows rules/lsass_access.yml     # Elastic
sigma convert -t kusto -p microsoft_xdr rules/lsass_access.yml  # Defender/Sentinel

**Tuning rules that stay honest:** filter on things the attacker cannot choose. Full paths of signed vendor binaries, specific service SIDs, and parent-child pairs are acceptable. Filtering on a filename, a username string, or a command-line fragment the attacker controls is not tuning — it is building the bypass into the rule.

Writing Network Detections

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"Beacon: HTTP POST, no User-Agent, fixed small body";
    flow:established,to_server;
    http.method; content:"POST";
    http.header_names; content:!"User-Agent";
    threshold:type both, track by_src, count 10, seconds 600;
    classtype:trojan-activity;
    metadata:attack_target Client_Endpoint, mitre_technique_id T1071;
    sid:1000101; rev:1;
)

For encrypted traffic, detect on metadata rather than content: JA3/JA4 fingerprints, certificate anomalies, SNI/DNS patterns, and — most durably — **b