| v18.1 ATT&CK version(Dec 2025) | 14 Enterprise tacticsdocumented | 79% of 2024 attackswere malware-free(CrowdStrike, 2025) | 26% increase in cloudintrusions YoY(CrowdStrike, 2025) |
Picture this: an EDR alert fires in your SOC. An analyst opens the ticket, sees ‘Suspicious PowerShell Execution,’ and closes it as a false positive — because PowerShell runs constantly in that environment and nobody has connected the dots between this alert, a DNS anomaly from three hours earlier, and a registry change that happened overnight.
That’s not an analyst failure. That’s a visibility and context failure. And it’s exactly the problem the MITRE ATT&CK framework was built to address.
ATT&CK gives your team a shared language for adversary behavior, a structured map of how attacks actually unfold, and a way to measure where detection coverage has genuine gaps. For MSP teams managing SOC operations across multiple clients, it’s one of the most practically useful tools available — but only if you actually operationalize it. This guide covers how the framework is structured, how to run a real gap assessment, and practical steps for embedding it into daily SOC operations.
ATT&CK stands for Adversarial Tactics, Techniques, and Common Knowledge. MITRE — the nonprofit behind federally funded R&D centers — built the framework in 2013, released it publicly in 2015, and has been refining it with the global security community ever since. As of December 2025, it’s on version 18.1, with 14 tactics, 216 techniques, and 475 sub-techniques in the Enterprise matrix alone.
The core idea is deceptively simple: instead of cataloguing malware hashes or IP addresses (which change constantly), ATT&CK catalogues behaviors. The way an adversary dumps credentials. The way they establish persistence. The way they move laterally. Behaviors are much harder for attackers to change than indicators — and a detection built on behavior survives when the attacker rotates their infrastructure.
ATT&CK is organized into three matrices: the Enterprise Matrix (Windows, macOS, Linux, cloud, containers — where most MSP SOC work lives), the Mobile Matrix (iOS/Android), and the ICS Matrix (Industrial Control Systems — critical if clients touch OT). This guide focuses on Enterprise.
The hierarchy: Tactic = the ‘why’ (e.g., Persistence); Technique = the ‘how’ (e.g., T1059.001: PowerShell); Sub-technique = a more granular variation; Procedure = a specific real-world implementation by a named threat actor.
Detection rules live at the technique and sub-technique level. Coverage assessments happen at the tactic level. That distinction matters a lot when deciding where to spend detection engineering time.
Every attack — ransomware, APT intrusion, insider threat, supply chain compromise — moves through some subset of these 14 stages. The order isn’t always linear, and adversaries don’t use every tactic on every job. But understanding what each one represents helps your team ask the right questions when an incident unfolds.
A few things worth calling out from the full tactic list:
Abstract framework knowledge only becomes useful when you apply it to an actual incident. In a realistic ransomware attack chain — the kind MSP SOC teams see regularly — detectable signals typically appear on Day 1 (PowerShell execution, C2 beaconing) and Day 2 (registry persistence). An analyst who connects those dots has a containment opportunity before credentials are ever touched.
The attacker’s goal is to stay in the Execution-to-C2 gap long enough to establish persistence before anyone notices. Detection engineering built around ATT&CK techniques — particularly early-stage ones like T1059.001 (PowerShell), T1071.001 (Web Protocols C2), and T1547.001 (Registry Run Keys) — is what compresses that detection window.
| The Defender’s Imperative: Shift Detection Left Detection at Impact = too late. Data is encrypted, exfiltrated, or destroyed. Detection at Lateral Movement = containable. Affected systems isolated; credentials rotated. Detection at Execution = excellent. Single endpoint, no spread, clean recovery. Detection at Initial Access = ideal. The intrusion is stopped before it becomes an incident. |
This is where most teams either get enormous value from the framework — or get lost in it. A gap assessment isn’t about coloring in the Navigator heatmap until it looks impressive. It’s about answering one specific question: for the techniques most likely to be used against your clients’ environments, do you have validated, tested detection coverage?
Step 1 — Define Your Threat Profile
Not every technique is equally likely against every client. A healthcare MSP client faces different adversary priorities than a manufacturer with OT systems. Before opening the Navigator, answer: What industries do we serve? What attack vectors are most common there? Which threat actor groups target those industries? What telemetry do we actually have? This threat profile becomes your prioritization lens — you’re targeting the 30–50 most relevant techniques, not 200+.
Step 2 — Map Your Existing Telemetry
Each ATT&CK technique has documented data sources. If you don’t have a data source, you categorically cannot detect the techniques that depend on it. Key ones to verify: process execution logs (Windows Event 4688 / Sysmon Event 1), network/proxy logs, authentication logs (Events 4624/4625/4648), DNS query logs, EDR telemetry, and cloud audit logs (CloudTrail, Azure Activity Log, GCP Audit Log).
Step 3 — Use the ATT&CK Navigator
The ATT&CK Navigator (free at attack.mitre.org) lets you visualize coverage across the matrix. Color each technique by confidence: Green for tested detections in production, Yellow for rules that exist but are untested, Red for known gaps, Grey for not yet assessed.
The honest version of this exercise usually produces a lot of red and grey. That’s the point. The Navigator isn’t a trophy — it’s a diagnostic. The output drives your detection engineering backlog.
Step 4 — Prioritize by Risk, Not Coverage Percentage
A 40% coverage score built around your most likely attack paths is worth more than a 70% score built around obscure techniques that rarely appear in your environment. Prioritize in this order: Initial Access, Execution, and Persistence first; Credential Access and Lateral Movement second; Defense Evasion third; Exfiltration and Impact last.
Tag Every Alert with a Technique ID
When every alert your SIEM or EDR generates is tagged with its corresponding ATT&CK technique ID (e.g., T1059.001 for PowerShell execution), you gain the ability to trend which techniques are active across your clients, correlate multi-source alerts under a single incident narrative, and report to clients in plain language: ‘This quarter we detected 43 Credential Access attempts — here’s what we caught and contained.’ Most SIEM and XDR platforms now support ATT&CK tagging natively.
Build Playbooks Around Tactics, Not Symptoms
Traditional IR playbooks are symptom-driven: ‘If you see ransomware, do X.’ ATT&CK-structured playbooks are tactic-driven: ‘When Credential Access is detected, the protocol is…’ A tactic-based playbook handles novel malware using known techniques. A symptom-based playbook fails against anything it hasn’t seen before. For each of the 14 tactics, document: what to look for, what to collect, who to escalate to, and what the containment steps are.
Run Tabletop Exercises Against Named Threat Actors
ATT&CK’s Groups section documents the specific techniques associated with real-world threat actors — APT29, Lazarus Group, FIN7, BlackCat/ALPHV, and dozens more. Pull the TTP set for a group targeting your client’s industry and ask: ‘If this group came after Client X tomorrow, what would we detect — and what would we miss?’ This surfaces gaps faster than any spreadsheet and produces a prioritized remediation list tied directly to real adversary behavior.
Feed Every Incident Back into Detection Engineering
ATT&CK is a continuous improvement engine, not a one-time project. Every incident should produce: an updated ATT&CK technique mapping for what the attacker actually did, an assessment of which detections fired versus which should have, and at least one new or refined detection rule before the ticket closes. Teams that operate this way see measurable coverage improvements over 6–12 months — converting every real incident into a permanent detection improvement.
Given how widely ATT&CK has been adopted, there’s a corresponding amount of cargo-cult adoption. Here are the most common misapplications:

ATT&CK is the closest thing the security industry has to a shared operating language for adversary behavior. The teams that get real value from it treat it as an operational foundation — embedded in alert tagging, detection engineering, playbook design, and client reporting — not a reference document they read once and shelve.
For MSP SOC teams, ATT&CK solves a genuine problem: how do you maintain consistent, high-quality detection capability across dozens of different client environments, with analysts who vary in experience, using tooling that varies by client? A common framework that structures how everyone thinks about threats, how detections are built, and how incidents are investigated is the answer.
Start with your most common incident types. Map them to ATT&CK. Assess your coverage honestly. Build one new detection rule. Repeat. The framework gets more useful with every iteration.
| Working With TechMonarch We run white-label SOC and NOC operations for MSPs and IT service providers worldwide. ATT&CK-aligned detection isn’t aspirational for us — it’s the operational standard our analysts work to daily, across environments spanning healthcare, finance, manufacturing, and professional services. If you’re an MSP building or scaling a SOC practice, looking for a white-label partner who can cover detection and response under your brand, or simply want a frank conversation about where your ATT&CK coverage actually stands — we’re a useful conversation to have. |