Detection Engineering with MITRE ATT&CK

Detection engineering is the discipline of deliberately building, testing, and maintaining the detections a SOC runs on — treated like software, not like clicking “enable” on a vendor's default rules. It is the highest-leverage blue-team skill, and it is the exact inverse of the offensive content on this site: every technique in the AD attack-path map is a detection opportunity waiting to be engineered.

The shift it represents: from buying detection (and inheriting a vendor's blind spots and false positives) to owning it — knowing precisely which adversary behaviours you can see, proving it, and improving it over time.

MITRE ATT&CK as the map

MITRE ATT&CK is a curated, community knowledge base of real adversary behaviour, organised as:

Tactics — the why (the adversary's goal in a phase). ATT&CK Enterprise defines 14: Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command & Control, Exfiltration, and Impact.
Techniques & sub-techniques — the how (e.g. T1558.003 Kerberoasting, T1003.001 LSASS memory).
Procedures — the specific real-world implementations seen in the wild.

Used as a coverage map, ATT&CK lets you answer the only question that matters: which adversary behaviours can we actually detect, and where are the holes? The ATT&CK Navigator is the standard way to colour that heat-map.

The Pyramid of Pain — detect behaviour, not just IOCs

David Bianco's Pyramid of Pain ranks indicators by how much it hurts the attacker when you detect at that level. Low down, they swap trivially; high up, they have to rebuild their tradecraft.

Indicator	Pain to attacker	Durability of your detection
Hash values	Trivial	Breaks on any file change
IP addresses	Easy	Rotated constantly
Domain names	Simple	Cheap to re-register
Network/host artifacts	Annoying	Tooling-specific
Tools	Challenging	Forces a tool change
TTPs (behaviour)	Tough	Survives IOC rotation

The lesson: a detection for “this hash” dies the moment the attacker recompiles. A detection for the behaviour — “a non-DC asked to replicate directory secrets” (DCSync) — survives, because the attacker can't achieve the goal without the behaviour. Engineer toward the top of the pyramid.

The detection lifecycle

  (1) HYPOTHESIS      -- what adversary behaviour do we want to catch?
        |                (pick an ATT&CK technique)
        v
  (2) DATA SOURCES    -- do we even collect the needed telemetry?
        |                (EDR? Sysmon? 4688? LDAP logs?)
        v
  (3) LOGIC           -- write the detection (Sigma rule / query)
        |
        v
  (4) TEST            -- fire the real technique (Atomic Red Team) & confirm
        |
        v
  (5) TUNE            -- cut false positives against real baselines
        |
        v
  (6) DEPLOY          -- version-controlled, peer-reviewed, into the SIEM
        |
        v
  (7) MAINTAIN        -- revisit as the environment & TTPs change
        (loop back to 1)

Detections-as-code with Sigma

Mature teams write detections in Sigma — a vendor-agnostic YAML format that compiles to Splunk/Sentinel/Elastic queries — and manage them in Git with peer review and CI, exactly like application code. That gives version history, testing, and portability across SIEMs. A (simplified) Sigma rule for Kerberoasting-style TGS requests:

title: Potential Kerberoasting (TGS-REQ for many SPNs, RC4)
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769          # Kerberos service ticket requested
    TicketEncryptionType: '0x17'   # RC4 -- crackable
  filter:
    ServiceName|endswith: '$'      # machine accounts (noise)
  condition: selection and not filter
level: medium
tags:
  - attack.credential_access
  - attack.t1558.003

The prerequisite: can you even see it?

Every detection depends on a data source being collected and retained. This is why detection engineering is joined at the hip to logging & telemetry and EDR: a brilliant detection for an event you don't log is fiction. Half of detection engineering is actually log engineering — turning on the right auditing (process creation with command line, script-block logging, LDAP/Kerberos events) before writing a single rule.

Mapping the site's attacks to detections

Attack (on this site)	ATT&CK	Detection idea
Kerberoasting	T1558.003	4769 service-ticket requests with RC4 encryption for user SPNs, in volume from one source
DCSync	T1003.006	Directory-replication (DRSUAPI GetNCChanges) from a host that is not a domain controller
Pass-the-hash	T1550.002	Logon type 9 / anomalous NTLM auth; new-host access from a credential never used there
AS-REP roasting	T1558.004	4768 AS-REQ without pre-auth for accounts, then offline-crackable material
Process injection	T1055	EDR/Sysmon: remote-thread creation, suspicious memory permissions (RWX)

Measuring & validating coverage

ATT&CK Navigator heat-map — colour techniques by detection confidence to expose the holes.
Atomic Red Team (OSS) — fire individual techniques safely to prove a detection actually triggers.
Purple teaming — red executes a TTP, blue confirms (or builds) the detection, in a tight loop.
Breach & Attack Simulation (AttackIQ, SafeBreach, Cymulate) — automated, continuous validation that controls and detections still work.

“We have 2,000 detection rules” is not a metric; “we have tested detections for 140 of the ATT&CK techniques relevant to our estate, validated monthly by BAS” is. Coverage you have proven beats coverage you assume.

Key takeaways

Detection engineering = building, testing, and maintaining detections like software.
Use ATT&CK as a coverage map; engineer toward the top of the Pyramid of Pain (behaviour, not IOCs).
Follow the lifecycle: hypothesis → data → logic → test → tune → deploy → maintain.
Half the job is log engineering; validate coverage with Atomic Red Team, purple teaming, and BAS.