Mapping Detection Rules to MITRE ATT&CK

Recently, I posted 🔗 on how a structured engineering approach to creating detection rules can benefit a Threat Detection Engineering (TDE) program. In that post, I showed how early engineering can bring benefits, including classifying new detection rules using MITRE ATT&CK terms.

While seemingly simple, this action involves a certain level of complexity due to the numerous techniques and inherent subjectivity involved. In this post, I will bridge that gap by outlining a process to perform this task.

Mapping to MITRE ATT&CK

The most important tip here is the well-known phrase: context is king. As shown by MITRE itself, a single technique alone is sometimes insufficient to infer maliciousness. Similarly, a command, a tool, an operating system, or a user alone, without context, may not be enough to classify an action as malicious. A Windows system in a network is not intrinsically malicious, but a Windows system running Mimikatz and connecting to an external machine might indicate credential dumping and data exfiltration.

This highlights why we must rely on the rule context, which exemplifies its crucial nature. The context must include baseline directives, best practices, and how the environment is expected to behave. It must also detail the protections in place against the scoped malicious behavior. Ultimately, it's important that the context answers the question: "What and why am I detecting?" by describing the behavior, technical indicators, and, when possible, the adversary's objective.

Refer to the appendix for a practical example.

Understand the Context/Behavior: "What" and "How"

1. Read and Deconstruct the Context: What specific activity is being described in the detection rule context or threat modeling item? What logs or data sources are involved? What conditions trigger the alert? Focus on the actions and technical details. Avoid generic statements. For example, for a detection rule, think: How did the malware get there? What did it do when it ran?

2. Identify Key Actions and Indicators: Look for action verbs (e.g., "creates," "modifies," "executes," "connects"), associated nouns (e.g., "scheduled task," "registry key," "process," "network connection"), specific tools (e.g., PowerShell, PsExec, reg.exe), and involved system components (e.g., Windows services, WMI). Highlight or extract these keywords for future reference and enrich it for better applicability. For example, if the keywords include aws and root, they could be enriched with cloud, credential, and administrator.

Translate to ATT&CK: "Why" and Specific "How"

3. Brainstorm Potential Tactics (The "Why"): With the context in mind, it's time to reflect on it. Answering the question "why is the adversary doing this?" will lead to one or more of the tactics defined in the MITRE ATT&CK framework. If it's not immediately clear, rephrasing the question to similar or more specific ones might help. For example: "What's the adversary's immediate goal by performing this action?" The answer might fall into one or more tactics—this is common and acceptable. Starting with tactics mapping is strategic because currently there are only 14 of them. Conversely, there are hundreds of techniques, so this approach is like divide and conquer.

4. Identify Specific Techniques and Sub-Techniques (The Detailed "How"): Next, it's important to understand how the adversary will achieve their goal. Here, the techniques within each mapped tactic must be analyzed to determine if they fit the action. The context proves to be paramount because it must be cross-referenced against the description of each technique to understand if there's a reason to link them. The list of keywords will greatly aid in this sense. It's important, however, to be as specific as possible and try to map at the level of sub-techniques, when available and in scope. Even in cases where the context relates to all sub-techniques within a technique, it's worthwhile to map all applicable sub-techniques.

5. Refine and Review the Mapping: Does the technique's description truly match the behavior? Do the "Procedure Examples" and "Data Sources" listed for the technique on MITRE's page align with the context and the data expected? If so, it's time to ask for a peer review. Share the context and mapped tactics with a teammate and check if they found similar answers. If any mapping differs, evaluate if it makes sense and potentially make necessary adjustments. In this regard, using a Large Language Model (LLM) to assist in the review has proven to bring great results—just be aware that a good prompt will reduce the probability of hallucinations, and models might miss recent MITRE ATT&CK updates, leading them to map deprecated techniques or miss recently added ones.

Tools

Some tools are freely available to aid in using MITRE ATT&CK. The one I use the most is the ATT&CK Powered Suit, a Chrome extension that provides quick access to the matrix, allowing the user to query by each word present in many fields, like descriptions, titles, and IDs. This greatly helps, especially when a keyword list is available.

MITRE also offers a spreadsheet version of the entire matrix through the ATT&CK Data and Tools page. This is useful for quick access. Besides that, as previously mentioned, a decent LLM with a good prompt 🤖 is hands down the best companion.

Bottom Line

While MITRE ATT&CK is a flexible and well-documented framework, it can be misused if applied without context, threat relevance, or operational maturity. The most common failure, however, is simply not using it at all. Following the strategy of mapping tactics then techniques will greatly help in the process, and leveraging tools can make it easier. However, taking the time to read and understand what the chosen tactic or technique aims to represent is crucial—and this is the only way to truly grasp the gains of this framework.

It's always important to highlight that MITRE ATT&CK is not complete by itself. Using it to map scenarios is great, but it's incomplete by design. Not because it's a flawed product, but because it's infeasible to map all possible procedures under every technique. Bearing this in mind when analyzing a MITRE ATT&CK mapping underscores the importance of having comprehensive context for each TTP in the map. 🏅

If it looks challenging in the beginning, that's because it is, but it's totally worth the effort. A final tip for beginners: start small and iterate continually until the process matures. Although not perfect, this is certainly a good path towards a truly threat-informed defense, and good mapping will be prolific in different ways. From allowing engineers to find similar rules in public repositories, to building more precise coverage maps. 🚀

Appendix: Use Case and Context Example

Here is a use case and the context derived from it in a fictional scenario.

Use Case

Problem Statement & Context

We are concerned about adversaries leveraging scheduled tasks to achieve persistence within our environment by executing malicious PowerShell scripts. In particular, the creation of scheduled tasks that invoke scripts from temporary directories (e.g., C:\Windows\Temp) is highly suspicious, as these locations are not used by legitimate IT operations for storing or running scheduled tasks. Standard user accounts do not typically create scheduled tasks, and authorized tasks are generally deployed via centralized tools like GPO or SCCM, running from trusted paths. Given our current baseline—which includes enforced PowerShell execution policies, active EDR monitoring, and antivirus scanning of temporary directories—such behavior falls well outside of normal activity. This anomaly may indicate an attacker attempting to establish persistence, aiming to ensure the execution of malicious scripts at startup or on a recurring basis.

Expected Outcome

We need to detect and alert on the creation of scheduled tasks by non-administrative users that execute PowerShell scripts from temporary or otherwise untrusted directories. This detection helps us identify early signs of persistence mechanisms deployed by threat actors, allowing for rapid investigation and containment before further compromise.

Context

The environment is secured with strict baseline controls where standard users are not permitted to create scheduled tasks, and PowerShell execution is governed by Group Policy with comprehensive logging enabled. Temporary directories are not intended to host executable or persistent scripts, and application whitelisting is enforced on critical systems. Expected behavior dictates that legitimate scheduled tasks originate from centralized tools like GPO or SCCM and run from trusted directories, making user-created tasks highly anomalous. Protections include active EDR monitoring for process and task creation, antivirus scanning of temporary paths, and enforced PowerShell execution policies. Regular reviews of scheduled tasks and system configurations support the early detection of misuse. The detection rule focuses on identifying suspicious scheduled tasks created by non-admin users that run PowerShell scripts from temporary locations—activity strongly associated with persistence techniques used by adversaries to maintain access and execute code stealthily.

Directly Used Keywords

• Action verbs: create, execute, monitor, enforce
• Nouns: scheduled task, script, directory, process, user, system, access
• Tools: powershell, gpo, edr, antivirus
• Components: temp, startup

Derived Keywords

• Threat Concepts: persistence, escalation, stealth