Guides

MITRE ATT&CK + Your First Sigma Detection Rule (Defence)

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 29 September 2026 · Last updated: 30 September 2026

MITRE ATT&CK is a public knowledge base of adversary tactics and techniques that blue teams use to describe behaviour in a shared language. Sigma is an open detection rule format (YAML) you can translate into SIEM queries — so your first detection engineering habit is: map a technique → write a defensive rule → test on lab logs → tune false positives. No exploit PoCs here.

ATT&CK technique → telemetry you own → Sigma YAML → SIEM alert → triage notes
Rule without telemetry = fiction
Rule without tuning = pager death

What do I need before this guide?

• SIEM basics.
• Optional Windows telemetry: Windows Event Logs and Sysmon.
• Comfort reading simple YAML indentation.

How do ATT&CK and Sigma fit together?

1. Tactics — the adversary goal stage (for example Execution, Persistence) — the column headers in ATT&CK.
2. Techniques / sub-techniques — how (IDs like T1059 style) — use them as tags, not as attack manuals.
3. Data sources — what logs you need (process monitoring, command history, network).
4. Sigma — vendor-neutral detection logic focused on fields defenders already collect.
5. Detection-as-code — rules in git, reviewed like application code, tested before prod.

Educational warning: this guide teaches detection. Do not use ATT&CK pages as a cookbook to attack systems. Lab generation of benign events only, on machines you own, or under written authorisation.

Real incident: SolarWinds (2020) — mapping behaviour mattered

Public reporting on the SolarWinds / SUNBURST supply-chain intrusion described stealthy follow-on activity across cloud and identity systems. Defenders worldwide used shared behavioural vocabularies (including ATT&CK-style mapping in public reporting and hunting guides) to ask: which techniques apply to our telemetry, and which detections were missing?

Takeaways (vertical):

1. What happened — trusted update path abused; long dwell time in some environments.
2. What went wrong (theme) — subtle identity and admin behaviours under-detected.
3. Care-take — map crown-jewel abuse paths to techniques you can actually alert on.
4. Care-take — third-party software integrity belongs in detection and procurement (see SBOM guide).
5. Care-take — share detections as code so one analyst’s lesson helps the whole SOC.
6. Bonus parallel — many IR reports now include ATT&CK heat maps for executives — useful if honest about coverage gaps.

Red Team vs Blue Team (awareness only)

Red Team — what attackers try

• Prefer techniques that look like normal admin work.
• Rotate tooling faster than signature lists.
• Test whether your detections are brittle string matches.

Blue Team — defend, detect, respond

• Cover critical techniques with layered rules (endpoint + identity + network).
• Prefer behaviour + context over single scary filename.
• Track coverage: “which techniques have any high-quality detection?”
• After incidents: add/adjust Sigma (or native) rules, not only slides.

How do I write a first Sigma rule step by step?

Step 1 — Choose a beginner-friendly technique

1. Prefer something your lab already logs (Sysmon process create is ideal).
2. Example theme: unusual scripting host launched by Office — tune heavily; treat as educational pattern, not a paste-into-prod nuke.
3. Read official ATT&CK detection and mitigation sections only for defensive ideas.

Step 2 — Sketch fields before YAML

1. Which logsource product / category / service?
2. Which fields: Image, ParentImage, CommandLine?
3. What is the rare condition vs everyday noise?
4. What will you allow-list (update agents, security tools)?

Step 3 — Draft YAML structure (illustrative, defensive)

title: Lab - Suspicious Script Host Parent (Educational)
id: 00000000-0000-4000-8000-000000000001
status: experimental
description: Educational Sigma sketch — test only in your lab SIEM.
references:
  - https://attack.mitre.org/
author: LearnFast Academy lab
date: 2026/09/29
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\\WINWORD.EXE'
      - '\\EXCEL.EXE'
  selection_child:
    Image|endswith:
      - '\\cmd.exe'
      - '\\cscript.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare legitimate macros in controlled business apps (validate before prod)
level: medium
tags:
  - attack.execution
  - attack.t1059

This is a pattern sketch for learning structure — not a guaranteed production rule. Always test.

Step 4 — Test in lab

1. On your Windows lab with Sysmon, create a benign controlled parent/child event if policy allows (for example open a test document that launches a helper you wrote) — or replay recorded sample logs.
2. Confirm the rule fires.
3. Perform normal Office work; list false positives.
4. Tighten fields (full paths, signed parent, user context) before any wider deploy.

Step 5 — Operationalise

1. Store rule in git with PR review.
2. Map alert → playbook (isolate host? disable user? open IR?).
3. Review weekly hits; demote noisy rules.
4. Tag ATT&CK IDs so coverage dashboards stay honest.

Step 6 — Grow coverage deliberately

1. Identity: rare MFA changes, new inbox rules.
2. Cloud: unusual IAM failures / Disable logging APIs (high-level).
3. Network: beacon-like regularity is advanced — start simpler.
4. One solid rule per sprint beats fifty untested copies from the internet.

Care-take — detection engineering hygiene

1. Experimental → tested → production statuses mean something — use them.
2. Every prod rule has an owner and a last-reviewed date.
3. Secrets never belong inside rule sample logs committed to public repos.
4. Pair preventative controls (ASR, M365 policies) with detections — do not detect-only forever.
5. Purple-team lightly: ask a trusted tester to generate authorised benign artefacts that should hit your rule.
6. Legal / ethics: only authorised testing.

How do I fix common ATT&CK / Sigma mistakes?

Ghabru naka 😅 — these are the usual ones: