Module 8 — MITRE ATT&CK

A coverage matrix, fresh from a review:

Technique	Status
T1552.005 Cloud Instance Metadata API	✅ covered (DET-003)

The next week the fix ships: LAB_MODE=false, and metadata fetches are blocked. Someone tries anyway. The API logs ssrf_blocked. DET-003 watches ssrf_metadata_access. Nothing fires. The cell stays green.

The matrix didn’t lie on purpose. It recorded that a rule exists, and a rule existing isn’t the same as seeing the behaviour. In this module you fill in a matrix from what you actually observed, and you write down where each cell could be wrong.

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

Start at the bottom box, not the top. What you have is a procedure: GET /notes/2 as alice, owner: bob. Ask what it achieved: Alice collected a document. That points at a technique, and only then a tactic. “IDOR” is OWASP’s word for how. ATT&CK wants to know what the behaviour did. The top box, the adversary’s goal, is the one you fill in last and are least sure of.

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.

Threat hunting (idea 10). A hunt starts from a hypothesis, names the technique, and searches a data source you already store. An alert is someone else's hypothesis that already fired. A hunt is yours, including the case where the search returns nothing and you write down the gap.

flowchart LR
  hypo["hypothesis"] --> tech["technique you can name"]
  tech --> source["a log you actually keep"]
  source --> search["search"]
  search --> out["a row, or a gap"]

Hypothesis: a valid user read a note they do not own, and no case was opened. The data source is the audit event cross_user_note_access. soc-lite already stores it.

curl -s 'http://127.0.0.1:8090/events?event=cross_user_note_access'

An empty list is a result. Either the behavior did not happen, or the API never emitted the event. Those two explanations are the gap row.

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.

Worked scene — mapping DET-002 from evidence

Hypothesis. DET-002 is a web bug, so it is T1190 Exploit Public-Facing Application.

1. Expect the evidence to show an exploit. Got: a cross_user_note_access line: actor: alice, note_id: 2, owner: bob. A valid session reading data it shouldn’t.
2. Ask what the behaviour achieved. Alice didn’t gain a foothold. She collected a document. That points at Collection, T1213 Data from Information Repositories.
3. Ask where the mapping could be wrong. The vulnerability class (BOLA) is how she got in. T1190 is still defensible as a second mapping, but not the only one.

What that implies. Record T1213 with medium confidence, T1190 as the alternative, and the limitation: the rule sees a successful read, not an attempt. That row is worth more than one confident wrong ID.

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

Write down three answers before you run anything:

1. Which five rule IDs will appear in /alerts, and what will each alert ID’s group key be?
2. For DET-002, which tactic would you map it to if you hadn’t read the YAML, and why might that be wrong?
3. Which behaviour does the sim never generate, so no cell should be green for it?

Then run the steps. If a result surprises you, 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 the coverage template to docs/capstone/work/attack-coverage.md and put your table there, one row per rule. Don’t edit the template itself. Your work folder is gitignored, so this draft carries forward to the capstone.
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 do all of these 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

• 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.
• Exit criteria — meet this module’s list.

How these are graded: assessment.

Further reading

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