Computer security, cybersecurity or information technology security is the protection of computer systems and networks from information disclosure, theft of or damage to their hardware, software, or electronic data, as well as from the disruption or misdirection of the services they provide.
What is the Framework Core and how is it used? The Framework Core is a set of cyber security activities, desired outcomes, and applicable references that are common across critical infrastructure sectors. An example of Framework outcome language is, “physical devices and systems within the organization are inventoried.” The Core presents industry standards, guidelines, and …
What critical infrastructure does the Framework address? Critical infrastructure (for the purposes of this NIST Framework) is defined in Presidential Policy Directive (PPD) 21 as: “Systems and assets, whether physical or virtual, so vital to the United States that the incapacity or destruction of such systems and assets would have a debilitating impact on security, national economic …
What is the Framework, and what is it designed to accomplish? The NIST Framework is voluntary guidance, based on existing standards, guidelines, and practices for organizations to better manage and reduce cybersecurity risk. In addition to helping organizations manage and reduce risks, it was designed to foster risk and cybersecurity management communications amongst both internal and external …
By Jamie Williams (MITRE), Jen Burns (MITRE), Cat Self (MITRE), and Adam Pennington (MITRE)
As we promised in the ATT&CK 2021 Roadmap, today marks our April release (ATT&CK v9) and we’re thrilled to share the additions with you, and how to use them. So, what changed with this release?
This is in addition to our usual updates and additions to Techniques, Groups, and Software, which you can find more details about on our release notes. Notably this release includes 16 new Groups, 67 new pieces of Software, with updates to 36 Groups and 51 Software entries.
As much as we love tracking and nerding out over adversary behaviors, one of the most important goals of ATT&CK is to bridge offensive actions with potential defensive countermeasures. We strive to achieve this goal by tagging each (sub-)technique with defensive-focused fields/properties, such as what data to collect (data sources) and how to analyze that data in order to potentially identify specific behaviors (detections).
Many of you in the community have made great use of ATT&CK data sources ¹ ² ³, but we heard from you and recognized the opportunity for improvement. Our goal for the new data sources is to better connect the defensive data in ATT&CK with how operational defenders see and work these challenges.
The initial changes are a revamp of the data sources values, which were previously text strings without additional details or descriptions.
These high-level concepts were a helpful starting point, but along with issues regarding consistency, this level of detail didn’t effectively answer “Am I collecting the right data?”
Prior to ATT&CK’s v9 release, data sources only highlighted a specific sensor or logging system (e.g., Process Monitoring or PowerShell Logs). What we were trying to capture with this approach was the defender’s requirement to collect data about processes and executed (PowerShell) commands. However, while these clues often directed us to “where we should collect data”, they didn’t always provide details on “what data values are necessary to collect?”
Details on what to collect can be important for mapping from the framework to defensive operations. For example, Process Monitoring can take many forms depending on what technologies you are using and what data about a process is needed (ex: do you need command-line parameters, inter-process interactions, and/or API functions executed by the process?). The same applies to PowerShell logs, which can be collected from a variety of sources (event logs, trace providers, third-party tools).The specifics of what exact data were often only highlighted in the additional context provided by the detection section of the technique.
With this in mind, we redefined data sources to focus on answering “what type of data do we need?” Our new list of data sources describe the types of objects our detection data needs to observe. Examples that are very commonly used across techniques include process, file, command, and network traffic.
Building on this, we added data components to further define specific needed elements within each data source. Going back to the OS Credential Dumping: LSASS Memory (T1003.001) example, we can see how the additional context helps us identify exactly what relevant data we need. Illustrating this with the Sysmon tool, we can quickly map our exact needs for process data to corresponding operational telemetry.
We reviewed and remapped both data sources and data components for all of the Enterprise matrix, including the Cloud and our newest Containers platform (more details about those matrices in the New and Improved Cloud section). Featured below are an example of the new Data Source: Data Component values that replaced the previous text.
These values fulfill the same objective of directing us towards “where we should collect data,” as well as providing the added context of “what specific values are necessary to collect.” As defenders, we can operationalize these Data Source: Data Component pairings as part of our detection engineering process by:
1. Using data sources to identify relevant sensors/logs
(i.e., where and how do/can I collect data about processes?)
2. Using data components to identify relevant events/fields/values
(i.e., what data about processes is provided by each sensor/log and how can these values be used to identify adversary behaviors?)
We’ll add additional details behind each data source when we release data source objects in October, but for now the data sources on the ATT&CK site link to our GitHub repository, where you can read more about each one. As always, we invite feedback and contributions (and a special thanks to those who have already contributed).
For more background about the data sources work, check out our previously published two-part blog series ¹ ² and/or watch us discuss and demonstrate the potential power of these improvements!
The community was at the heart of macOS improvements featured in this release. We collaboratively updated several techniques, rescoped others, and added macOS specific malware. Our focus was primarily on Persistence and Execution, building in red team walkthroughs and code examples for a deeper look into the sub-techniques. Along with the rest of Enterprise, we also refactored macOS data sources to start building out visibility for defenders. We’ve only scratched the surface and are excited to continue enhancing and updating macOS and Linux content targeted at our October release.
As we highlighted in the 2021 roadmap, this release features the consolidation of the former AWS, Azure, and GCP platforms into a single IaaS (Infrastructure as a Service) platform. In addition to community feedback favoring consolidation, this update creates a more inclusive domain that represents all Cloud Service Providers.
We also refactored data sources for Cloud platforms, with a slightly different flavor than the host-based data sources. Specifically for IaaS, we wanted to align more with the events and APIs involved in detections instead of just focusing on the log sources (e.g., AWS CloudTrail logs, Azure Activity Logs). With that goal in mind, the new Cloud data sources include Instance, Cloud Storage, and others that align with terminology found in events within Cloud environments.
An ATT&CK for Cloud bonus in this release is the addition of the Google Workspace platform. Since ATT&CK already covers Office 365, we wanted to ensure that users of Google’s productivity tools were also able to map similar applicable adversary behaviors to ATT&CK. We hope that this platform addition is helpful to the community, and would appreciate any feedback or insights.
We’re also excited to publish ATT&CK for Containers in this release! An ATT&CK research team partnered with the Center for Threat-Informed Defense to develop this contribution to ATT&CK. You can find more information about the ATT&CK for Containers research project and the new matrix in their blog post.
We hope you’re as excited as we are about v9 and are looking forward to the rest of the updates and new capabilities we have planned for 2021. October’s release should include episode 2 of data sources, featuring descriptive objects, as well as updates to ATT&CK for ICS and Mobile. We’ll also continue enhancing coverage of macOS and Linux techniques, so now is a great time to let us know if you have contributions or feedback on one of those platforms. We may have some additional improvements to announce in the coming months, but we stand by our promise of nothing as disruptive as the new tactics and sub-techniques from 2020.
We look forward to connecting with you on email, Twitter, or Slack.
©2021 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 21–00706–2.
What’s New in ATT&CK v9? was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
Written by Adam Pennington and Jen Burns
We’re excited to announce that we’ve released the latest version of MITRE ATT&CK (v8), which includes the integration of PRE-ATT&CK’s scope into Enterprise ATT&CK! This integration removes the PRE-ATT&CK domain from ATT&CK and adds two new tactics to Enterprise — Reconnaissance and Resource Development. Similar to our July release of sub-techniques, this is an update to ATT&CK that’s been under development for some time. You can find this new version of ATT&CK on our website, in the ATT&CK Navigator, as STIX, and via our TAXII server.
When we originally launched Enterprise ATT&CK, we focused on the behaviors that adversaries perform after they’ve broken into an environment, roughly the Exploit through Maintain phases of the MITRE Cyber Attack Lifecycle. This aligned well with the visibility of many defenders of their own networks, but it left pre-compromise adversary behaviors uncovered. After ATT&CK’s initial launch, a separate team at MITRE decided to fill in the gap to the left by following the structure of Enterprise ATT&CK and enumerating adversary behaviors leading up to a compromise. This work became PRE-ATT&CK and was released in 2017.
Some of you in the ATT&CK community have embraced and leveraged PRE-ATT&CK since that release to describe pre-compromise adversary behavior, but the framework never found the kind of adoption or contributions we’ve seen for Enterprise ATT&CK. We’ve also heard from a number of organizations over the years that Enterprise ATT&CK’s coverage of only post-compromise behaviors held up their ability to adopt it. In response, we started the process of integrating PRE-ATT&CK into Enterprise in 2018. As the first step of that integration, we deprecated PRE-ATT&CK’s Launch and Compromise tactics and incorporated their scope into the Initial Access tactic in Enterprise.
In my ATT&CKcon 2.0 presentation, I talked about how PRE-ATT&CK + Enterprise ATT&CK covering the complete Cyber Attack Lifecycle/Cyber Kill Chain® is a bit of an understatement. The scope of PRE-ATT&CK actually starts before Recon, with multiple tactics covering pre-reconnaissance intelligence planning. It also includes some behaviors that don’t leave technical footprints or might not have been seen in the wild. In early 2019, MITRE’s Ingrid Parker worked with the ATT&CK team to develop the following criteria for determining which PRE-ATT&CK behaviors could assimilate into Enterprise ATT&CK:
She found that PRE-ATT&CK could be divided into three sections. Based on the criteria, the first section, including PRE-ATT&CK Priority Definition Planning, Priority Definition Direction, and Target Selection tactics as well as a number of other techniques, are out of scope. That left us with two sections that divided quite well into the new tactics we released today:
1. Reconnaissance — focused on an adversary trying to gather information they can use to plan future operations, including techniques that involve adversaries actively or passively gathering information that can be used to support targeting.
2. Resource Development — focused on an adversary trying to establish resources they can use to support operations, including techniques that involve adversaries creating, purchasing, or compromising/stealing resources that can be used to support targeting.
Over the course of 2019 and a number of whiteboard sessions, I worked with former ATT&CK team member Katie Nickels to identify the techniques and sub-techniques that fit the three criteria, and covered the scope of the remaining techniques in the Reconnaissance and Resource Development portions of PRE-ATT&CK. This work was largely complete last October, and you might notice that the preview from ATT&CKcon 2.0 is very similar to what we released today. Because Reconnaissance and Resource Development leveraged sub-techniques, the work was suspended until those were implemented in Enterprise ATT&CK with our recent release. With sub-techniques out the door, ATT&CK team members Jamie Williams and Mike Hartley picked up the ball and created the content for the 73 new techniques and sub-techniques.
A question that arose during the creation of the Reconnaissance and Resource Development techniques is “What platform should these be?” For example, Gather Victim Identity Information (T1589) isn’t really Windows, macOS, Cloud or any specific existing enterprise platform. In order to reflect the different nature of these new techniques (and as a homage to PRE-ATT&CK), we added techniques in Reconnaissance and Resource Development to a new PRE platform.
Another unique characteristic of these new PRE techniques is their detection. While we scoped techniques to those “visible to some defenders,” most adversary Reconnaissance and Resource Development isn’t observable to the majority of defenders. In many cases, we’ve highlighted the related techniques where there may be an opportunity to detect an adversary. For the subset of techniques that are detectible by a broad set of defenders, we’ve described detections, some of which may require new Data Sources to see.
Mitigating Reconnaissance and Resource Development techniques can be challenging or unfeasible, as they take place in a space outside of an enterprise’s defenses and control. We’ve created a new Pre-compromise mitigation to recognize this difficulty, and noted where organizations may be able to minimize the amount and sensitivity of data available to external parties.
While these new techniques don’t typically take place on enterprise systems, are difficult to detect, and potentially impossible to mitigate, it’s still important to consider them. Even without perfect detection of adversary information collection, understanding what and how they’re collecting from Reconnaissance can help us examine our exposure and inform our operational security decisions. Similarly, our sensors may not detect most activity from Resource Development, but the tactic can offer valuable context. Many of the behaviors leave evidence visible to the right open/closed source intelligence gathering or can be discovered through an intelligence sharing relationship with someone who does have visibility.
We’re interested in your feedback on the content we’ve added and your input on any techniques, sub-techniques, detections, and mitigations you think we’ve missed. Do you have a way of detecting a particular Resource Development technique or preventing an adversary from successfully performing Reconnaissance? Please let us know by sending us an email, or contributing what you believe is currently missing.
Finally, if you aren’t ready to make the switch from PRE-ATT&CK, we’re still here for you. PRE-ATT&CK is still available in the previous version of our website, in the v7.2 and earlier versions of our STIX 2.0 content, and by filtering on the prepare stage in a previous version of the ATT&CK Navigator.
©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–00841–15.
Bringing PRE into Enterprise was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
By Matt Malone (MITRE), Jamie Williams (MITRE), Jen Burns (MITRE), and Adam Pennington (MITRE)
Last updated 19 April 2021 12:00pm EDT
Reporting regarding activity related to the SolarWinds supply chain injection has grown quickly since initial disclosure on 13 December 2020. A significant amount of press reporting has focused on the identification of the actor(s) involved, victim organizations, possible campaign timeline, and potential impact. The US Government and cyber community have also provided detailed information on how the campaign was likely conducted and some of the malware used.
MITRE’s ATT&CK team — with the assistance of contributors — has been mapping techniques used by the actor group, referred to as UNC2452/Dark Halo by FireEye and Volexity respectively and more recently attributed to the existing APT29/Cozy Bear/The Dukes threat group by members of the US Intelligence Community, as well as SUNBURST, SUNSPOT, Raindrop, and TEARDROP malware. We have now published a point release to ATT&CK, v8.2, with the information we’ve mapped and new techniques we’ve spotted so far.
It’s also been difficult keeping up with all the reporting and updates while trying to track down descriptions of adversary behavior, particularly as we’re looking for direct analysis of intrusion data rather than derivative reporting. We were originally listing reports we were tracking in this blog post itself, but have moved our tracking to a GitHub repository and are continuing to update that in partnership with MITRE Engenuity’s Center for Threat-Informed Defense.
A key challenge mapping current reporting is that the actor used a number of behaviors not currently described by ATT&CK Enterprise or Cloud techniques. We have added new techniques, sub-techniques, and expansions of scope on existing content to improve this coverage and wanted to describe what’s new in ATT&CK in v8.2.
First and foremost, we would like to thank the individuals and teams responsible for analyzing, publishing, and/or contributing invaluable information to help the community react and respond to this incident. This wealth of publicly available intelligence has described many behaviors performed by the threat actor identified as UNC2452/Dark Halo/SolarStorm. Mapping these behaviors to ATT&CK, we see a combination of very commonly used techniques (such as T1059 Command and Scripting Interpreter, T1105 Ingress Tool Transfer, and T1218 Signed Binary Proxy Execution) as well others that are less often disclosed in public reporting (ex: T1195 Supply Chain Compromise). You can see the techniques we currently have mapped in the ATT&CK Navigator here, or grab the Navigator layer file from our repository here.
Several behaviors were identified that weren’t previously explicitly captured within existing techniques. We have now released updates that include:
Along with new/updated techniques we have added several new group and software entries to ATT&CK including:
We don’t expect to add more content to ATT&CK itself before our next major release (announced as planned for April 2021 in our recent State of the ATT&CK), but anticipate that more reporting on this intrusion will continue to be released. We will be continuing to watch and add reporting to our public report tracking, as well as any new techniques or software that appear to the next release of ATT&CK.
If you see a technique we’re missing from existing reporting, a report with unique information that we’re missing out on, or want to share a mapping of a new report you’ve done, please reach out to us at [email protected].
©2020-2021 The MITRE Corporation. ALL RIGHTS RESERVED Approved for public release. Distribution unlimited 20–00841–22.
Identifying UNC2452-Related Techniques for ATT&CK was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
ATT&CK® for Mobile is an ATT&CK matrix of adversary behavior against mobile devices (smartphones and tablets running the Android or iOS/iPadOS operating systems). We started the ATT&CK for Mobile journey with the goal of highlighting the broader mobile threat landscape and adversary behavior exploiting the distinct security architectures in mobile devices. ATT&CK for Mobile was released in 2017 and since then we’ve continued to grow with each new ATT&CK content release, in strong part due to contributions received from many of you in the community.
We’ll be publishing a post formally introducing ATT&CK for Mobile and describing our future plans in the coming weeks and we also plan on posting a series addressing other mobile security technical topics. In this post, we’ll be highlighting how to leverage ATT&CK for Mobile to address abuse of Android application permissions and special app accesses.
Android Permissions and Special App Access in ATT&CK for Mobile
Mobile devices commonly run a variety of applications that have the potential to contain exploitable vulnerabilities or deliberate malicious behaviors. Given these risks, Android (as well as iOS/iPadOS) sandboxes applications, isolating them from one another and from the underlying device. Applications must obtain permission before accessing sensitive resources or performing sensitive operations.
In ATT&CK for Mobile, we describe how Android application permissions are abused by adversaries, and outline methods of defending from abuse. The matrix also details abuse of and defense from what Android calls “special app accesses”, which are requested and managed differently than regular Android permissions. Special app accesses require more complicated defense approaches.
Android Permissions: Abuses and Mitigations
Android requires that applications request permissions before accessing sensitive resources or performing sensitive operations. Applications must declare each permission in their AndroidManifest.xml file using a <uses-permission> entry. Depending on the permission type, they may also need to ask the user to grant the permission at application runtime.
Adversaries may distribute malicious applications that request and make use of permissions, or they may exploit vulnerabilities in legitimate applications that hold permissions.
For example, Capture Audio (T1429) describes adversaries calling standard operating system APIs from an application to activate the device microphone and record audio. As the technique description outlines, on Android the application must request and hold the android.permission.RECORD_AUDIO permission. This includes declaring a <uses-permission> entry for the permission in the AndroidManifest.xml file inside the Android application package and asking the user at runtime to grant the permission.[1] Also, Android restricts the ability of applications running in the background to capture audio, although we have encountered applications using the Foreground Persistence (T1541) technique to bypass this restriction.
Enterprises often deploy vetting solutions that automatically assess mobile applications for potentially malicious behaviors, including a scan of the application’s manifest file for declarations of higher risk permissions such as audio recording. Enterprises could then apply additional scrutiny to these applications and, if warranted, could block use of the applications. The applicable ATT&CK for Mobile technique entries feature Application Vetting as a mitigation.
Additionally, using an Enterprise Mobility Management (EMM) system, also commonly known as Mobile Device Management (MDM) or Unified Endpoint Management (UEM), an enterprise can push runtime permission policies to devices to prevent an application from using specific permissions. Runtime permission policies can effectively “neuter” applications, allowing use of the application while blocking potential harmful behaviors, rather than completely blocking use of an application.
In the example below, enterprise policies are deployed to block TikTok from obtaining sensitive permissions. The policies prevent TikTok from recording videos while still allowing TikTok to view videos. Runtime permission policies are not yet included as a mitigation within ATT&CK for Mobile but will be added in a future release.
Managing Special App Accesses
While adding ATT&CK for Mobile techniques and developing defense descriptions, we encountered what Android refers to as “special app accesses”. According to the Android Platform Security Model paper, these are a “special class of permissions” that “expose more or are higher risk” than other permissions.
Each special app access is managed separately and has a specific way to be requested by applications, adding complexity when vetting applications to detect their use. The standard runtime permission framework cannot be used by enterprises to control use of these accesses by applications. Rather, one-off device management policies exist for some, but not all, of the special app accesses.
ATT&CK for Mobile describes adversary use of special app accesses:
After special app accesses are obtained by applications, they can be managed by the device user through the “Special App Access” menu in the device settings (Settings -> Apps & Notifications -> Advanced -> Special App Access).
Unfortunately, these accesses are handled separately from regular permissions and cannot be managed by enterprises in the same way. There is typically (we identify an exception below) no <uses-permission> entry in the application’s AndroidManifest.xml that can be used to easily identify applications that use each access.
Instead, Android manages each special app access uniquely, making it necessary to perform specific one-off checks to detect each access’s use. For example, applications requesting the ability to read notifications create an Android service with an intent filter for the android.service.notification.NotificationListenerService action. Applications that attempt to read notifications can be detected by searching for a matching service entry in the app’s AndroidManifest.xml file.
The standard runtime permission enterprise management framework cannot be used by enterprises to control use of these accesses by applications. One-off device management policies only exist for a few of the special app accesses. For example, the DevicePolicyManager.setPermittedAccessibilityServices method can be used to impose an “allow list” of applications able to request accessibility access. The setPermittedInputMethods method can be used to impose an allow list of applications permitted to install an input method.
The following table is a non-exhaustive list outlining several special app accesses, the associated ATT&CK for Mobile techniques, how to detect an application’s use of the special app access, and how (as applicable) to use enterprise policies to prevent an application from using them.
We’re still verifying all of the described detection and prevention methods and are interested in your feedback on the table and if there are any additional elements we should consider. We plan to incorporate into the applicable techniques in a future ATT&CK for Mobile release.
Other special app accesses not yet included in ATT&CK for Mobile include:
Future Considerations for a Uniform Approach
If Android adjusted to a uniform approach to managing special app accesses, it would simplify the ability to detect or prevent their use. For example, in at least one special app access case, Android requires a <uses-permission> declaration in the AndroidManifest.xml file before an app can obtain the access. Apps must declare the MANAGE_EXTERNAL_STORAGE permission before they can request the “All files access” special app access. The special app access request is still handled outside of the regular means of requesting permissions. If the approach of requiring <uses-permission> declarations were uniformly extended to other special app accesses, it would be easier to detect apps that use them. A uniform approach to push policies to prevent applications from obtaining special app accesses, similar to the existing enterprise management controls on permissions, would also be useful.
Adversary Abuses in the Wild
As we continue to expand the Mobile knowledge base and update and develop new techniques, we welcome any input on adversary abuse of special app accesses in the wild! We’re also interested in your feedback on how to detect apps that use each special app access and how to prevent apps from using each special app access.
You can connect with us at [email protected].
© 2021 The MITRE Corporation. All Rights Reserved. Approved for Public Release; Distribution Unlimited. Public Release Case Number 21–0835.
[1] Similarly, on iOS/iPadOS, each application must include the NSMicrophoneUsageDescription key in its Info.plist file (part of the application package) and must ask the user for permission to use the microphone.
[2] The Android OS grants the SYSTEM_ALERT_WINDOW permission to keep track of apps that hold the Draw over Other Apps special app access, but apps themselves cannot directly request SYSTEM_ALERT_WINDOW through the regular means of requesting permissions.
Mitigating Abuse of Android Application Permissions and Special App Accesses was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
A review of how we navigated 2020 and where we’re heading in 2021
With the monumental disruptions, challenges, and hybrid work environments of 2020, we found innovative ways to collaborate and maintain momentum. We started off 2020 by launching ATT&CK for ICS and expanding it over the next few months to feature mitigations and STIX integration. A proposed ATT&CK data sources methodology was introduced, with the goal of more effectively representing adversary behavior from a data perspective. We added sub-techniques to address abstraction imbalances across the knowledge base, and for a few months, the matrix could fit on one slide again. PRE-ATT&CK’s scope was integrated into Enterprise ATT&CK, and two new tactics, Reconnaissance and Resource Development, emerged from the fusion. We released the Network Devices platform, featuring techniques targeting network infrastructure devices. The Cloud domain benefitted from refined Cloud data sources and new Cloud technique content. Our infrastructure team updated ATT&CK Navigator with new elements to enhance your visualization and planning experience. We launched the virtual ATT&CKCon PowerHour, featuring insights from ATT&CK practitioners and the ATT&CK team. Finally, we mapped techniques used in a series of intrusions involving SolarWinds (recently published as a point release to ATT&CK, v8.2) and publicly tracked reports describing those behaviors.
Our objectives for the next 12 months shouldn’t be as disruptive as 2020’s changes. There aren’t significant structural adjustments planned and we’re looking forward to a period of stability. Our chief focus will be on enhancing and enriching content across the ATT&CK platforms and technical domains. We’ll be making incremental updates to core concepts, such as Software and Groups, and working towards a more structured contributions process, while maintaining a biannual release tempo, scheduled for April and October.
Improving and Expanding Mac/Linux | April & October 2021
We first introduced Mac and Linux techniques in 2017 and we’re ramping up our effort to improve and expand the coverage in this space. Our research efforts are ongoing, and we’re coordinating with industry partners to enrich the existing techniques and develop additional content to cover evolving adversary behavior. We’re also venturing into sub-technique exploration and the refactoring of data sources. Our current timeline is targeting macOS updates for the April release and slating Linux updates for the October release. Interested in contributing to this effort? Connect with us or check out our Contributions page.
Evolving ATT&CK Data Sources | April 2021 & October 2021
You may be aware that we’re revamping the process for ATT&CK data sources. Data sources are currently reflected in ATT&CK as properties/field objects of (sub-)techniques and are featured as a list of text strings without additional details or descriptions. With the refactoring, we’re converting the data sources into objects, a role previously only held by tactics, techniques, groups, software and mitigations. With data sources as objects, they’ll have their own corresponding properties, or metadata.
The new metadata provided by data sources includes the concepts of relationships and data components. These concepts will more effectively represent adversary behavior from a data perspective and will provide an additional sub-layer of context to data sources. Data components narrow the identification of security events, but also create a bridge between high- and low-level concepts to inform data collection strategies. They’ll also provide a good reference point to start mapping telemetry collected in your environment to specific sub(techniques) and/or tactics. With the additional context around each data source, the results can be leveraged with more detail when defining data collection strategy for techniques and sub-techniques.
An update of current Enterprise ATT&CK data sources in line with this new methodology is currently planned for the April release, with objects coming in October. Data source refactoring for other ATT&CK domains and platforms are also in progress.
Consolidating Cloud Platforms and Enhancing Data Sources | April 2021
Later this year we’ll be consolidating the AWS, Azure, and GCP platforms into a single Infrastructure as a Service (IaaS) platform. Many of you in the community provided feedback in favor of consolidation, and currently these three platforms share the same set of techniques and sub-techniques. Additionally, an IaaS platform will evolve ATT&CK for Cloud into a more inclusive domain, representing all Cloud Service Providers.
We’re also focused on creating more beneficial data sources for Cloud, shifting from a log-centric approach that isn’t necessarily the most effective for building detections, to aligning to events and API calls within the logs. The approach will mirror the refactoring happening across the rest of Enterprise and will be incorporated in future Cloud updates. IaaS data sources are in progress, and we’ll be expanding coverage to the SaaS, Azure AD, and Office 365 platforms. The initial IaaS data sources are the result of the 2020 revamping that involved normalizing name and structure of data sources across multiple Cloud vendors, with the APIs and events involved in detections across those multiple vendors relevant to a particular data source. The example below features a draft of the Instance data source:
If you have input or opinions on the future platforms or the data sources refactoring, let us know! We want to ensure that the changes we have planned are going to be beneficial to and continue to support your efforts.
Cross-Domain Mapping and Updating ICS Data Sources | October 2021
Along with Enterprise, one of our goals for ATT&CK for ICS this year is updating data sources. Network traffic is a popular source of data in ICS networks, but it often overshadows other valuable data sources, including embedded device logs, application logs, and operational databases. Some of the key elements we’ll be focusing on are processing information, asset management, configuration, performance and statistics, and physical sensors.
We’re also working on cross domain mapping. We’ve always emphasized that adversaries don’t respect theoretical boundaries, so having a deep understanding of how IT platforms are leveraged to access different domains or technology stacks, like ICS and Mobile, is really critical. The cross-domain mappings will help inform how to use the knowledge bases together and will more effectively demonstrate the full gamut and adversary behavior. Over the next few months, we’ll be focusing on mapping significant attacks against ICS, including Stuxnet, Industroyer, the 2015 Ukrainian attacks, and Triton, to Enterprise techniques This is a community effort, so if you have feedback on how you’re currently using mitigations, any input on our data source focus, or would like to contribute to the matrix, we encourage you to connect with us.
Refining and Expanding Mobile | October 2021
A key focus area for Mobile this year is working towards feature equity with Enterprise. This means continuing to refine and enhance our content, including working to identify new techniques, building out Software entries, and enhancing Group information. We’ll also be developing Mobile sub-techniques, which would provide that extra level of detail for the techniques that need it, without significantly expanding the size of the model. In addition to resolving the different levels of granularity between current techniques, sub-techniques would provide enhanced synergy between Mobile and the broader ATT&CK. The integration could potentially include unifying techniques between Mobile and Enterprise and using sub-techniques to differentiate mobile device specifics. Similar to Cloud and Network, the mobile device-specific content would still be separately viewable.
We’ve been coordinating with MITRE Engenuity as they look to examine mobile threats and how to evaluate the types of capabilities and solutions that address the threat. Their eventual goal is to provide public evaluations for Mobile, but there is still a lot of collaboration and awareness building needed to bring the community up to a collective understanding of the mobile threat landscape. Building on the criticality of a collective community understanding of Mobile threats, we kicked off a mini-series highlighting significant threats to mobile devices and we’ll continue walking through mobile security threats and how to use ATT&CK for Mobile to address them in over the next few months. We’re very interested in any adversary behavior targeting mobile devices that you’re seeing in the wild. If you would like to help us build out new techniques, or if you have data or observed behaviors you’d like to share, reach out or take a look at our Contributions page.
Investigating Container-based Techniques | Upcoming
Technique coverage for Container technologies (such as Kubernetes and Docker) have been on our docket for a while, and following the call for input in December, supporting a Center for Threat Informed Defense (CTID) research project, many of you responded with the contributions that informed the draft ATT&CK for Containers. We’re excited about this milestone, but we’re still exploring a few avenues before incorporating the techniques into ATT&CK. Most critically, we’re working to determine if adversary behaviors targeting containers result in objectives other than cryptomining. Our own research and ongoing conversations with contributors seem to point to most behaviors eventually leading to cryptomining activities, even when they involve accessing secrets such as cloud credentials.
With this in mind — we need your expertise and views from the trenches! If you’ve seen or heard of adversaries using containers for purposes such as exfiltration or collection of sensitive data, your input would be invaluable. With a better understanding of how adversary behavior in containers links to the rest of Enterprise, we’ll be able to develop a better approach for adding Containers techniques in a future ATT&CK release. We’re interested in your opinions on any gaps in the matrix or in-the-wild adversary behaviors that are not currently represented — let us know if you’d like to have a conversation!
Unleashing ATT&CK Workbench | Upcoming
Later this year we’re partnering with the CTID to launch a new toolset that will enable you to get behind the wheel and explore, create, annotate and share extensions of ATT&CK. ATT&CK Workbench will provide the tools, infrastructure, and documentation to simplify how you operate and adapt ATT&CK to local environments while staying in sync with upstream sources of ATT&CK content. Ever wanted to add some new procedures to T1531? Or monitor a threat group ATT&CK’s not currently tracking? How about sharing notes with team members on a specific object? Workbench will also enhance our ability to collaborate — you’ll be able to easily contribute techniques, extensions, and enhancements to ATT&CK. We’re excited to see how the community will leverage the toolset to apply the ATT&CK approach to new domains.
Innovating ATT&CKcon | Upcoming
We kicked off the concept of ATT&CKcon in 2018, and our inaugural venture featured around 1,250 virtual and in-person participants. In 2019, ATT&CKcon 2.0 reached more people than ever before, with 7,315 online registrations. With the global pandemic in 2020, we created ATT&CKcon Power Hour, a series of monthly 90-minute virtual power presentations, which have had a reach of over 12,000 to date. We don’t know exactly what ATT&CKcon 3.0 (4.0?) in 2021 will bring, aside from the great speakers sharing their insights from working with ATT&CK in the trenches, but we’re excited to see how it’ll continue to grow. Stay tuned for additional details on what ATT&CKcon 2021 will look like and how you can get involved.
Listening to the ATT&CK community, incorporating your feedback, and acting on your input has always been central to our model. ATT&CK is community-driven, and your first-hand knowledge and on-the-ground experience will continue to be critical to our efforts to evolve and expand the framework. We look forward to collaborating with you and appreciate your dedication to helping us improve ATT&CK for the entire community. You can always connect with us via email, Twitter, or Slack.
©2021 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–00841–24.
ATT&CK 2021 Roadmap was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
In part 1 of this blog series, we introduced how you can break down and understand detections by security products. When analyzing ATT&CK Evaluations results, we have found it helpful to assess and deconstruct each detection based on three key benchmarks:
The first two benchmarks (availability and efficacy) are naturally defined by data sources, from which context is derived. Context, understanding the true meaning and consequences of events, is what enables actionability, but is limited to what raw data inputs you consume (availability), as well as consuming enough of the right data to make sense of the situation (efficacy).
In this second and final part of this blog series, we address the always relevant question of “so what?” and provide insight into why we are so excited to introduce protections into the next round of ATT&CK Evaluations. Detecting malicious events is not the final solution to thwarting adversaries, as some action needs to be taken to mitigate, remediate, and prevent current and future threats activity. The context provided by data sources is what enables us to make these actionable decisions, whether they are operational (ex: killing a malicious process) or strategic (ex: hardening an environment in an attempt to prevent the execution of malicious processes).
Every detection ends with actionability, where the value of the entire detection process is realized. The actionable decisions we make begins with the available context surrounding a detection. However, generating detections does not guarantee successful actionability, as there are many other factors that challenge the strength of a detection’s context and must be addressed. We will explore and highlight these critical factors in the following case study.
Day 2 of the APT29 Emulation included a very interesting implementation of Credential Dumping (T1003). As described in publicly available cyber threat intelligence, APT29 has dumped plain-text credentials from victims using a PowerShell implementation of Mimikatz (Invoke-Mimikatz) hidden in and executed from a custom WMI class. Similar to the APT29 malware, we emulated this complex behavior in a single PowerShell script that was evaluated as steps 14.B.1 through 14.B.6, which leads us to our first actionability challenge.
We’ve learned a lot during our ATT&CK Evaluations journey. One of our biggest realizations relates to the difference between experimentation and real-world application. In the lab, we’re interested in capturing and analyzing every available data point to garner the maximum amount of specific and measurable results that we can analyze and draw conclusions from. However, reality is often much different, as real-world success may be based on maximizing the value of a single, seemingly less significant data point within an experiment.
This idea is highlighted by the credential dumping case study. The credential dumping behavior of the APT29 emulation was evaluated as six different but connected techniques, each with its own detection criteria and results.
These granular results are critical to Evaluations, where we aim to identify strengths/gaps and ultimately promote improvements, one technique at a time. But as defenders in the real world, do we actually need to detect every technique within this behavior to have a fighting chance at actionability?
The answer to this question of course circles back to context. Detecting each technique within this behavior provides an integral factor to understanding the entire scenario and how a defender could respond:
As demonstrated above, the detection of each individual technique may provide unique context that can lead to a more complete actionable response. However, we can also see that the defensive action associated with each individual technique could prevent the behavior, as interrupting even a single technique of this behavior would stop the adversary from successfully obtaining credentials. Also, each defensive action could reveal more context that leads to the detection of the other connected techniques (e.g., investigating the WMI class would reveal the code to download and execute Mimikatz). These conclusions on the interrelationship between connected techniques leads to our next factor of actionability.
Although we provide Evaluations results one technique at a time, in reality, breaches are a series of connected techniques and behaviors. As the credential dumping case study shows, the behavior is a series of functionally dependent techniques an adversary uses to accomplish a single goal (obtaining credentials). One break in that process may render the behavior unsuccessful.
This concept directly relates to the Evaluation’s detection Correlated modifier (known in the APT3 Evaluation round as Tainted). Defined as presenting a detection “as being descendant of events previously identified as suspicious/malicious,” this highlights another factor of the actionability of a detection. Specifically, the actionability of a detection can be enhanced by detections of previous techniques and behaviors.
To clarify this point, let’s review the credential dumping case study. Typically discovery techniques, such as the process discovery (T1057) in step 14.B.2, have less impactful potential defensive responsive actions. Unless the adversary discovery can easily be recognized as potentially malicious (such as scanning entire IP ranges), these techniques may blend into the “noise” of benign user activity. Since discovery techniques often utilize legitimate system utilities (such as binaries or protocols regularly used by users and services), preventing execution of these techniques may render systems unusable.
So how does the correlated modifier enhance actionability? Even if the process discovery in Step 14.B.2 is detected, as defenders, what can we confidently do with this information? Is killing every process discovering other processes an appropriate response, or do we need more context to make a better decision? In this case, detecting that technique alone is probably not enough to take action, but if we connect 14.B.2 back to 14.B.1 and recognize that the process discovery is being executed from an abnormal WMI execution (more context), we may have what we need to make a sound defensive action.
The power of correlation does not just exist within a single behavior. As we previously discussed, a breach is a series of connected behaviors. In our credential dumping case study, the behaviors of step 14.B are preceded by various detectable behaviors such as executing a malicious payload (Step 11.A) and bypassing UAC to elevate privileges (Step 14.A). Correlation enhances actionability by providing more context, not specifically to a single technique but rather to the entire story of behaviors. This leads to our final factor of actionability, which addresses how to detect the gaps in this story.
In a perfect world, every story has a complete beginning, middle, and end. Each part of the story builds upon the previous parts and flows into the next. With detections, we capture this as correlation, where our context of the adversary’s story increases with each new detection. But does that context disappear if a piece is missing?
Looking back at the credential dumping case study, we are reminded that although not ideal, in the real world we can possibly tolerate “misses.” For example, even if we did not detect the credential dumping technique (14.B.4), we could potentially still understand the behavior based on the surrounding context. Detections capturing the write of the Mimikatz file (14.B.3) and saving the Mimikatz results (14.B.5) could fill in the missing gap (at least enough to take action) based on correlation and the surrounding context of the story.
Context is key, but as the credential dumping case study highlighted detecting a behavior is not detecting every technique. If we organize and interpret our data correctly, we may not need to connect every piece of the puzzle to understand and act on the situation in front of us.
As Keith McCammon outlined during his ATT&CKcon 2.0 presentation, Prioritizing Data Sources for Minimum Viable Detection, we need to focus on “the probable” vice “the possible.” In the case of detections, this translates to the conclusion that with the right context we don’t need to detect everything to be effective. We must learn to operate with and make the most of what we have. While we should always continually innovate and improve, this is another practical recognition of how we interpret the ATT&CK Evaluation results and how understanding detection capabilities can make us better defenders.
In this two-part blog series, we discussed how we deconstruct and analyze detections using the availability, efficacy, and actionability benchmarks. As explained both in this post and in part 1, we continuously try to evolve and advance the way we execute and share Evaluations results. Along with data sources in the detection categories to address availability and efficacy, additional adjustments will be made to our Carbanak and FIN7 evaluations. As we shared here, these will include the introduction of the protections evaluations and a new approach to illuminating each vendor’s alert and correlation strategy. We believe these changes will further highlight the actionability of each detection.
We hope that this series, as well as the corresponding changes to ATT&CK Evaluations, enhances your ability to use the results. Please reach out to us with any additional feedback or ideas on how we can provide more value. As always, stay healthy and safe.
©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–00876–5.
Actionable Detections: An Analysis of ATT&CK Evaluations Data Part 2 of 2 was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
(Note: Much of the content in this post was consolidated and updated from previous posts written by Blake Strom with new content from Adam Pennington, Jamie Williams, and Amy L. Robertson)
We’re thrilled to announce that ATT&CK with sub-techniques is now live! This change has been a long time coming. Almost a year ago, we gave a first look at sub-techniques, and laid out our reasons for moving to them. This past March, based on feedback from that preview, we released a beta of ATT&CK with sub-techniques and now (with some small updates and fixes) it has become the current version of ATT&CK. You can find the new version of ATT&CK on our website, via the ATT&CK Navigator, as STIX, and via our TAXII server. Our “MITRE ATT&CK: Design and Philosophy” paper was also updated in March to reflect sub-techniques.
You can review the final change log here, which includes the changes from our last release (October 2019/v6.3) as well as some small changes since our beta (March 2020/v7.0-beta) release. If you have already been using our March beta, please take special note of the “Errata” and “New Techniques” in the “Compared to v7.0-beta” tab (nearly all of the “Technique changes” are due to the errata/new techniques and “Minor Technique changes” are generally small changes to descriptions).
Back in March, we released JSON and CSV “crosswalks” to help people moving from the October 2019 release of ATT&CK to ATT&CK with sub-techniques. Since the beta, we have updated and refined the format of these crosswalks in order to reduce the amount of human intervention and text parsing required to use them programmatically (we explore more about how you can use these crosswalks below). We would also like to extend a special thanks to Ruben Bouman for his excellent feedback on the beta crosswalks.
Before we dive into these exciting changes, we want to reassure you that previous version of ATT&CK (without sub-techniques) are still accessible. We respect and recognize that the addition of sub-techniques is a significant change and not something everyone will adopt immediately, so you’ll still have the ability to reference older content.
There are a few ways you can access previous versions of ATT&CK. The simplest is through our versions page, which links to versions of ATT&CK prior to sub-techniques (ATT&CK v6 and earlier) as well as the previous sub-techniques beta (ATT&CK v7-beta). It also contains links to the equivalent historical STIX representations of ATT&CK. You can also add “versions/v6/” to the beginning of any existing ATT&CK URL (for example, https://attack.mitre.org/techniques/T1098/ becomes https://attack.mitre.org/versions/v6/techniques/T1098/) in order to view the last version of a page prior to sub-techniques. If you have pre sub-technique layer files, the previous version of the ATT&CK Navigator can be found here.
ATT&CK has been in constant development for seven years now. We work every day to both maintain and evolve ATT&CK to reflect the behaviors threat actors are executing in the real world largely based on input from the community. Over that time, ATT&CK has grown quite a bit (we hit 266 Enterprise techniques as of October 2019) while still maintaining our original design decisions. ATT&CK’s growth has 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 heard from you at ATT&CKcon and during conversations with many teams that techniques being at different granularity levels is an issue — some have even started to develop their own concepts for sub-techniques. We wanted to address the granularity challenge while also giving the community a more robust framework to build onto over time.
This is a big change in how people view and use ATT&CK. We’re well aware that re-structuring ATT&CK to solve these issues could cause some re-design of processes and tooling around the changes. We think these changes are necessary for the long-term growth of ATT&CK and the majority of the feedback we’ve gotten has agreed.
Simply put, sub-techniques are more specific techniques. Techniques represent the broad action an adversary takes to achieve a tactical goal, whereas a sub-technique is a more specific adversary action. For example, a technique such as Process Injection has 11 sub-techniques to cover (in more detail) the variations of how adversaries have injected code into processes.
The structure of techniques and sub-techniques are nearly identical as far as what fields exist and information is contained within them (description, detection, mitigation, data sources, etc.) — the fundamental difference will be the in their relationships, with each sub-technique having a parent technique.
We’re frequently asked, “why didn’t you call them procedures?” The simplest answer is that procedures already exist in ATT&CK, they describe the in-the-wild use of techniques. Sub-techniques on the other hand are simply more specific techniques. Techniques, as well as sub-techniques have their own sets of mapped procedures.
Groups and software pages have also been updated to capture mappings to both techniques and sub-techniques.
First, you’ll need to implement some changes to ATT&CK’s technique structure necessary to support sub-techniques. In order to identify sub-techniques, we’ve expanded ATT&CK technique IDs in the form T[technique].[sub-technique]. For example, Process Injection is still T1055, but the sub-technique Process Injection: Dynamic-link Library Injection is T1055.001 and other sub-techniques for Process Injection are numbered similarly. If you’re working with our STIX representation of ATT&CK we’ve added “x_mitre_is_subtechnique = true” to “attack-pattern” objects that represent a sub-technique, and “subtechnique-of” relationships between techniques and sub-techniques. Our updated STIX representation is documented here.
Next, you’ll want to remap your content from the previous version of ATT&CK, to this new release with sub-techniques. As with our beta release, we’re providing two forms of translation tables or “crosswalks” from our previous release technique IDs to the new version with sub-techniques to help with the transition. The CSV files are essentially flat files that show what happened to each technique in the previous release. We have one file for each tactic, which includes every ATT&CK technique that was in that tactic in the October 2019 ATT&CK release. We’ve also included CSV files showing what new techniques have been added in this release along with the new sub-techniques that were created. We have also created a JSON representation for greater machine readability.
Thanks to the excellent feedback from the community (thanks again to Ruben Bouman, as well as Marcus Bakker for the initial structure idea), we identified seven key types of changes:
Each of these types of changes is represented in the “Change Type” column of the CSVs or “change-type” field in the JSON. Some of these changes are simpler to implement than others. We recognize this, and in the following steps, we incorporate the seven types of changes into tips on how to move from our previous release to ATT&CK with sub-techniques.
For content mapped to the October 2019/v6 version of ATT&CK, start by replacing the existing technique ID from the value in the “TID” column with the value in the “New ID” column if there is one. Next, update the technique name to match “New Technique Name”. For Remains Technique, Became a Sub-Technique, Multiple Techniques Became New Sub-Technique, One or More Techniques Became New Technique, or Merged into Existing Technique change types you will mostly be done. We’ll handle the remaining two cases in Step 2. In some cases tactics have been removed, so it’s also worth checking the “Note” field in the CSV and “explanation” in the JSON.
Remains Technique
The first thing that’s easy to remap — the techniques that aren’t changing and don’t need to be remapped. Anything labeled “Remains Technique” is still a technique with an unchanged technique ID like T1091 in the above example.
Became a Sub-Technique
Next in the “easy to remap category” are the technique to sub-technique transitions, labeled “Became a Sub-Technique”, which account for a large percentage of the changes. These techniques were converted into the sub-technique of another technique. In this example, Pass the Ticket (T1097) became Use Alternative Authentication Material: Pass the Ticket (T1550.003).
Finally, there are a few cases where techniques merged with other techniques.
Multiple Techniques Became New Sub-Technique
For techniques labeled “Multiple Techniques Became New Sub-Technique”, a new sub-technique was created covering the scope and content of multiple previous techniques. For example, Plist Modification (T1150) and Login Item (T1162) merged into Boot or Logon Autostart Execution: Plist Modification (T1547.011).
One or More Techniques Became New Technique
For techniques labeled “One or More Techniques Became New Technique” a new technique was created covering the scope and content of one or more previous techniques. For example, Data Compressed (T1002) and Data Encrypted (T1022) merged into Archive Collected Data (T1560) and its various sub-techniques.
Merged into Existing Technique
For techniques labeled “Merged into Existing Technique”, the scope and content of a technique was added into an existing technique. For example, Local Job Scheduling (T1168) merged into Scheduled Task/Job (T1053).
For any of these “easy” types of changes anything represented by the previous ATT&CK technique ID should be transitioned to the new technique or sub-technique ID. The ATT&CK STIX objects represent this type of change as a revoked object which leaves behind a pointer to what they were revoked by. In the case of T1097 above, that means it was revoked by T1550.003.
In all of these cases, taking what’s listed in the “TID” column and replacing it with what’s listed in the “New ID” column, and using the “New Technique Name” should give you the correct new technique.
This is where some manual effort will be required. Deprecated techniques are not as straightforward.
Deprecated
For techniques labeled as “Deprecated”, we removed them from ATT&CK without replacing them. They were deprecated because we felt they did not fit into ATT&CK or due to a lack of observed in the wild use. For example, Shared Webroot (T1051) was removed because we hadn’t been able to find evidence of any adversary using it in the wild for lateral movement after five years.
Became Multiple Sub-Techniques
Techniques labeled as “Became Multiple Sub-Techniques” were also deprecated because the ideas behind the technique fit better as multiple sub-techniques. In the above example, T1175 has been deprecated and we explain that it was split into into two sub-techniques for Component Object Model and Distributed Component Object Model. These two entries will show up in the new_subtechniques CSV with further details about where they now show up in ATT&CK.
If you have analytics or intelligence mapped to T1175, then it will take some manual analysis to determine how to remap appropriately since some may fit in T1559.001 and some in T1021.003.
If you want to take full advantage of sub-techniques, there’s one more step. Many “Remains Technique” techniques now have new sub-techniques you can take advantage of.
One great example of an existing technique that now has new sub-techniques is Credential Dumping (T1003). The name was changed slightly to OS Credential Dumping and its content was broken into a number of sub-techniques.
The new sub-techniques add more detail and taking advantage of them will require some manual analysis. The good news is that the additional granularity will allow you to represent different types of credential dumping that can happen at a more detailed level. These types of remaps can be done over time, because if you keep something mapped to OS Credential Dumping, then it’s still correct. You can map new stuff to the sub-techniques and come back to the old ones to make them more precise as you have time and resources.
TL;DR, if you do just Step 1 while mapping things that are deprecated to NULL, then it will still be correct. If you do Step 2, then you’ll have pretty much everything you mapped before now also mapped to the new ATT&CK. If you complete Step 3, then you’ll get the newfound power of sub-techniques!
Although previous versions of Enterprise ATT&CK will remain available, new content will only be added to this latest version leveraging sub-techniques. Other ATT&CK related projects, such as Navigator and the Cyber Analytic Repository (CAR), have also already made the transition. Mobile, ICS, and the other ATT&CK platforms plan to eventually implement sub-techniques as well. We look forward to exploring all of the new opportunities these improvements provide.
We would like to thank everyone that made these exciting changes possible, including the ATT&CK Team (past and present) and the amazing ATT&CK community for your continuous feedback and support.
©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–00841–6.
“ATT&CK with Sub-Techniques” is Now Just ATT&CK was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
