DE0.8 MITRE ATT&CK

What ATT&CK is

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a knowledge base of adversary behavior based on real-world observations. It catalogs the techniques attackers use across the attack lifecycle, organized into 14 tactical categories (the attacker's objective at each stage) with approximately 200 techniques (the specific methods used to achieve each objective) and hundreds of sub-techniques (variations of each method).

The framework is not theoretical. Every technique in the matrix is documented from real intrusions — observed by incident responders, threat intelligence analysts, and red teams.

The entries describe what the technique does, which platforms it applies to, what data sources contain evidence of its use, and which threat groups have been observed using it. When the framework says T1003.001 (OS Credential Dumping: LSASS Memory) is used by APT28, APT29, FIN6, and Lazarus Group, that means those groups were observed using it in documented intrusions.

For detection engineering, ATT&CK serves three purposes that no other framework provides.

Estimated time: 30 minutes.

ATT&CK as the coverage measurement standard

The coverage percentage from Section 3 — 10.3% — is calculated against ATT&CK. Every analytics rule in a detection program maps to one or more ATT&CK techniques.

The number of distinct techniques with active detection, divided by the number of techniques relevant to the organization, produces the coverage percentage. Without ATT&CK, there is no standard denominator. "How many attacks can we detect?" has no denominator without a catalog of attacks to measure against.

ATT&CK provides that catalog. It gives detection engineers a common language for what they cover and what they don't. "We cover T1566.002 (Spearphishing Link) but not T1566.001 (Spearphishing Attachment)" is a precise statement that another detection engineer, a threat intelligence analyst, or a red team member can evaluate. "We cover some phishing" is not.

The heatmap is the visual representation of coverage mapped to ATT&CK. Tactics run across the top (Initial Access, Execution, Persistence, ..., Impact). Techniques fill the cells. Green cells have active detection rules.

Red cells have none. The heatmap immediately shows which tactical categories are well-covered and which are blind. In a typical environment, Defense Evasion is entirely red — 42 techniques, zero detection rules. That's a visual finding that communicates more in one glance than a paragraph of explanation.

ATT&CK as the detection development framework

When the detection engineer sits down to build the next rule, the question is: which technique? ATT&CK provides the answer through a structured prioritization process.

The engineer starts with the organization's threat landscape — which threat groups target this industry? Those groups have documented technique profiles in ATT&CK.

Mandiant attributes threat groups to specific industries and publishes the techniques each group uses. CrowdStrike's adversary profiles do the same. The overlap between "techniques this group uses" and "techniques we don't currently cover" is the priority list.

Here's how that works in practice. Consider a manufacturing company with defense contracts. The threat groups that target manufacturing and defense include APT41 (China, targeting defense supply chain), APT28 (Russia, targeting defense and government contractors), and FIN7 (financially motivated, targeting manufacturing and retail). Each group's ATT&CK profile lists the techniques they've been observed using.

APT41 uses T1190 (Exploit Public-Facing Application), T1059.001 (PowerShell), T1003.001 (LSASS Memory), and T1048 (Exfiltration Over Alternative Protocol). FIN7 uses T1566.001 (Spearphishing Attachment), T1204.002 (Malicious File), T1059.001 (PowerShell), and T1071.001 (Web Protocols). The union of these technique sets, minus the techniques the organization already covers, is the prioritized detection backlog. The techniques that appear in multiple group profiles get higher priority — they're more likely to be used regardless of which specific group targets the organization.

Each ATT&CK technique entry includes data sources — the telemetry types that contain evidence of the technique. T1078.004 (Cloud Accounts) lists "Logon Session: Logon Session Creation" and "User Account: User Account Authentication" as data sources, which maps to SigninLogs in the Microsoft stack.

T1003.001 (LSASS Memory) lists "Process: Process Access" and "Process: OS API Execution" which maps to DeviceProcessEvents. The detection engineer uses these data source mappings to determine whether they have the telemetry to build a rule — if the data source isn't connected, the technique can't be detected regardless of how good the KQL is. A technique that's high priority but has no available data source gets flagged as a data gap, not a rule gap.

The technique entry also includes detection guidance — prose descriptions of what to look for. These descriptions are starting points for hypotheses, not finished detection rules. The ATT&CK detection guidance for T1003.001 mentions monitoring for access to the LSASS process memory.

The detection engineer's hypothesis adds environment-specific precision: "monitor for processes accessing LSASS memory where the calling process is not a known security tool or OS component, the access rights include PROCESS_VM_READ, and the calling process was started by a non-SYSTEM account." That specificity — which security tools to whitelist, which access rights to target, which account context to filter — is what turns generic framework guidance into a testable, environment-specific hypothesis. The framework provides the direction. The detection engineer provides the precision.

ATT&CK as the communication language

Detection engineering produces artifacts — rules, specifications, coverage reports, board presentations — that need to be understood by people who are not detection engineers. ATT&CK provides the shared vocabulary that makes this communication possible.

The SOC analyst needs to know which technique a rule detects so they can contextualize the alert during triage. When a rule fires and the incident shows "MITRE ATT&CK: T1137.001 — Office Application Startup: Outlook Rules," the analyst immediately knows the rule detected inbox rule manipulation — a persistence technique typically used after account compromise.

That context shapes their investigation: they look for the compromised authentication event that preceded the inbox rule creation, check whether the inbox rule is hiding financial emails, and search for downstream activity (data access, email sends) from the same session. Without the ATT&CK mapping, the alert says "suspicious inbox rule" and the analyst has to figure out the context from scratch.

The threat intelligence analyst needs to know which techniques are covered so they can assess exposure when a new threat report drops.

When CrowdStrike publishes a report on SCATTERED SPIDER using T1078.004 (Cloud Accounts) and T1098.003 (Additional Cloud Credentials), the TI analyst cross-references those technique IDs against the detection program's coverage and immediately knows whether the organization has detections for the campaign's techniques. The answer is a lookup, not an investigation.

The CISO needs to understand coverage in terms that map to external benchmarks.

ATT&CK is the standard that CISA uses in threat advisories, Mandiant uses in M-Trends, CrowdStrike uses in annual threat reports, and insurance underwriters increasingly reference in cyber risk assessments. A board report that presents coverage against ATT&CK is legible to anyone in the security ecosystem — including the board members who read CISA alerts and the cyber insurance broker who evaluates the organization's risk posture.

The red team needs to know what's covered so they can design realistic test scenarios.

An internal or external red team that receives the organization's ATT&CK coverage heatmap can design their engagement to test both covered techniques (do the rules actually fire?) and uncovered techniques (what's the blast radius in the blind spots?). The engagement produces findings that directly feed the detection backlog — technique IDs where the rule failed or didn't exist, mapped to priority and remediation effort.

How ATT&CK is used in this course

Every detection rule in DE3-DE8 is mapped to one or more ATT&CK techniques. The rule specification template includes the technique ID, the tactic, and the data source mapping. The coverage report in DE10 calculates the percentage against the relevant technique set. The board report in DE11 presents the heatmap.

The six attack chains are defined in ATT&CK terms. CHAIN-HARVEST uses T1566.002 → T1557/T1528 → T1137.001 → T1114.002 → T1534. CHAIN-MESH uses T1078.004/T1133 → T1021.002 → T1003.001 → T1562.001/T1490 → T1486. Each technique maps to a specific rule in a specific module. The mapping is the thread that connects the threat model to the detection library to the coverage report.

You don't need to memorize technique IDs.

You need to understand the framework well enough to use it as an organizing principle — to look at a threat report and identify which techniques it describes, to map those techniques to your coverage, and to prioritize the gaps. That understanding develops naturally through the course as you build rules mapped to techniques and track coverage across the heatmap.

The ATT&CK Navigator

The ATT&CK Navigator is a web-based tool that visualizes ATT&CK coverage as a heatmap. You'll use it throughout the course to track which techniques you've built rules for and which remain uncovered. In DE10 (detection-as-code), you'll integrate the Navigator export into your coverage reporting pipeline — the heatmap updates automatically as you deploy new rules.

The Navigator is available at mitre-attack.github.io/attack-navigator.

You create a layer, color-code techniques by coverage status (green for covered, red for uncovered, yellow for partial coverage, orange for coverage with known gaps), and export the layer as a JSON file or image. The exported heatmap is the visual artifact in the board report — it communicates coverage status in one glance more effectively than any table or percentage.

The workflow: after deploying a new detection rule, you update the Navigator layer to mark the technique as covered. After a tuning review reveals a rule has a significant blind spot, you mark the technique as partial.

After a rule is retired because the technique is no longer relevant, you remove the coverage marking. The Navigator layer becomes the living map of your detection program's capability.

Generate the data for your Navigator layer directly from your Sentinel rules. This KQL produces the technique list with coverage status:

// Coverage by tactic — which tactical categories have rules?
SecurityAlert
| where TimeGenerated > ago(90d)
| mv-expand tactic = todynamic(Tactics)
| where isnotempty(tactic)
| summarize
    Rules = dcount(AlertName),
    Techniques = dcount(AlertName)
    by Tactic = tostring(tactic)
| sort by Rules desc

Tactic                Rules  Techniques
────────────────────  ─────  ──────────
CredentialAccess      5      3
InitialAccess         4      2
Persistence           3      2
Execution             2      1
LateralMovement       0      0
Discovery             0      0
Collection            0      0
Exfiltration          0      0
DefenseEvasion        0      0
Impact                0      0

The pattern: rules cluster in the early tactics (Initial Access, Credential Access) and disappear entirely from mid-to-late tactics (Lateral Movement, Collection, Exfiltration, Impact). This is the typical template deployment shape — Microsoft's built-in analytics rules focus on identity-based initial access detection. Nobody built rules for what happens after the attacker is inside. That's the gap the course fills.

The Navigator layer for NE's current state looks like this in JSON — you can import this into the Navigator tool to visualize it:

{
  "name": "NE Detection Coverage — Baseline",
  "versions": { "attack": "16", "navigator": "5.1" },
  "domain": "enterprise-attack",
  "techniques": [
    { "techniqueID": "T1078",     "color": "#059669", "comment": "Template rule — 60% FP" },
    { "techniqueID": "T1110.003", "color": "#059669", "comment": "Template rule — NRT" },
    { "techniqueID": "T1566.002", "color": "#d97706", "comment": "Partial — email only" },
    { "techniqueID": "T1003.001", "color": "#dc2626", "comment": "No rule" },
    { "techniqueID": "T1021.002", "color": "#dc2626", "comment": "No rule" },
    { "techniqueID": "T1486",     "color": "#dc2626", "comment": "No rule" }
  ]
}

Green means covered. Orange means partial coverage (rule exists but quality issues). Red means no rule. In DE10, you'll build an automated pipeline that regenerates this layer file from your Sentinel rule configurations — the heatmap updates every time you deploy a new rule.

Multiple layers can be overlaid.

You might create one layer for your coverage (what you detect), one for your threat landscape (what threat groups targeting your industry use), and one for your data availability (which techniques you have telemetry for). The overlap of all three — techniques that are used against your industry, that you have data for, and that you don't yet cover — is the prioritized detection backlog.

What ATT&CK doesn't tell you

ATT&CK is the standard, but it's not complete and it's not a substitute for thinking. Understanding its limitations prevents over-reliance.

ATT&CK doesn't tell you how good your rule is

A technique marked as "covered" means you have at least one active rule mapped to it. It doesn't mean the rule is well-tuned, tested, or effective. A rule for T1078.004 (Cloud Accounts) that fires on every Medium-risk sign-in and produces 15 false positives per day is technically coverage.

It is not operationally useful coverage. Coverage percentage is a necessary metric but not a sufficient one — it needs to be paired with rule health, false positive rate, and MTTD to tell the complete story.

ATT&CK doesn't tell you which techniques matter most for your environment

The framework catalogs approximately 200 techniques. Not all are equally probable or equally impactful for your organization. A cloud-native SaaS company faces different techniques than a manufacturing company with hybrid infrastructure and physical access vectors.

Threat modeling (DE2) bridges this gap — it maps your specific threat landscape to the ATT&CK techniques that matter for you and ranks them by priority.

ATT&CK doesn't cover everything attackers do

The framework focuses on post-compromise behavior — what the attacker does after gaining access.

It's less comprehensive on pre-compromise activity (reconnaissance, resource development) and on operational security techniques that attackers use to avoid detection during operations. Some detection rules you build — particularly for anomalous behavior patterns and data exfiltration channels — may not map cleanly to a single ATT&CK technique.

That's fine. The framework is an organizing principle, not a constraint.

ATT&CK updates on a different cadence than the threat landscape

New techniques appear in the wild before they appear in the ATT&CK matrix. The framework is updated semi-annually based on contributions from the security community. A novel technique observed in a March incident might not appear in ATT&CK until the October update.

Detection engineers who rely solely on ATT&CK for prioritization will always be six months behind the leading edge. The threat intelligence feeds, incident reports, and hunt findings that drive the detection backlog are more current than the framework itself.

Despite these limitations, ATT&CK remains the best available standard for organizing, measuring, and communicating detection capability. No alternative provides the combination of technique coverage, threat group mapping, data source guidance, and industry adoption that ATT&CK offers. Use it as the foundation. Build beyond it where your threat landscape requires.