ATT&CK Sub-Techniques Preview

ATT&CK has been in constant development for about six years now. Over that time, ATT&CK has grown quite a bit while still sticking to our original design decisions. This has all resulted in techniques at different levels of granularity: some are very broad and cover a lot of activity, while others cover a narrow set of activity.

We want to fix this, and we need your input as we do that. We think we can do better to address some of these issues while also giving the community a more robust framework to build onto over time. We’ve heard from you that techniques being at different granularity is an issue for you, too, including mentions at ATT&CKcon and many discussions we’ve had with various teams — some have even started to develop their own concepts for sub-techniques.

This will be a big change in how people view and use ATT&CK. We’re well aware re-structuring ATT&CK to solve these issues could cause some re-design of processes and tooling around the changes. Even though we think these changes are necessary for the long-term growth of ATT&CK (many others have said so too), we are sensitive to the impact it will have, and we want feedback from the community as to how it will affect you.

Here’s our ask: take a look at what we’re thinking below, then reach out to us to let us know what you think at attack@mitre.org . Use a subject line that starts with “Sub-technique feedback” so it’s easy to spot.

What are Sub-Techniques?

Sub-techniques are a way to describe a specific implementation of a technique in more detail. Oftentimes in technique entries we describe various ways techniques can be performed. A good example is with Credential Dumping.

ATT&CK Credential Dumping technique

Within the technical description of Credential Dumping there are several sections describing various ways the action can be performed (nine total), like Windows SAM and Cached Credentials. That’s quite a lot of different behaviors lumped into one technique even though the end result is similar each time. With sub-techniques, we would split this up and have a top-level Credential Dumping technique with nine sub-techniques underneath to cover those variations in more detail for how they apply in specific ways to individual platforms.

Techniques and sub-techniques will be pretty much identical as far as what fields exist and information is contained within them (description, detection, mitigation, data sources, etc.) — the difference will just be the in their relationships, with each sub-technique being under a technique.

Persistence and Privilege Escalation Sub-Technique Examples

We’ve done a lot of work over the past year and a half to determine when techniques should be broken out into sub-techniques, combined, or added. There were also quite a few “back to the drawing board” moments since we’re trying to maintain the same look and feel of ATT&CK. It hasn’t been a perfect science, so we felt the best way to get our point across is to show the details. As a concrete example, here’s the new set of proposed Persistence and Privilege Escalation techniques with sub-techniques listed. The specifics are subject to change, but we wanted to be transparent about what we’re thinking so far. You can take a look at the images below (new techniques and sub-techniques in bold) or click here for a detailed spreadsheet:

ATT&CK Persistence Tactic with techniques and sub-techniques

ATT&CK Privilege Escalation Tactic with techniques and sub-techniques

There are a few key types of changes we’re proposing from the ATT&CK you’re used to:

• New ID numbering — With the addition of sub-techniques tied to individual top level techniques, we can expand the technique IDs to identify sub-techniques: T[technique].[sub-technique]. Sub-techniques will start at .001 and increment with each new sub-technique under a technique. For example, Access Token Manipulation will still be T1134, but “Token Manipulation/Theft” will be T1134.001, “Create Process with Token” T1134.002, etc.
• New techniques — We added a few new techniques to help us better organize sub-techniques. For example, we added the new technique “Pre-OS Boot” to Persistence because it was a broader way to describe the purpose of using Bootkit, Component Firmware, and System Firmware (which are now sub-techniques).
• Technique decomposition — Some techniques like Account Manipulation and Process Injection had several sub-techniques created from content in their previous definition. In other cases the techniques will get decomposed and sub-techniques will be assigned under other applicable techniques. For example, Local Job Scheduling was decomposed into sub-techniques that fall under “Scheduled Task/Job” and “Scheduled Task/Job (Escalation Possible)”.
• Technique realignment and deprecation — The analysis of techniques necessary to do sub-techniques led to some technique realignment between tactics and deprecation of techniques. We pruned back several techniques that didn’t fit the core definition of the tactic, like Hidden Files and Directories not fitting under Persistence, and a small number that needed to be deprecated, like Hypervisor where we’ve found no documented use cases beyond proof of concepts. (We’ll cover this in more depth in the future.)
• Technique-to-sub-technique demotion — We moved many techniques into sub-techniques. For example, since we added the technique “Pre-OS Boot,” we moved the existing Bootkit technique underneath it as a sub-technique.

Reading into the details, there’s some additional things to note.

• Some techniques are so unlike anything else in the Tactic that we don’t see a good way of grouping them at this point (e.g., BITS Jobs, Port Knocking, SID-History Injection) and remain as techniques with no added sub-techniques. (Whew, some things AREN’T changing!)
• You’ll observe that this change would reduce the number of techniques in each tactic. As of this example, Persistence has been reduced from 59 techniques into 19 and Privilege Escalation has been reduced from 28 to 13.
• Intuitive scoping of techniques and sub-techniques has been quite a bit more difficult than anticipated. You’ll see some aspects of this in how we’ve defined two techniques for one type of behavior based on whether or not that technique’s sub-techniques can be used to escalate privileges. An example is with “Event Triggered Execution” and “Event Triggered Execution (Escalation Possible)”. This helps to preserve a one-to-one mapping from sub-techniques to techniques if a technique can be used to accomplish more than one tactic. Both techniques would then fall under Persistence, but only “Event Triggered Execution (Escalation Possible)” would be under Privilege Escalation.

Crosswalks can help to understand our decisions and how things map between old and new techniques. If you want to dive into the details of how “old ATT&CK” maps to “new ATT&CK,” for Persistence and Privilege Escalation you can see that spreadsheet here — be warned that it is not final and it’s detailed, but we realize some of you want that level of detail so we want to be transparent. Below is a preview of what this may look like.

Crosswalk example mapping old techniques to new sub-techniques

Benefits of ATT&CK with Sub-Techniques

We already mentioned the key reason we’re proposing this change: to address the issues with levels of granularity in techniques. In addition to that, there are several other benefits to this enhancement to ATT&CK’s structure. I’ve mentioned some already, but lists are useful. We hope adding sub-techniques will:

• Allow the top-level techniques to change less frequently since techniques will be consolidated into more enduring categories. (For example, we can consolidate narrow techniques such as Rundll32 and Regsvr32 under existing higher level techniques like Signed Binary Proxy Execution. If a new method of Signed Binary Proxy Execution is found, we can simply add a new sub-technique.)
• Help users with assessing coverage since they will better understand that there’s several ways a technique can be performed. We’ve had several conversations where people have expressed that it’s difficult to say you’re “covered” (or not) for a broad technique like Scripting, so we hope adding the additional detail of sub-techniques will help users create more accurate coverage maps using ATT&CK.
• Simplify the process of adding new domains like Cloud that have a clear overlap with Enterprise. We can now express domain-specific behaviors sub-techniques with new cloud-based platform tags. (For example, the Account Discovery technique may be used differently in cloud environments, so we can add a sub-technique under Account Discovery for how it might apply to Office 365 or other SaaS applications.)
• Lead to more refined data sources that apply to techniques and sub-techniques on specific platforms. (In the above Account Discovery example, the data you collect from a traditional IT environment to detect that will be different than the data you collect from a cloud environment, so we can better express that difference.)
• Provide a structure for others to add their own local sub-techniques under existing techniques to meet their specific requirements. (For example, the Deloitte Threat Library Team added their own sub-technique of DNS Tunneling to the Technique Custom Command and Control, which you can check out in MITRE ATT&CK The Play at Home Edition on slides 73–74).
• Make it easier to fit the ATT&CK Matrix with techniques on a single slide. (Look, we make a lot of PowerPoints, and we know you do too!)

What We Want from You

These changes are essentially a whole new generation of ATT&CK. They’re big and likely should have been made a long time ago. For many of you it likely won’t be a straightforward task to implement them. We have two main questions for the community to make sure we aren’t doing this in vain.

1. Are we going about this the right way to meet your expectations on what sub-techniques should be?
2. Do you agree these changes are necessary enough to put into the work to implement them?

Please reach out to us at attack@mitre.org to let us know what you think. We may not get back to you right away as we’ll likely be inundated with emails but rest assured that we will read and consider your feedback.

What’s Next

Above all, we will listen to your feedback. We know ATT&CK is widely used by the community, and we don’t take decisions to change ATT&CK’s structure lightly. We will spend time reviewing your feedback and considering how we should go about this.

Going forward, our plan is that sub-techniques won’t sit at attack.mitre.org right away. We intend to publish a companion site that includes the changes for sub-techniques alongside the main ATT&CK site to give everyone a chance to preview the full scope of the changes and work to process them before we make that version the “official” one. There will be a delay of at least 2–3 months, (maybe more depending on your feedback) before the old site is deprecated and added to the previous versions for historical reference.

To assist with the transition, we plan to provide a crosswalk from old technique IDs to new ones wherever this is possible. This will help in most of the cases where an existing technique becomes a new sub-technique. Sometimes the mapping won’t be as straightforward, like when a technique gets decomposed into sub-techniques (as we discussed above). In those cases, we can map to an appropriate higher-level technique since there will likely be some analysis required on your end to map it more specifically, but at least the mapping will still be valid. An example is with the current Path Interception technique that will get decomposed and the resulting sub-techniques will reside under the new “Hijack Execution Flow” technique. Mapping existing intel or detection analytics to the top-level technique initially may be the best action until a review can be performed to see what new sub-technique they fall under, “Path Interception by Unquoted Path” or “Path Interception by Environment Variable”.

How Will This Affect Me?

This change will affect you differently based on how you’re using ATT&CK right now.

For those mapping detections or tooling to ATT&CK, this change will likely result in you reviewing new techniques and changes to refine detections for anything new. As discussed earlier, we expect many sub-techniques will map directly to “old” techniques, so in those cases you should only have to update IDs. You will have some level of effort with mapping new techniques and sub-techniques as well as determining how to assign things like detection analytics to those sub-techniques that have been decomposed.

For those mapping intel with ATT&CK, we expect this change to be more challenging. We plan to keep the historical site and STIX objects available as a reference for older intel that is mapped to the prior, pre-sub-technique version of ATT&CK. The crosswalks may help with intel mapped with structured formats, but anything analyzed and mapped by hand will likely require a significant amount of work to redo with sub-techniques. If you are mapping intel to ATT&CK, you should plan that this change will be significant for your historic repositories and consider how you may want to approach that (e.g. only map new intel to the new ATT&CK version). We are experiencing this same challenge and expect that we will devote significant effort to re-mapping old intel reporting, meaning there will likely not be new Group/Software additions as we do this. For those mapping intel to ATT&CK, we are interested in hearing whether there are ways we could help you during this transition.

For those focused on ATT&CK visualizations, we intend to have support for sub-techniques in how ATT&CK is visualized on the site as well as in the ATT&CK Navigator. Below is one proof of concept of how to interact with sub-techniques. The number of sub-techniques are listed as a number on the technique name and you can expand the sub-techniques to show the names and heatmap coverage.

Example ATT&CK Matrix visualization with sub-techniques

For those not yet using ATT&CK but thinking about doing so, you may be wondering if you should hold off until this change. We would advise you not to wait and to start now. The core concepts of how ATT&CK can be used aren’t changing, just the structure of the techniques. There are ways you can get started with the concepts to see if they’ll work for you. Check out the Getting Started blog series starting with Katie Nickels’ post on Getting Started with ATT&CK: Threat Intelligence.

Please keep these points in mind as you’re thinking about how to integrate these changes and let us know if there’s anything else we’re not considering for how you’re using ATT&CK.

Wrapping up

Adding sub-techniques is a big change for ATT&CK. We’re sensitive to what this means for the community and want to mitigate any issues and concerns you have before we continue to implement these changes and roll them out later this year. Let us know at attack@mitre.org what you like, don’t like, or want to see with these changes. If there’s a specific pain point you have or you’ll hate us forever if we make these changes, let us know so we can try to work through the issues! Above all, our goal is to make sure ATT&CK remains a useful resource for you, the community that we want to help.

©2019 The MITRE Corporation. ALL RIGHTS RESERVED

Approved for public release. Distribution unlimited 19–00696–9