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, 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.
Discussion around ATT&CK often involves tactics, techniques, procedures, detections, and mitigations, but a significant element is often overlooked: data sources. Data sources for every technique provide valuable context and opportunities to improve your security posture and impact your detection strategy.
This two-part blog series will outline a new methodology to extend ATT&CK’s current data sources. In this post, we explore the current state of data sources and an initial approach to enhance them through data modeling. We’ll define what an ATT&CK data source object represents and how we can extend it to introduce the concept of data components. In our next post we’ll introduce a methodology to help define new ATT&CK data source objects.
The table below outlines our proposed data source object schema:
Data sources are featured as part of the (sub)technique object properties:
While the current structure only contains the names of the data sources, to understand and effectively apply these data sources, it is necessary to align them with detection technologies, logs, and sensors.
The MITRE ATT&CK: Design and Philosophy white-paper defines data sources as “information collected by a sensor or logging system that may be used to collect information relevant to identifying the action being performed, sequence of actions, or the results of those actions by an adversary”.
ATT&CK’s data sources provide a way to create a relationship between adversary activity and the telemetry collected in a network environment. This makes data sources one of the most vital aspects when developing detection rules for adversary actions mapped to the framework.
Need some visualizations and audio track to help decipher the relationships between data sources and the number of techniques covered by them? My brother and I recently presented at ATT&CKcon on how you can explore more about data sources metadata and how to use sources to drive successful hunt programs.
We categorized a number of ways to improve the current approach to data sources. Many of these are based on community feedback, and we’re interested in your reactions and comments to our proposed upgrades.
Community feedback emphasizes that having definitions for each data source will enhance efficiency while also contributing to data collection strategy development. This will enable ATT&CK users to quickly translate data sources to specific sensors and logs in their environment.
Standardizing the naming convention for data sources is another factor that came up during feedback conversations. As we outline in the image below, data sources can be interpreted differently. For example, some data sources are very specific, e.g., Windows Registry, while others, such as Malware Reverse Engineering, have a wider scope. We propose a consistent naming syntax structure that addresses explicitly defined elements of interest from the data being collected such as files, processes, DLLs, etc.
Another unintended consequence of not having a standard naming structure for data sources is redundancy, which can also lead to overlaps.
Example A: Loaded DLLs and DLL monitoring
The recommended data sources related to DLLs imply two different detection mechanisms; however, both techniques leverage DLLs being loaded to proxy execution of malicious code. Do we collect “Loaded DLLs” or focus on “DLL Monitoring”? Do we do both? Can they just be one data source?
Example B: Collecting process telemetry
All of the information provided by Process Command-line Parameters, Process use of Network, and Process Monitoring refer to a common element of interest, a process. Do we consider that “Process Command-Line Parameters” could be inside of “Process Monitoring”? Can “Process Use of Network” also cover “Process Monitoring” or could it be an independent data source?
Example C: Breaking down or aggregating Windows Event Logs
Finally, data sources such as “Windows Event Logs” have a very broad scope and cover several other data sources. The image below shows some of the data sources that can be grouped under event logs collected from Windows endpoints:
ATT&CK recommends collecting events from data sources such as PowerShell Logs, Windows Event Reporting, WMI objects, and Windows Registry. However, these could be already covered by “Windows Event Logs” as previously shown. Do we group every Windows data source under “Windows Event Logs” or keep them all as independent data sources?
There are also data sources that, from a technique’s perspective, are linked to platforms where they can’t feasibly be collected. For example, the image below highlights data sources related to the Windows platform such as PowerShell logs and Windows Registry given for techniques that can be also used on other platforms such as macOS and Linux.
This issue has been addressed to a degree by the release of ATT&CK’s sub-techniques. For instance, in the image below you can see a description of the OS Credential Dumping (T1003) technique, the platforms where it can be performed, and the recommended data sources.
While the field presentation could still lead us to relate PowerShell logs data source to non-Windows platform, once we start digging deeper into sub-technique details, the association between PowerShell logs and non-Windows platforms disappears.
Defining the concept of platforms at a data source level would increase the effectiveness of collection. This could be accomplished by upgrading data sources from a simple property or field value to the status of an object in ATT&CK, similar to a (sub)technique.
Based on feedback from the ATT&CK community, it made sense to start providing definitions for each ATT&CK data source. However, we realized right away that without a structure and a methodology to describe data sources, definitions would be a challenge. Even though it was simple to describe data sources such as “Process Monitoring”, “File Monitoring”, “Windows Registry” and even “DLL Monitoring”, data source descriptions for “Disk Forensics”, “Detonation Chamber” or “Third Party Application Logs” are more complex.
We ultimately recognized that we needed to apply data concepts that could help us provide more context to each data source in an organized and standardized way. This would allow us to also identify potential relationships among data sources and improve the mapping of adversary actions to data that we collect.
Our methodology for upgrading ATT&CK’s data sources is captured in the following six ideas:
A data model is a collection of concepts for organizing data elements and standardizing how they relate to one another. If we apply this basic concept to security data sources, we can start identifying core data elements that could be used to describe a data source in a more structured way. Furthermore, this will help us to identify relationships among data sources and enhance the process of capturing TTPs from adversary actions.
Here is an initial proposed data model for ATT&CK data sources:
Based on this notional model, we can begin to identify relationships between data sources and how they apply to logs and sensors. For example, the image below represents several data elements and relationships identified while working with Sysmon event logs:
Data modeling enables us to validate data source names and provide a definition for each one in a standardized way. This is accomplished by leveraging the main data elements present in the data we collect.
We can use the data element to name the data source related to the adversary behavior that we want to collect data about. For example, if an adversary modifies a Windows Registry value, we’ll collect telemetry from the Windows Registry. How the adversary modifies the registry, such as the process or user that performed the action, is additional context we can leverage to help us define the data source.
We can also group related data elements to provide a general idea of what needs to be collected. For example, we can group the data elements that provide metadata about network traffic and name it Netflow.
Leveraging data modeling concepts would also enhance ATT&CK’s current approach to mapping a data source to a technique or sub-technique. Breaking down data sources and standardizing the way data elements relate to each other would allow us to start providing more context around adversary behaviors from a data perspective. ATT&CK users could take those concepts and identify what specific events they need to collect to ensure coverage over a specific adversary action.
For example, in the image below, we can add more information to the Windows Registry data source by providing some of the data elements that relate to each other to provide more context around the adversary action. We can go from Windows Registry to ( Process — created — Registry Key).
This is just one relationship that we can map to the Windows Registry data source. However, this additional information will facilitate a better understanding of the specific data we need to collect.
The key components in ATT&CK — tactics, techniques, and groups — are defined as objects. The image below demonstrates how the technique object is represented within the framework.
While data sources have always been a property/field object of a technique, it’s time to convert them into objects, with their own corresponding properties.
Once data sources are integrated as objects in the ATT&CK framework, and we establish a structured way to define data sources, we can start identifying additional information or metadata in the form of properties.
The table below outlines some initial properties we propose starting off with:
These initial properties will advance ATT&CK data sources to the next level and open the door to additional information that will facilitate more efficient data collection strategies.
Our final proposal is to define data components. The relationships we previously discussed between the data elements related to the data sources (e.g., Process, IP, File, Registry) can be grouped together and provide an additional sub-layer of context to data sources. This concept was developed as part of the Open Source Security Event Metadata (OSSEM) project and presented at ATT&CKcon 2018 and 2019. We refer to this concept as Data Components.
Data Components in action
In the image below, we extended the concept of Process and defined a few data components including Process Creation and Process Network Connection to provide additional context. The outlined method is meant to provide a visualization of how to collect from a Process perspective. These data components were created based on relationships among data elements identified in the available data source telemetry.
The diagram below maps out how ATT&CK could provide information from the data source to the relationships identified among the data elements that define the data source. It’d then be up to you to determine how best to map those data components and relationships to the specific data you collect.
In the second post of this two-part series, we’ll explore a methodology to help define new ATT&CK data source objects and how to implement the methodology with current data sources. We will also release the output of our initial analysis, where we applied these data modeling concepts to draft a sample of the new proposed data source objects. In the interim, we appreciate those who contributed to the discussions around data sources and we look forward to your additional feedback.
©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 20–00841–11.
Defining ATT&CK Data Sources, Part I: Enhancing the Current State was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
(Note: The content of this post is being released jointly with Mandiant. It is co-authored with Daniel Kapellmann Zafra, Keith Lunden, Nathan Brubaker and Gabriel Agboruche. The Mandiant post can be found here.)
Understanding the increasingly complex threats faced by industrial and critical infrastructure organizations is not a simple task. As high-skilled threat actors continue to learn about the unique nuances of operational technology (OT) and industrial control systems (ICS), we increasingly observe attackers exploring a diversity of methods to reach their goals. Defenders face the challenge of systematically analyzing information from these incidents, developing methods to compare results, and communicating the information in a common lexicon. To address this challenge, in January 2020, MITRE released the ATT&CK for ICS knowledge base, which categorizes the tactics, techniques, and procedures (TTPs) used by threat actors targeting ICS.
MITRE’s ATT&CK for ICS knowledge base has succeeded in portraying for the first time the unique sets of threat actor TTPs involved in attacks targeting ICS. It picks up from where the Enterprise knowledge base leaves off to explain the portions of an ICS attack that are out of scope of ATT&CK for Enterprise. However, as the knowledge base becomes more mature and broadly adopted, there are still challenges to address. As threat actors do not respect theoretical boundaries between IT or ICS when moving across OT networks, defenders must remember that ATT&CK for ICS and Enterprise are complementary. As explained by MITRE’s ATT&CK for ICS: Design & Philosophy paper, an understanding of both knowledge bases is necessary for tracking threat actor behaviors across OT incidents.
In this blog, written jointly by Mandiant Threat Intelligence and MITRE, we evaluate the integration of a hybrid ATT&CK matrix visualization that accurately represents the complexity of events across the OT Targeted Attack Lifecycle. Our proposal takes components from the existing ATT&CK knowledge bases and integrates them into a single matrix visualization. It takes into consideration MITRE’s current work in progress aimed at creating a STIX representation of ATT&CK for ICS, incorporating ATT&CK for ICS into the ATT&CK Navigator tool, and representing the IT portions of ICS attacks in ATT&CK for Enterprise. As a result, this proposal focuses not only on data accuracy, but also on the tools and data formats available for users.
Joint Analysis of Enterprise and ICS TTPs to Portray the Full Range of Actor Behaviors
For years, Mandiant has leveraged the ATT&CK for Enterprise knowledge base to map, categorize, and visualize attacker TTPs across a variety of cyber security incidents. When ATT&CK for ICS was first released, Mandiant began to map our threat intelligence data of OT incidents to the new knowledge base to categorize detailed information on TTPs leveraged against ICS assets. While Mandiant found the knowledge base very useful for its unique selection of techniques related to ICS equipment, we noticed how helpful it could be to develop a standard way to group and visualize both Enterprise and ICS TTPs to understand and communicate the full range of actors’ actions in OT environments during most incidents we had observed. We reached out to MITRE to discuss the benefits of joint analysis of Enterprise and ICS ATT&CK techniques and exchanged some ideas on how to best integrate this task as they continued to work on the evolution of these knowledge bases.
Enterprise and ICS TTPs Are Necessary to Account for Activity in Intermediary Systems
One of the main challenges faced by ATT&CK for ICS is categorizing activity from a diverse set of assets present in OT networks. While the knowledge base contains TTPs that effectively explain threats to ICS — such as programmable logical controllers (PLCs) and other embedded systems — it by design does not include techniques related to OT assets that run on similar operating systems, protocols, and applications as enterprise IT assets. These OT systems, which Mandiant defines as intermediary systems, are often used by threat actors as stepping-stones to gain access to ICS. These workstations and servers are typically used for ICS functionalities such as running human machine interface (HMI) software or programming and exchanging data with PLCs.
At the system level, the scope of ATT&CK for ICS includes most of the ICS software and relevant system resources running on these intermediary Windows and Linux-based systems while omitting the underlying OS platform (Figure 2). While the majority of ATT&CK for Enterprise techniques are thus descoped, there remains some overlap in techniques between ATT&CK for ICS and ATT&CK for Enterprise as the system resources granted to ICS software are in-scope for both knowledge bases. However, this artificial divorce of the ICS software from the underlying OS can be inconsistent with an adversaries’ possible overarching control of the compromised asset.
As MITRE’s ATT&CK for ICS was designed to rely on ATT&CK for Enterprise to categorize adversary behaviors in these intermediary systems, there is an opportunity to develop a standard mechanism to analyze and communicate incidents using both knowledge databases simultaneously. As the two knowledge bases still maintain an undefined relationship, it may be difficult for ATT&CK users to understand and interpret incidents consistently. Furthermore, ICS owners and operators who unknowingly discard ATT&CK for Enterprise in favor of ATT&CK for ICS run the risk of missing valuable intelligence applicable to the bulk of their OT assets.
Enterprise and ICS TTPs Are Useful to Foresee Future Attack Scenarios
As MITRE notes in their ATT&CK for ICS: Design & Philosophy paper, the selection of techniques for ATT&CK for ICS is mainly based on available evidence of documented attack activity against ICS and the assumed capabilities of ICS assets. While the analysis of techniques based on previous observations and current capabilities presents a solid preamble to describe threats in retrospect, Mandiant has identified an opportunity for ATT&CK knowledge and tools to support OT security organizations to foresee novel and future scenarios. This is especially relevant in the evolving field of OT security, where asset capabilities are expanding, and we have only observed a small number of well-documented events that have each followed a different attack path based on the target.
MITRE’s intent is to limit the ATT&CK knowledge base to techniques that have been observed against in-scope assets. However, from Mandiant’s perspective as a security vendor, the analysis of exhaustive techniques–including both observed and feasible cases from Enterprise and ICS–is helpful to foresee future scenarios and protect organizations based upon robust and abundant data. Additionally, as new IT technologies such as virtualization or cloud services are adopted by OT organizations and implemented in products from original equipment manufacturers, the knowledge base will require flexibility to explain future threats. Adapting ATT&CK for ICS to the novelty of future ICS incidents enhances the knowledge base’s long-term viability across the industry. This can be accomplished by merging ATT&CK for Enterprise and ICS, as the Enterprise techniques are readily available as future, theoretical ICS technique categories.
A Hybrid ATT&CK Matrix Visualization for OT Security Incidents
To address these observations, Mandiant and MITRE have been exploring ways of visualizing the Enterprise and ICS ATT&CK knowledge bases together as a single matrix visualization. A mixed visualization offers a way for users to track and analyze the full range of tactics and techniques that are present during all stages of the OT Targeted Attack Lifecycle. Another benefit is that a hybrid ATT&CK matrix visualization will help defenders portray future OT incidents that employ tactics and techniques beyond what has currently been observed in the wild. Figure 3 shows our perception of this hybrid visualization that incorporates TTPs from both the Enterprise and ICS ATT&CK knowledge bases into a single matrix. (We note that the tactics presented in the matrix are not arranged in chronological order and do not reflect the temporality of an incident).
This visualization of the hybrid ATT&CK matrix shows in gray the novel tactics and techniques from ATT&CK for ICS, which were placed within the ATT&CK for Enterprise matrix. It shows in blue the overlapping techniques found in both the Enterprise and ICS matrices. The visualization addresses three concerns:
· It presents a holistic view of an incident involving both ICS and Enterprise tactics and techniques throughout the attack lifecycle.
· It eliminates tactic and technique overlaps between the two knowledge bases, for example by combining Defense Evasion techniques into a single tactic.
· It differentiates the abstraction level of techniques contained in the impact tactic categories of both the ATT&CK for Enterprise and ICS knowledge bases.
The separation of the Enterprise Impact and ICS Impact tactics responds to the need to communicate the different abstraction levels of both knowledge bases. While Enterprise Impact focuses on how adversaries impact the integrity or availability of systems and organizations via attacks on IT platforms (e.g. Windows, Linux, etc.), ICS Impact focuses specifically on how attackers impact ICS operations. When analyzing an incident from the scope of the hybrid ATT&CK matrix visualization, it is possible to observe how an attacker can cause ICS impacts directly through an Enterprise impact, such as how Data Encrypted for Impact (T1486) could cause Loss of View (T0829).
As threat actors do not respect theoretical boundaries between IT and ICS when moving across OT networks, the hybrid visualization is based on the concept of intermediary systems as a connector to visualize and communicate the full picture we observe during the OT Targeted Attack Lifecycle. This results in more structured and complete data pertaining to threat actor behaviors. The joint analysis of Enterprise and ICS TTPs following this structure can be especially useful for supporting a use case MITRE defines as Cyber Threat Intelligence Enrichment. The visualization also accounts for different types of scenarios where actors willingly or unwillingly impact ICS assets at any point during their intrusions. Additional benefits can spill across other ATT&CK use cases such as:
· Adversary Emulation: by outlining paths followed by sophisticated actors involved in long campaigns for IT and OT targeting.
· Red Teaming: by having access to comprehensive attack scenarios to test organizations’ security not only based on what has happened but what could happen in the future.
· Behavioral Analytics Development: by identifying risky behavioral patterns in the intersection between OT intermediary systems and ICS.
· Defensive Gap Assessment: by identifying the precise lack of defenses and visibility that threat actors can and have leveraged to interact with different types of systems.
Refining the Hybrid ATT&CK Matrix Visualization for an OT Environment
The hybrid ATT&CK matrix visualization represents a simple solution for holistic analysis of incidents leveraging components from both knowledge bases. The main benefits of such visualization are that it is capable of portraying the full range of tactics and techniques an actor would use across the OT Targeted Attack Lifecycle, and that it also accounts for future incidents that we may not have thought about. However, there is also value in thinking about other alternatives for addressing our concerns — for example, to expand ATT&CK for ICS to reflect everything that could happen in an OT environment.
The main option Mandiant and MITRE evaluated was to identify which of all ATT&CK for Enterprise techniques could feasibly impact intermediary systems interacting with ICS and define alternatives to handle overlaps between both knowledge bases. We particularly analyzed the possibility of making this selection based on type of assets (e.g. OS and software applications) that are likely to be present in an OT network.
Although the idea sounds appealing, our initial analysis suggests that shortlisting ATT&CK for Enterprise techniques that apply to OT intermediary systems may be feasible but would result in limited benefits. The ATT&CK for Enterprise site separates the 184 current techniques into a few different platforms. Table 1 presents these platforms and their distribution.
· Close to 96 percent of the techniques included in the enterprise knowledge base are applicable to Windows devices, and close to half apply for Linux. Considering that most intermediary systems are based on these two operating systems, the feasible reduction of techniques applicable to OT is quite low.
· Devices based on macOS are rare in OT environments, however, we highlight most of the techniques for affecting these devices match with others observed in Windows and Linux. Additionally, we cannot discard the possibility of at least a few asset owners using products based on macOS.
· Cloud products are also rare in industrial environments. However, it is still possible to find them in business applications such as manufacturing execution systems (MES), building management systems (BMS) application backends, or other systems for data storage. Major vendors such as Microsoft and Amazon have recently started offering cloud products, for example, for organizations in energy and utilities. Another example is Microsoft Office 365 suite, which although not critical for production environments, is likely present in at least a few workstations. As a result, we cannot entirely discard cloud infrastructure as a target for future attacks to OT.
Vouching for a Hybrid Visualization to Holistically Approach OT Security
The hybrid ATT&CK matrix visualization can address the need to consider intermediary systems to analyze and understand OT security incidents. While it does not seek to reinvent the wheel by significantly modifying the structure of ATT&CK for Enterprise or ICS, it suggests a way to visualize both sets of tactics and techniques to reflect the full array of present and future threat actor behaviors across the OT Targeted Attack Lifecycle. The hybrid ATT&CK matrix visualization has the capability to reflect some of the most sophisticated OT attack scenarios, as well as fairly simple threat activity that would otherwise remain unobserved.
As ATT&CK for ICS continues to mature and becomes more broadly adopted by the industry, Mandiant hopes that this joint analysis will support MITRE as they continue to build upon the ATT&CK knowledge bases to support our common goal: defending OT networks. Given that attackers do not respect any theoretical boundaries between enterprise or ICS assets, we are convinced that understanding adversary behaviors requires a comprehensive, holistic approach.
The hybrid ATT&CK matrix visualization .xls can be downloaded here
©2020 The MITRE Corporation. ALL RIGHTS RESERVED. Approved for public release. Distribution unlimited 19–03307–6.
In Pursuit of a Gestalt Visualization: Merging MITRE ATT&CK® for Enterprise and ICS to Communicate was originally published in MITRE ATT&CK® on Medium, where people are continuing the conversation by highlighting and responding to this story.
