MITRE ATT&CK mapping

MITRE ATT&CK® describes adversary behavior. Use these conditional references to annotate demonstrated attack steps; a vulnerability name alone does not establish a mapping. This curated Enterprise selection is not an exhaustive vulnerability taxonomy, a required testing checklist, or evidence of an incident. No direct mapping is a valid result.

Verified against official technique pages on 14 September 2026, with ATT&CK v19.2 current. Enterprise v19 split Defense Evasion into Stealth and Defense Impairment; Mobile retains its separate taxonomy. The tactic labels below follow current Enterprise pages. Version history, v19 changes, v19.2 release.

Choose the right reference layer#

Keep the vulnerability classification, demonstrated behavior, test coverage, and severity in separate fields. They answer different questions and can coexist in the same report. The relationships below are a practical annotation convention, not an official automatic crosswalk.

There is no universal one-to-one conversion. A single SSRF weakness may enable several different behaviors, while several different weaknesses may enable the same behavior. An ATT&CK label neither increases a bounty nor substitutes for the impact argument. A count of mapped techniques is not a severity score.

Choose a reportable CWE root cause#

Catalog badges are candidate references. Before putting a CWE in a report, read its current Vulnerability Mapping Notes, including whether its use is allowed, requires review, or is discouraged. Explain the implementation mistake instead of copying a category name from a checklist. MITRE root-cause guidance.

Several badges are alternatives, not proof of several independent flaws. Describe a causal chain only when the evidence supports its distinct steps. When implementation details are unavailable, record the uncertainty rather than choosing an artificially precise root cause.

Map from evidence in six steps#

1. Write the observed action first. Identify the actor's starting access, the affected component, the operation performed, the boundary crossed, and the resulting access. Keep a separate sentence for untested follow-on possibilities.
2. Select the domain and environment. These cards are Enterprise references. Check the technique's platform list and description; a similarly named Mobile behavior may have a different ID. A mobile application's backend API can still have an Enterprise-relevant behavior.
3. Find candidates using the action. Search for token acquisition, token reuse, trust modification, or private-repository collection. Do not search only for a vulnerability label and accept the first apparent match.
4. Read the full technique and nearest alternatives. Confirm its objective, mechanism, and boundary. Use a sub-technique only when the evidence supports that specificity. Otherwise retain a parent technique, mark the relationship conditional, or record no direct mapping.
5. Attach the evidence reference. Link the sanitized request, test fixture, process trace, audit event, or reproduction step. Label the result demonstrated on the authorized target, reproduced in an isolated lab, or hypothetical. These labels prevent a lab capability from becoming an unsupported incident claim.
6. Record the version and reviewer rationale. Include the technique URL, domain, catalog version, verification date, and why alternatives were rejected. Select only the tactic justified by this step; a card's complete official tactic list is context, not proof of every goal.

ATT&CK describes tactics as goals and techniques as actions; its tactics are not a compulsory ordered sequence. The workflow above is this manual's application of those distinctions. MITRE FAQ.

Worked mapping decisions#

T1190 requires a demonstrated initial-access relationship to an Internet-facing host or system. The issue may be injection, deserialization, or a configuration flaw, but its mere presence in a web application is insufficient. Likewise, a BOLA affecting actual cloud-stored confidential objects may support T1530; record that storage context rather than inheriting the mapping from the word BOLA. T1190, T1530.

Reusable report annotation#

weakness:
  id: CWE-918
  rationale: URL validation permits requests to the fixture metadata service.
attack:
  domain: enterprise-attack
  catalog_version: '19.2'
  checked_at: '2026-09-14'
  technique: T1552.005
  demonstrated_tactic: Credential Access
  evidence_level: isolated-lab-reproduction
  evidence_refs: [request-04, metadata-fixture-response]
  rationale: The response disclosed the fixture workload credential.
  limitations: No production credentials accessed; cloud token reuse untested.
  incident_attribution: none

For a weak relationship, replace the technique with null and explain: Object authorization failure demonstrated; no sufficiently specific ATT&CK behavior established. Preserve the vulnerability and its impact; an empty mapping is not a failed finding.

Review checklist and boundaries#

• Root cause and demonstrated behavior are separate.
• The domain, platform, ID, name, and current technique status were checked.
• Each asserted step has an evidence reference and starting privileges.
• Token acquisition, token reuse, role grants, and trust changes are distinguished.
• Hypothetical follow-on actions are explicitly labelled and excluded from demonstrated coverage.
• A lab result is not described as an incident or attributed to an actor.
• No additional persistence, collection, or scope expansion was performed merely to fill a matrix.
• The report includes limitations, cleanup, severity reasoning, and a reproducible regression condition.

For device-side Android/iOS behavior, consult the Mobile matrix; do not copy Enterprise IDs by name. For Web3 reentrancy or oracle manipulation, no direct Enterprise mapping is often appropriate. For AI-specific prompt injection or model manipulation, evaluate MITRE ATLAS separately, with its own identifiers and version. Conventional follow-on behavior, such as demonstrated application-token theft, can still be annotated independently. ATLAS maintains a distinct knowledge base for adversarial behavior targeting AI systems. Official ATLAS data.

Reverse references in this manual mean that a playbook discusses a technique under stated conditions. They do not certify that every vulnerability in that family implements it, that a tool detected it, or that the target has experienced it.

Conditional technique references#