MITRE ATT&CK Explained: A SOC Analyst's Field Guide

If you have spent any time around a SOC, you have seen technique IDs get dropped into conversation like shorthand nobody bothers to explain. Someone says "that's a T1110" and everyone nods. If you are new, that nod is doing a lot of work you have not earned yet, and this guide is meant to close that gap.

What MITRE ATT&CK Actually Is

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is a free, publicly maintained knowledge base of how real attackers operate. MITRE built it by studying actual intrusions and distilling the patterns into a structured catalog, and they keep updating it as new techniques get documented in the wild. It is not a theoretical model somebody drew on a whiteboard. Every technique in it maps back to observed behavior, usually with citations to the incident reports or research that surfaced it.

The framework covers several domains, but the one you will use almost daily as a SOC analyst is Enterprise ATT&CK, which models attacks against traditional IT environments: workstations, servers, cloud infrastructure, identity systems, and the networks connecting them. There are also PRE-ATT&CK (reconnaissance and resource development, now folded into Enterprise), Mobile, and ICS matrices for their respective domains.

Picture the matrix as a table. Across the top you have tactics, the attacker's objective at a given stage of the intrusion. Down each column you have the techniques an attacker could use to achieve that specific objective. As of ATT&CK v19.1, the Enterprise matrix has 14 tactics, running roughly in this order:

Tactic ID	Tactic	Attacker's goal
TA0043	Reconnaissance	Gather information about the target
TA0042	Resource Development	Build infrastructure and capabilities
TA0001	Initial Access	Get a foothold in the environment
TA0002	Execution	Run malicious code
TA0003	Persistence	Maintain access across reboots and credential changes
TA0004	Privilege Escalation	Gain higher-level permissions
TA0005	Defense Evasion	Avoid detection
TA0006	Credential Access	Steal account names and passwords
TA0007	Discovery	Learn about the environment
TA0008	Lateral Movement	Move through the environment
TA0009	Collection	Gather data of interest
TA0011	Command and Control	Communicate with compromised systems
TA0010	Exfiltration	Steal data
TA0040	Impact	Manipulate, interrupt, or destroy systems and data

That order reads like a story, and mostly it is one, but real intrusions do not march through it in a straight line. An attacker might hit Discovery, Credential Access, Discovery again, then Lateral Movement, then back to Credential Access on a new host. ATT&CK is built to model that non-linear reality, which is the single biggest thing that separates it from the older kill-chain thinking, more on that below.

Tactics, Techniques, and Sub-Techniques: The Hierarchy That Matters

This is the part beginners get sideways, so it is worth being precise about it.

A tactic is the why. TA0006, Credential Access, is a category. It answers "what was the attacker trying to accomplish at this point?" You cannot detect a tactic directly; it is not an event that fires, it is a classification you apply after you understand what happened.

A technique is the how. Under TA0006 sits T1110, Brute Force. That is a specific, describable method: repeatedly guessing credentials until one works. Techniques are what actually get detected. Your SIEM rule does not fire on "Credential Access," it fires on a pattern of failed authentication attempts that matches T1110's signature.

A sub-technique is precision underneath the technique. T1110 has four sub-techniques, and knowing which one you are looking at changes your response:

• T1110.001, Password Guessing: one account, many passwords tried in sequence.
• T1110.002, Password Cracking: a captured password hash taken offline and cracked, so it never touches your auth logs.
• T1110.003, Password Spraying: many accounts, one or two common passwords tried against each, spread out to avoid lockout thresholds.
• T1110.004, Credential Stuffing: previously breached username/password pairs replayed against a new target.

All four produce failed-logon telemetry (except .002, which produces none at all, since the cracking happens offline against a stolen hash), but the pattern is different in each case, and that pattern is exactly what you are looking for when you triage the alert. A password-spray shows up as one source hitting dozens of accounts with the same password; classic brute force shows up as one account absorbing hundreds of attempts. Same tactic, same parent technique, different investigation, and in .002's case, a completely different evidence trail: you are not looking at Authentication Logs at all, you are looking backward for how the hash was captured in the first place.

Here is another pairing worth internalizing early: T1078, Valid Accounts, sits under Initial Access, Persistence, Privilege Escalation, and Defense Evasion, because using a stolen but legitimate credential can serve any of those goals depending on when it happens. That multi-tactic mapping trips up a lot of newcomers who assume every technique lives under exactly one tactic. It doesn't. ATT&CK models the real overlap.

Why sub-techniques exist, and why skipping them costs you

A parent technique like T1110 or T1053 (Scheduled Task/Job) can hide wildly different attacker tradecraft under one ID. Two analysts can both write "T1110" in their notes and mean genuinely different attacks: a noisy password guess against a single VIP account, or a slow, distributed spray across the whole directory designed to stay under a lockout threshold. If detection engineering only ever writes rules at the parent-technique level, one rule ends up trying to catch four distinct behavioral patterns, which usually means it catches the loudest one and misses the quiet ones. Mapping to the sub-technique is what tells you which log fields and which threshold logic you actually need.

Data Sources: What Telemetry Actually Catches a Technique

Every technique page in ATT&CK lists its data sources, the categories of telemetry that could plausibly detect it, alongside a detection section describing the general approach. This is the part beginners skip past fastest, and it's arguably the most operationally useful part for a tier-1 analyst, because it answers a concrete question: if this technique fired in my environment, what log would it show up in?

A few worth knowing cold:

• T1110 (Brute Force) relies primarily on Authentication Logs: successful and failed logon events, source IP, account name, timestamp. Without centralized authentication logging, this technique is functionally invisible no matter how good your correlation rules are.
• T1059 (Command and Scripting Interpreter) relies on Process Creation events (a new process spawns, command line captured) and script-execution logs like PowerShell's script block logging. Without full command-line capture, you can see powershell.exe ran without ever seeing what it was told to do, which is the part that matters.
• T1021 (Remote Services), the umbrella for lateral movement over RDP, SSH, SMB, relies on Network Traffic (flow data, protocol, source/destination) and Authentication Logs, since a remote-services login still authenticates against something.
• T1486 (Data Encrypted for Impact), the ransomware-encryption technique, relies on File telemetry: creation, modification, and deletion events at volume, often alongside Process Creation for the encryption binary itself.

The reason this matters day to day is that "detection coverage" is not really about whether someone wrote a rule, it's about whether the underlying data source is even being collected. A team can have a beautifully written correlation rule for T1021 lateral movement that will never fire because nobody onboarded the Windows Security event log carrying the logon-type-10 (RDP) events it depends on. Reading a technique's data-sources list before assuming you have coverage is a habit worth building early, and it's the first question a detection engineer asks when a coverage-gap analysis flags a technique as "at risk."

A Worked Example: From Raw Alerts to an Attack Story

Framework explanations only click once you have watched a real alert stream turn into a technique-mapped narrative. Here is a compressed version of what that looks like on a live shift, condensed from the kind of alert sequence a SIEM or XDR console would actually throw at you.

07:14 UTC. A service account, svc-backup, authenticates successfully to a VPN concentrator from an ASN it has never logged in from before. No MFA prompt, since service accounts are often exempted. On its own, this is one login event with an unusual geo-tag.

Mapped: T1078, Valid Accounts (TA0001, Initial Access, since this is the entry point here). What it tells you: someone has working credentials for a low-visibility account that was probably never meant to be interactively usable. The move is not to close this as "service account noise," it's to ask what that account should never be able to do, and start watching for it.

07:16 UTC. Two minutes later, an LDAP query fires from the same host, enumerating every member of the Domain Admins group.

Mapped: T1087.002, Account Discovery: Domain Account (TA0007, Discovery). What it tells you: the attacker is no longer just "in," they're actively mapping who holds the keys. This is where the alert stops being triage-and-close and becomes an active investigation. Recognizing the Discovery pattern here means escalating now, not after the next alert.

07:24 UTC. An RDP session opens from the same host to a file server svc-backup has no documented business reason to touch.

Mapped: T1021.001, Remote Services: Remote Desktop Protocol (TA0008, Lateral Movement). What it tells you: the attacker moved off the initial foothold onto a second machine using the same valid credential. Containment stops being optional here. If Discovery told you what they were looking for, Lateral Movement tells you they found something worth moving toward.

07:31 UTC. On the file server, a scheduled task is created to run a PowerShell command on next reboot, referencing a script staged in a world-writable temp directory.

Mapped: T1053.005, Scheduled Task/Job: Scheduled Task (TA0003, Persistence here, though the same technique can equally serve Execution or Privilege Escalation depending on the task's payload). What it tells you: the attacker is planting a way back in that survives a reboot or password reset. This should trigger isolating the host immediately rather than continuing to observe.

07:40 UTC. Mass file-modification events begin across the file server's shared volumes, files rewritten with a new extension at a rate no human produces.

Mapped: T1486, Data Encrypted for Impact (TA0040, Impact). What it tells you: the attack reached the stage it was built for. If containment happened at Lateral Movement or Persistence, this event never happens. If it's happening now, the incident has moved from "contain and investigate" to "declare and activate the IR plan."

Strung together, technique IDs turn five disconnected log lines into a sentence: a compromised service credential got in, enumerated privileged accounts, moved to a file server, planted persistence, and encrypted data. That sentence is what goes in the incident report, and it's also what should have triggered escalation well before the ransomware note appeared, which is the point of mapping early rather than waiting for the technique that's impossible to miss.

How a Tier-1 Analyst Actually Uses ATT&CK

None of this matters if it stays academic. Here's where it earns its keep on a live shift.

Mapping an alert to a technique

Say a SIEM alert fires: a service account authenticated successfully from a new geographic location, followed by an LDAP query enumerating every account in the domain. On its own, that's two events. Mapped to ATT&CK, it reads differently: the initial logon looks like T1078 (Valid Accounts) under Initial Access or Persistence, and the LDAP enumeration maps to T1087 (Account Discovery), a Discovery-tactic technique. Suddenly you're not looking at two disconnected log lines, you're looking at a plausible early-stage intrusion where an attacker got in on a valid credential and is now mapping the environment before moving laterally.

That mapping changes what you do next. If you recognize TA0007 (Discovery) activity, you know the natural next stage in a real attack is often TA0008 (Lateral Movement) or TA0006 (Credential Access) as the attacker tries to expand their foothold. You go looking for that, instead of waiting for the next alert to tell you.

Reading the raw signal

A command like net user /domain or a PowerShell one-liner querying Get-ADUser -Filter * is a textbook example of T1059, Command and Scripting Interpreter, being used in service of a Discovery-tactic goal. Recognizing the technique in the command line itself, not just in a vendor's pre-built alert, is what separates an analyst who can read raw telemetry from one who only reacts to a dashboard. The technique library is worth bookmarking specifically for this: real command syntax, real log formats, and the detection logic that would actually catch each one.

Finding coverage gaps

At the team level, ATT&CK becomes a coverage map. Someone (often a detection engineer, sometimes a senior analyst) builds a heatmap of every technique the team has ever seen, cross-referenced against which ones have an actual detection rule behind them, and which ones have the underlying data source collected at all. A gap can exist for two different reasons that get confused constantly: no rule was ever written for a technique the team has telemetry for, or the telemetry was never onboarded, so no rule could ever fire regardless of how well it's written. A technique with rich data sources and zero detections is a quick engineering fix; a technique whose primary data source (PowerShell script block logging for T1059, say) was never turned on is a bigger infrastructure conversation, and it usually surfaces first when an analyst notices an incident they investigated manually left no trace they could have alerted on.

This is what people mean by "threat-informed detection": instead of writing rules for whatever seems interesting, you write them for the techniques adversaries in your industry actually use, prioritized by the size of the gap. MITRE's own Groups pages, which catalog which named threat actors favor which techniques, are a reasonable starting point if your team doesn't have its own threat-intel feed doing it already. Threat hunting as a discipline builds on this same coverage-gap logic, just proactively, searching for technique evidence in environments where no alert has fired yet rather than waiting for one to.

Building a shared vocabulary

The quieter benefit is communication. When an incident report says "the attacker used T1566.001 for initial access," every analyst who reads it, on this team or a different one entirely, knows exactly what that means without a paragraph of explanation. That precision is worth more than it sounds like, especially once you're writing your own IOC-heavy reports and need someone six months from now to understand exactly what you saw.

Common Mistakes Beginners Make With ATT&CK

The framework is easy to misuse in ways that feel productive but aren't. Watch for these specifically.

Treating it as a checklist instead of a lens. The goal is not to attach a technique ID to every alert so the ticket "has a mapping." A mapping that doesn't change your investigation or your next action is decoration. If tagging an alert T1110 doesn't lead you to check for other accounts hit by the same source, the tag did nothing for you.

Over-mapping a single ambiguous event. A newcomer will sometimes see one log line and assign it four or five plausible technique IDs "just in case." This dilutes the analysis rather than sharpening it. Pick the mapping the evidence actually supports, and if it genuinely supports more than one interpretation, say so explicitly rather than listing every technique that's theoretically consistent.

Confusing a tactic with a technique. Saying "this looks like Credential Access" is a reasonable first read. Writing "TA0006" into an incident report as if it were the finding is not, because a tactic isn't a detectable thing, it's a category you arrive at after identifying the technique. The finding is T1110.003; TA0006 is the shelf it sits on.

Stopping at the parent technique when a sub-technique is knowable. T1110 alone tells a reader far less than T1110.003 does. If your evidence is specific enough to tell a spray from a guess, write the sub-technique. Vague mapping produces vague detections.

Mapping at the wrong level of abstraction. This cuts both ways. Mapping "phishing email" broadly to T1566 without noting whether it was a malicious attachment (T1566.001) or link (T1566.002) is too coarse, since the follow-on detection logic differs for each. Forcing a technique ID onto something that's really just infrastructure detail, like the mail client used, is too fine; ATT&CK models attacker behavior, not every incidental log fact. The skill only comes from mapping real evidence repeatedly and getting corrected when you're wrong.

ATT&CK vs. the Cyber Kill Chain

You will hear both terms used almost interchangeably by people who haven't looked closely at either, so it's worth being clear on the difference.

The Lockheed Martin Cyber Kill Chain, published in 2011, models an attack as seven linear stages: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, and Actions on Objectives. It's a straight line, and the assumption baked into it is that an attacker moves through those stages roughly in order, and that breaking the chain at any point stops the attack. It's simple, it's old enough that most security leaders already know it, and it's genuinely useful for explaining "how attacks generally progress" to a non-technical audience in one slide.

MITRE ATT&CK is a matrix, not a line, and that's the structural difference that matters. It has 14 tactics instead of seven stages, hundreds of techniques and sub-techniques instead of a handful of named phases, and it explicitly does not assume attackers move through tactics in a fixed sequence. An attacker can bounce from Discovery to Credential Access and back to Discovery three times before ever reaching Lateral Movement, as the worked example above shows in miniature. ATT&CK also gets updated on a public release cadence as new techniques surface in the wild, where the Kill Chain has stayed the same seven boxes since 2011.

In practice, most working SOCs use ATT&CK for actual day-to-day detection engineering and incident mapping, because it has the resolution to be useful at the alert level. The Kill Chain still shows up in executive briefings and vendor marketing because it's easier to put on one slide. Knowing both, and knowing which one your team defaults to, is a fair thing to ask about in an interview.

ATT&CK vs. D3FEND

Less commonly discussed but worth knowing: MITRE also maintains D3FEND, a companion knowledge base focused on the defensive side. Where ATT&CK catalogs what attackers do, D3FEND catalogs the countermeasures, mapped against the specific techniques they mitigate, credential hardening, network isolation, file analysis, and so on. As a tier-1 analyst you won't touch it much day to day, that's more detection-engineering territory, but it's useful to know it exists: when someone asks "what's our mitigation for T1110," D3FEND is the framework with a structured answer instead of a vague one.

How to Start Learning ATT&CK Without Drowning In It

The matrix has hundreds of techniques and it is genuinely not realistic to memorize all of it, and trying to is a bad use of your first few months. A better path:

1. Start with the techniques you already see. Pull the last month of alerts your team handled and map five or six of the most common ones to their IDs, probably things like T1566 (Phishing), T1078 (Valid Accounts), T1059 (Command and Scripting Interpreter), T1110 (Brute Force), and T1046 (Network Service Discovery). Learn those cold before going wider.
2. Read real incident reports and map them yourself first. Pick a few public writeups from vendor threat-intel blogs or CISA advisories, and try assigning technique IDs to each stage before checking the author's own mapping. Getting it wrong and seeing why is where the learning happens.
3. Learn to recognize evidence, not just labels. A technique ID is a category; what you actually need to recognize is the raw signal, an unusual process spawning a script interpreter, a spike in failed logons across many accounts. The label comes after you've seen the pattern.
4. Learn each technique's data sources alongside the technique itself. Knowing that T1110 lives in Authentication Logs, or that T1059 lives in Process Creation and script-execution logs, is what turns "I can name the technique" into "I know where to look for it." That pairing is what a real detection engineer carries around in their head.
5. Practice on realistic, noisy data. Clean write-ups make everything look obvious in hindsight. Real SIEM and XDR consoles bury the interesting signal in thousands of routine events, and pivoting from a raw alert to a technique ID under that noise is a different skill. This is the gap SOCSimulator is built for: technique detection practiced on realistic SIEM, XDR, and firewall consoles, free to start.
6. Keep the matrix as a reference, not a study list. Bookmark the technique library and the glossary and return to them when a specific alert calls for it.

Where This Fits Into Your Broader Toolkit

ATT&CK is a vocabulary and a coverage map, not a replacement for the judgment you build by triaging real alerts, and it works best alongside the fundamentals of a solid SIEM workflow: correlating technique-level signal across log sources, watching for the tactic-to-tactic progression the worked example walked through, and cross-checking your instincts against documented playbooks for how a given technique is normally investigated. Understanding persistence mechanisms like T1053 alongside the tactics that typically precede them is exactly the kind of pattern recognition that only comes from repetition. None of it substitutes for reps.

If you're building toward a SOC role and want to practice mapping alerts to techniques on consoles that behave like the real thing, SOCSimulator gives you SIEM, XDR, and firewall environments with realistic noise baked in, free to start. Technique recognition under pressure is the skill interviewers actually probe for, and it's a skill you build by doing it, not by reading about it.