L61 · MITRE ATT&CK

Module 9: Detection and Incident Response · ~20 min · Lesson 61 of 71

🎯 What you'll learn

• Tactics (why), techniques (how), sub-techniques (how exactly) and procedures (what one attacker did)
• How to read an ID like T1552.005, and where the Cloud and Containers matrices fit a typical API stack
• How to map a real breach (Capital One, Uber) onto ATT&CK
• How defenders use it (coverage heatmaps, the Navigator) and where it misleads

🔥 Why this matters

A CISA advisory in your team channel says the actor used T1078.004, T1621 and T1530. A GuardDuty finding is tagged "Credential Access", and the security report claims "62% ATT&CK coverage". Then your manager asks: "Would we catch what happened to Capital One?" ATT&CK is the shared vocabulary that lets advisories, findings, detection rules and postmortems point at the same things.

1. From a story to a catalog

L03's Cyber Kill Chain tells an intrusion as seven stages: a good story, but coarse. An attacker with a stolen password skips half of them.

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a free, public catalog of attacker behavior seen in real intrusions, with sources. MITRE started it in 2013, published it in 2015, and releases twice a year (April and October). This lesson uses v20.1 (October 2026). Of its three domains, Enterprise covers cloud and API work; the others are Mobile and ICS.

2. Four levels: why, how, how exactly, what they did

 TACTIC          the attacker's goal at this step      "why"
 TA0006          Credential Access
   │ is achieved by
   ▼
 TECHNIQUE       one way to reach that goal            "how"
 T1552           Unsecured Credentials
   │ more specifically
   ▼
 SUB-TECHNIQUE   a narrower variant                    "how
 T1552.005       Cloud Instance Metadata API            exactly"
   │ as done by one actor, once
   ▼
 PROCEDURE       "made a WAF on EC2 fetch 169.254.169.254
                  /latest/meta-data/iam/security-credentials/
                  and got the role's keys"   (Capital One, L47)

• A tactic is the attacker's short-term goal, such as Persistence (ID TA####).
• A technique is a way to reach that goal (ID T####).
• A sub-technique narrows a technique: the parent ID plus .NNN, so T1552.005 is under T1552.
• A procedure is how a real group or tool actually did it. Procedures have no ID; they're the "Procedure Examples" on each technique page.

Security people shorten the set to TTPs (tactics, techniques and procedures).

One technique can serve several tactics. T1078 Valid Accounts sits under Initial Access, Persistence, Privilege Escalation and Stealth: a stolen login gets you in, keeps you in, and blends in.

Each technique page lists platforms, procedure examples, mitigations (M IDs, such as M1032 Multi-factor Authentication) and, since v18, detection strategies.

The Enterprise matrix has 15 tactics in v20. Read them roughly left to right, but attackers loop:

 Reconnaissance → Resource Development → Initial Access →
 Execution → Persistence → Privilege Escalation → Stealth →
 Defense Impairment → Credential Access → Discovery →
 Lateral Movement → Collection → Command and Control →
 Exfiltration → Impact

A recent change. v19 (April 2026) split Defense Evasion in two: Stealth (blending in) kept TA0005, and Defense Impairment (TA0112, breaking your controls) is new. Some techniques got new IDs: "disable or modify cloud logs" moved from T1562.008 to T1685.002 (the old page redirects). Older tools and vendor findings will use the old names for a while.

3. One catalog, several matrices

Enterprise techniques are tagged with platforms, and a "matrix" is a view filtered to some of them. v20.1 has 227 techniques and 479 sub-techniques. The views that matter for a typical API stack:

The Containers matrix has 10 of the 15 tactics (no Reconnaissance, Resource Development, Collection, Command and Control or Exfiltration). Real attacks cross matrices: leave the pod and you're in IaaS.

4. Mapping a real incident: Capital One (L47)

To map an incident, ask of each step: which tactic did it serve, and which technique was it? L47's attack path becomes:

 L47 step                         TACTIC            TECHNIQUE
 ───────────────────────────────  ────────────────  ──────────
 1 connects via TOR and a VPN     Command and       T1090.003
                                  Control           Multi-hop
                                                    Proxy
 2 WAF made to fetch an internal  Initial Access    T1190
   URL (SSRF) [reported]
 3 IMDSv1 returns role keys       Credential        T1552.005
                                  Access
 4 uses the role's keys from      Initial Access,   T1078.004
   outside AWS                    Stealth           Cloud
                                                    Accounts
 5 "ls": lists 700+ buckets       Discovery         T1619
 6 "sync": copies the data        Collection        T1530
 7 data ends up on her machine    Exfiltration      no neat fit

First, mapping is a judgment call: step 7 has no clean technique, because the "exfiltration" was the same S3 API call as the collection. Write down your reasoning. Second, each row is a question for your own estate: "Would we see this? Would anything stop it?" For row 3: IMDSv2 with hop limit 1 (L35), and an alert on instance credentials used outside AWS (L52).

5. How defenders use it

Coverage heatmaps. Score each technique that matters to you by how well you'd catch it:

 TECHNIQUE                       SCORE
 T1190      Exploit app          ■■□  2
 T1552.005  Cloud IMDS           ■■■  3
 T1078.004  Cloud accounts       ■□□  1
 T1621      MFA push spam        □□□  0
 T1619      Bucket discovery     ■□□  1
 T1530      Cloud storage        ■■□  2
 T1685.002  Disable cloud log    ■■■  3

 0 = no data   1 = logged, no rule
 2 = rule that alerts   3 = rule tested by simulation (L62)

Rows at 0 and 1 are your backlog. T1621 is 0 because IdP logs aren't in the SIEM: a logging gap (L60).

The ATT&CK Navigator is MITRE's free web app for this. It draws the matrix, lets you score, color and comment on techniques, and saves a JSON layer file. Layers combine: "techniques used by groups that target finance" minus "techniques we detect" leaves your gaps. A layer is just JSON, so you can generate it from your detection repo on every merge (L62).

ATT&CK IDs also tag detection rules (L62), let you check an advisory against your heatmap, and give red and purple teams a menu to test.

6. Where ATT&CK misleads

• Coverage percentages are vanity metrics. One narrow rule turns a technique green, and T1078 Valid Accounts can't be "covered" by any single rule: every real login looks like it.
• Not every technique matters to you. Prioritize by what attackers of companies like yours do (deep dive 2), not by filling the grid.
• It's built from public reporting, so it leans to Windows and lags new tricks.
• It's about behavior, not bugs. A BOLA flaw (L40) isn't a technique; exploiting it maps, at best, to T1190. CVEs and CWEs (L29) are a separate catalog.
• It's not a maturity model or a compliance checklist.

🧪 Worked example: mapping Uber (L28)

The same method on L28's timeline ([Uber] confirmed, [claim] attacker's claim):

Turned into questions for your estate:

1. T1621. Do IdP MFA events reach the SIEM? "Five denied pushes, then an approve" is an easy rule once they do (L28's first deep dive).
2. T1552.001. Would a credential committed to a repo or DAG be caught? (Secret scanning, L57.)
3. T1555.005. Would one identity reading 50 secrets in an hour alert? (L62 builds this.)

No malware and no exploit, only valid credentials: that's why the Kill Chain fits Uber badly and ATT&CK fits it well.

🛠 Try it (optional, ~5 min)

Part 1: open attack.mitre.org/techniques/T1552/005/ and read Procedure Examples, Mitigations (look for IMDSv2) and Detection Strategy. Then open mitre-attack.github.io/attack-navigator/, create an Enterprise layer, and score T1552.005.

Part 2: ATT&CK is published as STIX JSON on GitHub (about 55 MB). List the Containers techniques:

mkdir -p ~/tmp/attack && cd ~/tmp/attack
curl -sSLo ea.json https://raw.githubusercontent.com/mitre-attack/\
attack-stix-data/master/enterprise-attack/enterprise-attack.json
jq -r '.objects[]
  | select(.type=="attack-pattern")
  | select((.revoked|not) and (.x_mitre_deprecated|not))
  | select(.x_mitre_platforms | index("Containers"))
  | "\(.external_references[0].external_id)  \(.name)"' \
  ea.json | sort | head -4

Output from v20.1 (48 lines in total):

T1036  Masquerading
T1036.005  Match Legitimate Resource Name or Location
T1036.010  Masquerade Account Name
T1046  Network Service Discovery

Change "Containers" to "IaaS" and compare. Which ones would show up in CloudTrail?

🧠 Key takeaways

• Tactic = why, technique = how, sub-technique = how exactly, procedure = what one actor really did.
• IDs are stable handles, but they change: v19 split Defense Evasion into Stealth and Defense Impairment.
• Cloud and Containers matrices are filtered views of one Enterprise catalog; real attacks cross them.
• Mapping an incident turns a story into questions: would we see this, would anything stop it?
• Score coverage honestly (no data, logged, alerting, tested); a grid percentage means little.

📖 Words to know

⏭ Next time

L62 turns techniques into alerts: what a SIEM does, and how to write, test and tune a Sigma rule.

The Containers matrix is small, and most people never look at it. Walking one realistic path through an EKS cluster shows which techniques matter and, more usefully, where the attacker leaves the container world for the cloud.

The path

A made-up quote-api pod in namespace pricing has a remote code execution bug. Its ServiceAccount is bound, by mistake, to a Role that can create pods (L27's second deep dive).

 1 RCE in quote-api ............ T1190  Exploit Public-Facing App
      │                          (Initial Access)
      ▼
 2 read the mounted SA token ... T1528  Steal Application
      │  /var/run/secrets/...    Access Token (Credential Access)
      ▼
 3 list pods, secrets, roles ... T1613  Container and Resource
      │                          Discovery (Discovery)
      ▼
 4 create a privileged pod ..... T1610  Deploy Container
      │  with hostPath: /        (Execution)
      ▼
 5 break out to the node ....... T1611  Escape to Host
      │                          (Privilege Escalation)
      ▼  ── leaves the Containers matrix ──
 6 node's IMDS → node role ..... T1552.005 (Credential Access,
      │                          IaaS only)
      ▼
 7 use the role from outside ... T1078.004 → T1530 (IaaS)

Step 2 is in ATT&CK's own words: the T1528 page says a compromised container's service account token can give "access to Kubernetes API commands". Step 6 is where L35's advice (IMDSv2, hop limit 1, pods with their own roles through IRSA or Pod Identity) cuts the path.

What sees each step

Step 2 is the useful lesson: some techniques leave no log at all. You cover them by preventing them (no token mounted unless the pod needs it, automountServiceAccountToken: false) and by catching the next step, where the stolen token is used.

Worked example: a coverage note in a layer file

Turn the table into a Navigator layer so it shows up on the team heatmap. Scores use the scale from section 5; the comment records why:

{
  "name": "EKS pricing cluster coverage",
  "versions": {"attack": "20", "navigator": "5.3.2",
               "layer": "4.5"},
  "domain": "enterprise-attack",
  "techniques": [
    {"techniqueID": "T1528", "score": 0,
     "comment": "No telemetry. Prevent: no automount."},
    {"techniqueID": "T1613", "score": 2,
     "comment": "Audit log rule: SA lists secrets"},
    {"techniqueID": "T1610", "score": 3,
     "comment": "Kyverno blocks privileged; tested"},
    {"techniqueID": "T1611", "score": 1,
     "comment": "GuardDuty runtime on, no triage rule"}
  ],
  "gradient": {"colors": ["#ff6666", "#66cc66"],
               "minValue": 0, "maxValue": 3}
}

The layer format (4.5) and Navigator version (5.3.2) are current as of late 2026; Navigator will offer to upgrade older layers when you open them. Upload it with Open Existing Layer.

🧠 Extra takeaways

• The Containers matrix covers the cluster; the moment an attacker reaches node credentials, you're in the IaaS matrix.
• T1528 (stealing a mounted service account token) leaves no log; prevent it and detect the token's use instead.
• The EKS audit log covers discovery and pod creation; runtime tools cover escapes; CloudTrail covers what happens after.
• Record why each score is what it is, so the next person can trust the heatmap.

There are about 700 techniques and sub-techniques. You can't detect them all, and you shouldn't try. Threat-informed defense means choosing what to build by asking which techniques the attackers most likely to hit you actually use.

Groups, software and campaigns

Besides techniques, ATT&CK tracks:

• Groups (IDs G####): named threat actors, with every technique they've been reported using. Example: LAPSUS$ (G1004), the group Uber linked to its attacker (L28).
• Software (S####): malware and tools, such as AADInternals (S0677).
• Campaigns (C####): specific operations within a time window.

For a financial company running on AWS and SSO, one natural pair to study is LAPSUS$ and Scattered Spider (G1015). Both are loose, largely young extortion crews known for phone-based social engineering, MFA fatigue and SaaS and cloud theft rather than custom malware.

Worked example: what do both groups do?

Using the STIX file from the Try it, list techniques reported for both groups. Groups link to techniques through relationship objects of type uses:

cat > both.jq <<'EOF'
(.objects | map(select(.type=="intrusion-set"))
  | map({key: .id, value: .external_references[0]
                                 .external_id})
  | from_entries) as $g
| (.objects | map(select(.type=="attack-pattern"
      and (.revoked|not) and (.x_mitre_deprecated|not)))
  | map({key: .id, value: "\(.external_references[0]
          .external_id)  \(.name)"})
  | from_entries) as $t
| [.objects[] | select(.type=="relationship"
      and .relationship_type=="uses" and (.revoked|not))
  | select($g[.source_ref] == ("G1004", "G1015"))
  | select($t[.target_ref])
  | {g: $g[.source_ref], t: $t[.target_ref]}]
| unique | group_by(.t)
| map(select(length == 2) | .[0].t) | .[]
EOF
jq -r -f both.jq ea.json | sort

Against v20.1 this prints 21 techniques. A selection:

T1078.004  Cloud Accounts
T1098.003  Additional Cloud Roles
T1133  External Remote Services
T1213.003  Code Repositories
T1213.005  Messaging Applications
T1555.005  Password Managers
T1578.002  Create Cloud Instance
T1598.004  Spearphishing Voice
T1621  Multi-Factor Authentication Request Generation
T1684.001  Impersonation

The list reads like L28 replayed. Some entries (NTDS dumping, Windows domain groups) matter less if your crown jewels are in AWS and SaaS, so filter by the platforms you actually run.

From list to backlog

Score each remaining technique on three questions, then sort:

The top of that table is your next quarter's detection work. Repeat it when a new advisory comes out. CISA advisories include ATT&CK tables precisely so you can do this.

Caveats. A group page lists what has been reported, not everything a group does, and attribution is often disputed (at the London trial, prosecutors said Uber's attacker acted on his own, not for LAPSUS$). Treat group pages as a strong hint, not a complete list.

🧠 Extra takeaways

• Prioritize techniques used by attackers who target companies like yours, not the whole grid.
• Group (G), software (S) and campaign (C) pages tie techniques to real actors.
• The STIX data makes it a five-minute query to compare groups, or a group against your heatmap.
• Group pages are incomplete and attribution is often uncertain; use them to rank, not to rule things out.