Data Sources, Containers, Cloud, and More: What’s New in ATT&CK v9?

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?

• Updated: A revamp of data sources (Episode 1 of 2)
• Updated: Some refreshes to macOS techniques
• New: Consolidation of IaaS platforms
• New: The Google Workspace platform
• New: ATT&CK for Containers (and not the kind on boats)

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.

Making Sense of the New Data Sources: Episode I

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?”

Redefining Data Sources

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!

What’s New with Mac

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.

New and Improved Cloud

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.

Container Updates (that don’t include the Suez Canal)

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.

What’s Next

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.

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.

2021 Roadmap

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.

In Closing

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.

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:

• Accessibility — “used to assist users with disabilities in using Android devices and apps”, but also abused by malicious applications to capture sensitive information from the device screen (T1513) or maliciously inject input to mimic user clicks (T1516)
• Read Notifications — abused by malicious applications to read Android OS notifications containing sensitive data such as one-time authentication codes sent over SMS (T1517)
• Draw over Other Apps (also known as SYSTEM_ALERT_WINDOW) — abused by malicious applications to display prompts on top of other applications to capture sensitive information such as account credentials (T1411)
• Device Administrator — abused by malicious applications to perform administrative operations on the device such as wiping the device contents (T1447)
• Input Method — abused by malicious applications to register as a device keyboard and capture user keystrokes (T1417)

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:

• All files access
• Battery optimization
• Do Not Disturb access
• Modify system settings
• Adaptive Notifications
• Picture-in-picture
• Premium SMS access
• Unrestricted data
• Install unknown apps
• Usage access
• VR helper services
• Wi-Fi control

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.

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.

UNC2452 Technique Analysis

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:

• New procedural example variations of techniques, such as T1070 Indicator Removal on Host including UNC2452 reverting changes to legitimate utilities and tasks after abuse and T1098.002 Account Manipulation: Exchange Email Delegate Permissions including them granting additional permissions to the target Application or Service Principal to read mail content from Exchange Online via Microsoft Graph or Outlook REST
• Expansion of current technique scoping, such as the T1098.001 Account Manipulation: Additional Cloud Credentials description being amended to include adding credentials to legitimate OAuth Applications as well as Service Principals in Azure AD
• New (sub-)techniques not previously published within ATT&CK, such as those necessary to describe UNC2452 forging web cookies (T1606.001 Forge Web Credentials: Web Cookies) and SAML tokens (T1606.002 Forge Web Credentials: SAML Tokens) via stolen secret keys and compromised signing certificates (T1552.004 Unsecured Credentials: Private Keys) and making malicious modifications to domain federation trust settings to include adversary owned objects (T1484.002 Domain Policy Modification: Domain Trust Modification)

New Group/Software Entries

Along with new/updated techniques we have added several new group and software entries to ATT&CK including:

• A new group representing the threat group responsible for the intrusions, added as UNC2452 with associated group names of Solorigate, StellarParticle and Dark Halo.
• New malware first spotted in this intrusion, including Sunburst, Teardrop, Sunspot, and Raindrop.
• An existing tool used in this intrusion, AdFind.

More to Come?

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.

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.

PRE-ATT&CK’s History

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.

Finishing the Merger

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:

• Technical — the behavior has something to do with electronics/computers and is not planning or human intelligence gathering.
• Visible to some defenders — the behavior is visible to a defender somewhere without requiring state-level intelligence capabilities, for example an ISP or a DNS provider.
• Evidence of adversary use — the behavior is known to have been used “in the wild” by an adversary.

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.

The PRE Platform

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.

Going Forward

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.