Module 8 — MITRE ATT&CK

Why it matters to a software engineer

ATT&CK is how red, blue, intel, and engineering can name the same behavior without a 40-page email. It is also how organizations fake progress: coloring cells on a matrix. You will learn to map observed events to techniques with confidence, and to treat coverage as a hypothesis about telemetry.

Visual overview

flowchart LR
  GOAL[Adversary goal] --> TAC[Tactic — the why]
  TAC --> TECH[Technique — the how]
  TECH --> SUB[Sub-technique — specific variant]
  SUB --> PROC[Procedure — exact commands/tools used]
  TECH --> DS[Required data source]
  DS --> HYP[Detection hypothesis]
  HYP --> MIT[Mitigation]

Intuition

Read ATT&CK bottom-up in practice, even though it's drawn top-down here. You rarely start from "the adversary's goal" — you start from a suspicious procedure you observed, work out which technique it maps to, and only then reason about tactic-level intent. The framework is a shared vocabulary for comparing notes with other defenders, not a checklist to fill in from the top.

Red uses ATT&CK to name authorized emulation; blue to organize observations and controls; analysts to classify with uncertainty; hunters to form testable hypotheses; detection engineers to state telemetry requirements. A green matrix cell proves none of prevention, detection fidelity, or response quality.

Hint

"We have a detection mapped to this technique" and "we would actually catch this technique in production" are different claims. The matrix cell only proves the first one. Module 9's replay loop is how you test the second.

Learning objectives

• Explain tactics, techniques, sub-techniques, procedures, software, groups, data sources, and mitigations.
• Relate Enterprise ATT&CK to other domains without merging them.
• Map a lab alert to ATT&CK and state limitations.
• Draft a small coverage matrix for the capstone.

Key concepts

See also COURSE.md section 6.

ATT&CK is a knowledge base, maintained by MITRE, of adversary behavior drawn from public reporting. attack.mitre.org. It is not PCI, not a NIST control catalog, not a product requirement list.

Tactic. Goal at that step. Enterprise ATT&CK currently has 14 columns (confirm on the site; the knowledge base is versioned):

Reconnaissance, Resource Development, Initial Access, Execution, Persistence, Privilege Escalation, Defense Evasion, Credential Access, Discovery, Lateral Movement, Collection, Command and Control, Exfiltration, Impact.

This lab barely touches Reconnaissance, Resource Development, Persistence, Lateral Movement, and C2 — write “no data source,” do not paint those cells.

Technique / sub-technique. How, at two levels of granularity. IDs like T1190, T1552.005.

Procedure. The concrete implementation. Lab: Alice GET /notes/2.

Software / groups. Real-world names. We do not emulate named malware.

Data sources. What you would need to see it (application logs, process creation, cloud audit). If you lack the data source, you do not “cover” the technique.

Mitigations. Control classes (restrict web-based content, network segmentation, …). Mapping a mitigation is not implementing it.

Enterprise vs other matrices. Enterprise includes platform-specific techniques (Windows, Linux, cloud, containers). Mobile, ICS, and ATLAS for AI are siblings. A prompt-injection against an agent may map better to ATLAS/OWASP LLM than to T1059.

Red use: adversary emulation plans (“we will attempt T1110.001 against the lab login”). Blue use: detections, hunts, gap analysis. SOC use: alert classification and prioritization — with the caveat that the first mapping is often wrong.

Limitations. Coverage ≠ security; techniques are ambiguous; mappings need context; version drift; paper coverage.

The Pyramid of Pain (David Bianco). A ranking of indicator types by how much it costs an attacker to change them when you detect on that type — and therefore how durable your detection is:

Indicator (bottom → top)	Cost for attacker to change	Detection durability
Hash values	Trivial — recompile, repack	Almost none
IP addresses	Easy — new host/proxy	Low
Domain names	Simple — register another	Low–medium
Network/host artifacts	Annoying — rework tooling	Medium
Tools	Challenging — rewrite/replace the tool	High
TTPs (technique/procedure)	Tough — relearn a new approach	Highest

ATT&CK gives teams a vocabulary for the TTPs near the top of the pyramid; the framework itself is not a pyramid layer. A behavioral detection for T1110.001 password guessing can survive a changed IP or tool if its logic uses durable behavior and sufficient context. A rule tied to one procedure's fields can still be brittle even when it carries a technique tag. Hash- or IP-only detections are usually cheaper for an attacker to evade, so combine them with behavior and test the concrete procedures your telemetry can see.

Architecture connection

Detections should cite: data source → event → rule → technique (confidence). That is the same chain as “we emit this log because hunters asked for T1552.005 visibility.”

Hands-on lab — map five detections

AUTHORIZED LAB USE ONLY.

Prerequisites

Modules 4 and 7. Lab up. LAB_MODE=true.

Before you run this

Predict: (1) which evidence appears (2) which does not (3) why.

Then run the steps. Compare with the prediction. If the result differs, which assumption was wrong?

Steps

1. python3 labs/attack-sim/simulate.py --scenario all
2. curl -s -X POST http://127.0.0.1:8090/ingest
3. curl -s http://127.0.0.1:8090/alerts
4. For each alert, open labs/detections/rules.yaml and attack.mitre.org (or your notes). Fill:

Rule	Event observed	Tactic	Technique	Confidence	Why it might be wrong
DET-001
DET-002
DET-003
DET-004
DET-005

Alert ids are {rule_id}:{group_key}. DET-001 groups by src_ip (for example DET-001:172.30.0.1), not alice. DET-002–005 group by actor (DET-003:alice). If a leftover LAB_MODE=false volume is still mounted, IDOR/SSRF success events will not appear — reset first.

1. Copy your table into docs/capstone/attack-coverage.md. The stub already contains starter mappings so you can see the shape; replace them with what you observed. Do not treat the stub as an answer key.
2. Add a gap row: a behavior the sim does not generate (for example persistence). Write “no data source” rather than painting the cell.

Expected observations

Five rule IDs. Suggested mappings in YAML are starting points: T1110.001, T1213 (+ T1190), T1552.005, T1087, T1190. You may disagree; write why.

Security lessons

Map from evidence, not from the vulnerability name. IDOR is OWASP; the behavior is collection or discovery depending on what was taken.

Common mistakes

• Tagging every web bug as T1190 only.
• Claiming 100% Enterprise coverage.
• Mapping T1059 Command and Scripting Interpreter because “they used curl.” Curl from the attacker laptop is not execution on the victim host.

Cleanup

Keep the lab if continuing to module 9.

Knowledge check

1. Difference between technique and procedure?
2. Why might DET-002 be T1213 rather than T1005?
3. What does a green cell in a coverage matrix not prove?
4. Name a tactic that this lab barely touches.
5. Should prompt injection be forced into Enterprise ATT&CK?

Answers: (1) Technique is the general method; procedure is the instance. (2) T1005 is data from local host filesystem; here it is app repository data. (3) That a real adversary would be stopped or even seen. (4) Persistence / lateral movement / C2. (5) Prefer ATLAS/OWASP; only map Enterprise if a specific technique truly fits the observed host/API behavior.

Exit criteria

You pass this module when you can meet the course pass bar (Explain → Predict → Diagnose → Design → Defend) on this material:

• ✓ State the difference between tactic (why) and technique (how) without looking at the diagram.
• ✓ Map an observed alert to a technique from the evidence it produced, not from the vulnerability's OWASP name.
• ✓ Name a data source you would need but do not have, and write "no data source" instead of guessing a mapping.
• ✓ Explain what a green coverage-matrix cell does and does not prove.
• ✓ Rank two indicator types by Pyramid of Pain durability and say why one costs an attacker more to evade.
• ✓ Distinguish "we have a detection mapped to this technique" from "we would catch this technique in production."
• ✓ Defend one tradeoff: why a behavioral TTP-based detection is more work to write than an IP/hash-based one, and why it survives longer.

Engineering assignment

Pick one production alert type you have seen (or invent from notes-api). Write a mapping with confidence and an alternative ID. One paragraph.

Self-check

Answer before expanding. These are the assessment moves on this module's Acme Notes lab, not trivia.

Explain: Tactic vs technique for DET-001, in one sentence each.

Tactic (why): Credential Access. Technique (how): T1110.001 Password Guessing. The procedure is six HTTP failures against lab /login. ATT&CK is the language, not a scoreboard.

Predict: What does the DET-001 alert id look like, and what is it not grouped by?

{rule_id}:{group_key} → DET-001:<src_ip> (often the Docker gateway). Not alice. DET-002–005 group by actor; do not assume every alert names a user.

Diagnose: Why is DET-002 T1213 rather than T1005?

T1005 is data from a local host filesystem. Here the object is an application repository (a note row). Wrong ID is matrix theatre.

Design: A coverage cell is green for T1110.001. What does that not prove?

That a real adversary would be stopped or even seen. You have a procedure, a data source, and a rule for this lab login. Persistence, lateral movement, and C2 stay "no data source."

Defend: Why spend more effort on a TTP-style rule than on an IP denylist?

IPs are cheap for an attacker to change (Pyramid of Pain). A behavioral guess-burst rule survives a new source if the fields still exist. Residual: shared NAT src_ip and slow guessing still evade DET-001.

Before you leave

• Predict — write expected evidence (what appears, what does not, and why) before the next observation.
• Diagnose — map from the alert's evidence, not from the vulnerability's OWASP name.
• Build — fill the five-detection coverage matrix with confidence and limitations.
• Defend — state containment and residual risk in one sentence each.
• Exit criteria — meet this module's list and the course pass bar.

Further reading

• MITRE ATT&CK
• ATT&CK for Cloud
• MITRE D3FEND (defensive counterpart; optional)
• MITRE ATLAS
• The Pyramid of Pain