What Is MITRE ATT&CK? Tactics, Techniques and Rule Tagging

The matrix, in numbers

The Enterprise matrix on attack.mitre.org lists 15 tactic columns, and Discovery alone carries 34 techniques. Persistence holds 22, Execution 20, Command and Control 18. Those columns are not a kill chain in the sequential sense. They are buckets for adversary goals, and a single intrusion can touch Discovery six times and Exfiltration never.

The same matrix covers 11 platforms: Windows, macOS, Linux, PRE, Office Suite, Identity Provider, SaaS, IaaS, Network Devices, Containers and ESXi. That platform list is the reason a technique like Valid Accounts (T1078) has sub-techniques for Default, Domain, Local and Cloud accounts. The behavior is the same. The telemetry that proves it is completely different.

One detail that bites people with old Navigator layers on disk. The live Enterprise matrix we pulled shows Stealth (30 techniques) and Defense Impairment (18 techniques) as separate columns, while the Sigma tag specification still defines defense-evasion as its tactic tag. Version drift between ATT&CK releases and your tooling is normal. Pin the version you map against and record it.

Tactic, technique, sub-technique

The hierarchy is three levels and only three. Tactic is the why (Credential Access). Technique is the how (OS Credential Dumping, T1003). Sub-technique is the specific how (LSASS Memory, T1003.001). Sub-technique IDs are the parent ID plus a three-digit suffix.

Detection engineers care about the bottom level, because that is where the artifact lives. T1059 tells you nothing actionable. T1059.001 tells you to look at powershell.exe process creation and Event ID 4104 script blocks. T1059.003 sends you to cmd.exe command lines instead. Red Canary's Threat Detection Report ranks both in its top ten, along with T1078.004 (Cloud Accounts), T1530 (Data from Cloud Storage), T1105 (Ingress Tool Transfer), T1114.003 (Email Forwarding Rule), T1047 (WMI), T1204.004 (Malicious Copy and Paste), T1564.008 (Email Hiding Rules) and T1027 (Obfuscated Files or Information).

Worth reading that list twice. Four of the ten are identity, cloud or email techniques, not endpoint. If your rule catalog is 90 percent Windows process creation, your coverage claim is about one platform column out of eleven.

The ID is the join key

ATT&CK IDs are useful because they let unrelated systems talk. A CTI report, a detection rule, an adversary emulation test and a control assessment can all carry T1059.001 and be joined on it. CISA describes ATT&CK as a common language for threat actor analysis, and points out the knowledge base carries details on 100+ threat actor groups plus the software they use.

Sigma formalises the ID space in its tag appendix, version 2.1.0, released 2025-08-02. The namespace is not just techniques.

tags:
  - attack.t1059.001        # technique or sub-technique
  - attack.execution        # tactic
  - attack.g0016            # group
  - attack.s0154            # software
  - attack.ds0009           # data source
  - attack.m1042            # mitigation
  - car.2016-04-005         # CAR analytic reference
  - stp.4                   # Summiting the Pyramid analytic robustness
  - tlp.clear

The 2.1.0 release added the Data Sources, Mitigations and Assets prefixes plus a d3fend namespace. The stp namespace scores analytic robustness 1 to 5, with an optional event robustness letter (A for application, U for user-mode, K for kernel-mode), so stp.3k means analytic level 3 against a kernel-mode event source.

Tagging a rule so the mapping survives review

Here is a lab rule we wrote to show the tagging pattern, not a novel detection. Encoded PowerShell is a well-worn example precisely because everyone already has the telemetry.

title: Encoded PowerShell command line
id: 8e2b1f04-6c7a-4f1e-9a3d-2b5c7d10ae41
status: experimental
description: Detects powershell.exe invoked with an encoded command argument
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    - Image|endswith: '\powershell.exe'
    - OriginalFileName: 'PowerShell.EXE'
  selection_enc:
    CommandLine|contains:
      - ' -enc '
      - ' -encodedcommand '
      - ' -ec '
  condition: all of selection_*
falsepositives:
  - Software deployment tooling that wraps scripts in encoded commands
  - Monitoring and backup agents invoking scheduled PowerShell
level: medium
tags:
  - attack.execution
  - attack.t1059.001

What it catches: any process creation event where the image resolves to PowerShell and the command line carries a recognised encoded-command switch. It works off Sysmon Event ID 1 or Security Event ID 4688 with command line auditing enabled.

What it misses, and this is the honest part. PowerShell accepts abbreviated parameters, so -e and -enco are valid and are not in the selection list. Anything that hosts System.Management.Automation.dll without spawning powershell.exe never produces the process event at all. If the binary is renamed and your sensor does not populate OriginalFileName, the image match fails. Known false positives are software distribution agents and vendor installers, which in our lab generated the only hits we saw during idle periods. We did not test this rule against PowerShell 7 (pwsh.exe) paths.

If you want the tagged equivalents rather than a starting template, browse the catalog at /rules?domain=windows.

CAR, and why analytics sit outside ATT&CK

MITRE keeps its analytics in a separate repository on purpose. The Cyber Analytics Repository (CAR) is a knowledge base of analytics built against the ATT&CK adversary model, Apache-2.0 licensed, with implementations aimed at specific tools such as Splunk and EQL. Each CAR analytic carries a hypothesis, an information domain (host, network, process, external), references to the ATT&CK techniques and tactics it detects, pseudocode, and a unit test that triggers it.

The repository README states the split plainly.

It's critical to keep how we articulate threats with ATT&CK separate from a set of possible ways to detect them with the analytics.

That is the right instinct for your own catalog too. A technique has many detections and each one is environment-specific. CAR also ships BZAR, a library of Zeek scripts focused on SMB and RPC traffic, and has partnered with OSSEM to use its Common Data Model. Field normalisation is the boring half of every mapping exercise.

Mapping without fooling yourself

CISA published Best Practices for MITRE ATT&CK Mapping in June 2021 with HSSEDI and updated it in January 2023. The update added coverage of common analytical biases, mapping mistakes and specific guidance for ICS. Read it before you map a report, because most mapping errors are the same three.

1. Mapping the tool instead of the behavior. Cobalt Strike is not a technique.

2. Mapping to a parent technique when the evidence supports a sub-technique, or the reverse, claiming T1003.001 when all you have is a process access event.

3. Mapping intent you inferred rather than behavior you observed. If the report does not say how the actor got in, you cannot map Initial Access.

The hedge we use in our own notes: if the artifact would not survive a hostile review, tag the parent technique and write down what is missing.

Coverage math

A heatmap where 60 percent of cells are green is a claim about rule counts, not about detection. Two questions kill most heatmaps. Which log sources are actually collected on which hosts, and when did each of those rules last fire on real data. Start with the second, because it is a query.

SELECT technique_id,
       COUNT(DISTINCT rule_id) AS rules,
       COUNT(*)                AS alerts_90d,
       MAX(ts)                 AS last_seen
FROM alerts
WHERE ts > now() - INTERVAL '90 days'
GROUP BY technique_id
ORDER BY alerts_90d DESC

Techniques with rules but zero alerts in 90 days fall into two piles: genuinely rare behavior, and rules pointed at a log source nobody is shipping. Only host-by-host source inventory tells you which. Techniques with hundreds of alerts and no closed investigations are tuning debt.

One column of ATT&CK is worth checking against your own rules first. Search the catalog by ID if you want to see whether a technique has coverage at all, for example /rules?q=T1059.001.

Technique mapping reference

Summary

ATT&CK is a taxonomy of adversary behavior with 15 Enterprise tactics and 11 platforms, and its value to a detection team is the stable ID that joins intel, rules and tests. Tag rules with the Sigma attack namespace at sub-technique granularity where the evidence supports it, and use stp if you want the robustness of the analytic recorded next to the mapping. Keep the analytics in your own catalog, not in the taxonomy, which is exactly why MITRE keeps CAR separate from ATT&CK. Treat coverage heatmaps as a claim to verify, starting with which log sources you actually collect. When you cannot ground a mapping in an artifact, map the parent technique and note the gap.

Collect first, per platform:
  Windows   4688 (with command line auditing), 4104, 4624, 4625, 5145, 7045
  Sysmon    1 (process create), 3 (network), 7 (image load), 11 (file create), 13 (registry)
  Identity  sign-in logs, MFA method registration, conditional access changes
  Cloud     control-plane audit trail, storage object access logs
  Email     mailbox audit, transport rule and forwarding rule changes

Tag namespaces to standardise on:
  attack.tNNNN[.NNN]   technique / sub-technique
  attack.<tactic>      tactic
  car.YYYY-MM-NNN      CAR analytic reference
  stp.N[a|u|k]         analytic and event robustness