MITRE ATT&CK for Defenders: How to Use the Matrix

MITRE ATT&CK is the shared vocabulary of security teams. Every vendor report, detection rule and red team debrief uses it, yet many new analysts only know it as a colourful grid on a conference slide. This guide shows how to use MITRE ATT&CK as a defender: how to read the matrix, how to turn a technique into a detection, and how to find the gaps in your own coverage.

This is Part 6 of 30 in the Blue Team Learning Path. In Part 1 we looked at how a SOC works. Here we give that SOC a map of attacker behaviour to work from.

Key takeaways

• ATT&CK describes what attackers do (tactics and techniques), not which tool they use.
• Start from the techniques you can actually log, then work outward.
• Map every detection rule to a technique ID so gaps become visible.
• Coverage is not the same as quality: one noisy rule does not “cover” a technique.

What MITRE ATT&CK is (and what it is not)

ATT&CK is a knowledge base of adversary behaviour built from public incident reports and research, maintained by MITRE. You can browse it for free on the official ATT&CK site. It is organised as matrices for different environments, and the Enterprise matrix, which covers Windows, Linux, macOS, cloud and more, is the one most blue teams start with.

It is not a checklist, a maturity score or a product. Nobody is meant to “reach 100% coverage”. It is a common language: when an analyst writes “T1059.001” in a ticket, a threat intel vendor and a pentester know exactly what that means. That alone removes a lot of confusion during an incident.

Tactics, techniques, sub-techniques and procedures

The matrix has four levels, and mixing them up is the most common beginner mistake.

• Tactics are the attacker’s goals, the columns of the matrix. Examples are Initial Access, Execution, Persistence, Credential Access and Lateral Movement.
• Techniques are how a goal is achieved. Brute Force (T1110) is a technique under Credential Access.
• Sub-techniques are more specific variants. Password Spraying is T1110.003 and Password Guessing is T1110.001.
• Procedures are the concrete way a named group or tool implements a technique. This is where real command lines live.

The tactic order follows a rough attack lifecycle, but attackers do not walk the columns left to right. They loop, skip and repeat. Treat the columns as categories, not a timeline.

How to read a technique page

Open any technique page, for example Brute Force (T1110), and read it in this order:

1. Description: what the behaviour is and why attackers use it.
2. Procedure examples: which groups and tools have used it, with references.
3. Mitigations: controls that reduce the risk, such as multi-factor authentication or account lockout.
4. Detection: what to monitor. ATT&CK has been reworking this section, so treat it as a starting point and check the current wording on the page.

The detection guidance names data sources such as authentication logs or process creation. That tells you which telemetry you need before any rule can work.

From technique to detection: a worked example

Take Password Spraying (T1110.003). The behaviour is one source trying a few common passwords against many accounts. The question is: what would that look like in my logs?

1. Pick the telemetry. On Windows domain controllers, failed logons are event 4625 on member systems and Kerberos or NTLM failures on the domain controller. Our Windows event logs primer covers these fields.
2. Describe the pattern. Many distinct usernames, few attempts each, same source address, short window.
3. Write the logic. Count distinct target accounts per source over, say, 30 minutes and alert above a threshold you tune to your environment.
4. Test it. Generate the behaviour in a lab (Part 10 builds one) and confirm the alert fires.
5. Tag it. Store T1110.003 in the rule metadata.

Here is the shape of a PowerShell check you can run on one host to see failed logons grouped by source. Event 4625 is documented by Microsoft, and the Security log needs an elevated session.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-1)} |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object Name -eq 'IpAddress' | Select-Object -ExpandProperty '#text' } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 10

This only counts attempts per source. A real spraying rule also counts distinct usernames, which is what separates spraying from one forgotten password.

A quick tour of the Enterprise tactics

The Enterprise matrix lists fourteen tactics at the time of writing. Check the site for the current list, because MITRE updates it a few times a year. Here is what each one means in plain language, and the telemetry a defender usually needs.

• Reconnaissance and Resource Development: preparation that mostly happens outside your network. You see it through threat intelligence, not logs.
• Initial Access: phishing, exposed services, stolen credentials. Email gateway, VPN and web logs help here.
• Execution: running code, for example through PowerShell (T1059.001). Process creation and script logging matter most.
• Persistence: surviving a reboot, for example with a new service (T1543.003) or scheduled task (T1053.005). Watch service and task creation events.
• Privilege Escalation and Defense Evasion: getting higher rights and hiding. Log tampering and security tool changes are strong signals.
• Credential Access: brute force, credential dumping, ticket abuse. Authentication logs are the core source.
• Discovery and Lateral Movement: exploring the network and moving between hosts, for example over SSH (T1021.004). Logon events and network flow data help.
• Collection, Command and Control, Exfiltration: gathering data and talking to the attacker. DNS, proxy and firewall logs are your friends.
• Impact: encryption, deletion, disruption. By this point you are already in incident response.

Notice how each tactic points to a log source. That link between a behaviour and the telemetry that reveals it is the real value of the framework.

Example: mapping an alert to ATT&CK

Imagine a SIEM alert: a new Windows service was installed on a file server at 02:14, and its binary path points to a user’s temp folder. How does an analyst use ATT&CK here?

1. Name the behaviour. A service created to run a program is Create or Modify System Process: Windows Service (T1543.003), a Persistence technique. Event 4697 records service installation, see the Microsoft reference.
2. Ask what came before. Persistence follows Initial Access and Execution. Who logged on? What process created the service? That sends you to logon events and process creation.
3. Ask what comes next. Attackers who persist usually move on to Credential Access or Lateral Movement. Check the host and its neighbours for those behaviours.
4. Record it. Write T1543.003 in the ticket, with the evidence, so the next analyst can search for the same technique across incidents.

That is the whole method: behaviour, context, next likely steps, record. You do not need to be an expert on the technique to do it, because the technique page tells you the rest.

Using ATT&CK Navigator to find coverage gaps

ATT&CK Navigator is a free web tool that lets you colour techniques on the matrix and save the result as a layer file. A practical workflow:

1. Export your detection rules with their technique tags.
2. Colour each technique that has at least one tested rule.
3. Make a second layer from a threat actor relevant to your industry, using the group pages on the ATT&CK site.
4. Overlay the two. Techniques the actor uses that you do not detect are your priority list.

This turns “we need better detection” into a ranked to-do list that you can show your manager.

Other ways defenders use ATT&CK

• Incident reporting: tag each observed behaviour so reports from different analysts line up. The NIST incident handling guide describes the process around it.
• Threat hunting: pick a technique, form a hypothesis and search for it. Part 21 covers this in detail.
• Purple teaming: the red team runs a technique, the blue team checks whether it was seen. Part 29 uses Atomic Red Team for exactly this.
• Hardening: use the mitigations listed on each technique to prioritise controls.

If you want to see how an attack path reads in ATT&CK terms, our Active Directory attacks guide and the Kerberos deep dive are easy to map technique by technique.

Common pitfalls

• Chasing a coverage percentage. A green square from one untested rule is false comfort.
• Ignoring data sources. You cannot detect process creation if you do not log it. Fix telemetry first.
• Treating the matrix as a timeline. Attackers jump around the tactics.
• Memorising IDs. Learn the behaviours. Look up the numbers.
• Using stale IDs. MITRE occasionally restructures techniques. For example, Clear Windows Event Logs, which used to be T1070.001, now appears as T1685.005. Always confirm an ID on the live site before citing it.

A simple weekly routine

You do not need a big programme to start. Pick one technique a week, read its page, find the logs that would show it, write or tune one rule, test it, and tag it. After three months you will have a dozen tested detections and a layer that shows exactly where you are blind. If you are earlier in your journey, our learning path from zero to job-ready shows where this fits.

Frequently asked questions