Blog Post

Microsoft Security Blog
3 MIN READ

Introducing the Azure Threat Research Matrix

hausec's avatar
hausec
Icon for Microsoft rankMicrosoft
Aug 03, 2022

When performing an offensive security assessment, it’s common to find the assessment team attribute their actions to the MITRE ATT&CK knowledge base so that high-level stakeholders can visually see what techniques were successful and administrators & defenders can understand the techniques that were performed in order to remediate or defend against them in the future. However, the commonly utilized MITRE knowledge base lacks formal documentation of Azure or AzureAD-related tactics, techniques, or procedures (TTPs) that assessment teams can attribute to. Over the past year, Microsoft has worked with some of the top Azure security researchers to create the Azure Threat Research Matrix (ATRM), a matrix that provides details around the tactics & techniques a potential adversary may use to compromise an Azure Resource or Azure Active Directory.

 

The Azure Threat Research Matrix (ATRM), is a knowledge base built to document known TTPs within Azure and Azure AD. The goal of the ATRM is twofold:

  1. To give security professionals an easily viewable framework to better visualize TTPs within Azure & Azure AD.
  2. To educate professionals about the potential configuration risks that accompany Azure & Azure AD when not following best practices.

Scope & Intent

The ATRM is primarily focused on AzureAD and Azure Resource TTPs. Due to the nature of AzureAD being used by other products, such as M365, occasionally it is necessary to include techniques or technique details that also pertain to other products. An example is AZT303 - Managed Device Scripting, which documents abusing InTune, which is integrated with AzureAD, to execute scripts on devices. Additionally, there are some AzureAD techniques (specifically around hybrid-joined devices) that are not included due to that technique already being present in MITRE ATT&CK. The intent of the ATRM is not to replace MITRE ATT&CK, but to rather be an alternative for pure Azure Resource & AzureAD TTPs. However, we would like feedback on this decision from the community!

 

The additional purpose of the ATRM is to educate readers on the potential of Azure-based tactics, techniques, and procedures (TTPs). Commands that relate to a technique are added with the intention of defenders building alerts on those commands. While the commands are also listed to show how to abuse a given technique, certain parts are omitted or obfuscated to prevent malicious abuse.  

Walkthrough of the ATRM Structure

In order for security professionals to find ATRM helpful in understanding potential risks, it is important to first understand the layout and content within the matrix.

The top row designates the tactic, each sequentially having an ID starting with Reconnaissance at “AZT1”.

 

Figure 1: The top line represents the tactics and the columns represent the techniques that pertain to the tactic.

 

When clicking on a specific tactic, it will bring you to a list of techniques and sub-techniques associated with that tactic, with a short description.

 

Figure 2: Part of the page for the 'Execution' tactic.

 

Clicking on the specific ID associated with the technique will bring you to the page on that technique or sub-technique.

 

 Figure 3: The page for a sub-technique, AZT301.6 - Virtual Machine Scripting: Vmss Run Command.

 

The technique/sub-technique specific pages have several key topics of information.

  • Resource: The resource(s) that the technique effects
  • Actions: What resource provider operation actions are required to utilize the technique
  • Examples of commands to utilize the technique, including using the portal
  • Any potential detections
  • Additional Resources

The Azure Threat Research Matrix is meant to be product-agnostic, meaning specific detection queries are for technologies within Azure by default and not an additional, paid solution.

 

Community Collaboration

Over the past several months, we’ve collaborated with some of the top researchers in the Azure security community to put together the TTPs within the matrix as it is released today. Their contributions have been extremely helpful and are on the list of acknowledgments here. One of the intended goals of the ATRM is to be as comprehensive as possible. With the hundreds of services and offerings within Azure, it’s difficult for one person to know every potential TTP within Azure and Azure AD. While internally at Microsoft we have dedicated research teams whose jobs are to research the potential abuse scenarios within Azure & Azure AD, we recognize that the community also has a large contribution to the security of our products. With this in mind, we openly invite feedback on the ATRM, from new techniques to additional data added, we would love to hear the greater security community’s input. The Azure Threat Research Matrix is being released under the MIT license and hosted on GitHub, which will openly welcome pull requests and issues.

Updated Aug 03, 2022
Version 2.0
  • vanvleet's avatar
    vanvleet
    Copper Contributor

    This is terrific, thank you for putting it together. It's nice to have the vendor publish a threat matrix for their product, I hope others follow suit!

     

    To those who are making comments about splintering from Mitre's matrix, Mitre's matrix was designed for intelligence uses, and there are design decisions (only publishing when there's documented evidence that an attacker has used it) that make sense in that context, but do not work for other cyber security needs. I think intel might be the ONLY cyber security discipline that has the luxury of waiting until a technique has been demonstrably used. For threat detection purposes (my field of expertise), we cannot wait to build defenses against a technique. That would be like requiring a sacrificial lamb for every technique: we won't document it until someone's network has been publicly breached by it. Who wants to be the lamb?!? Once it's proven a technique WORKS, we need to get defenses in place, SPECIFICALLY so that we've done it before threat actors start using it. So, we need threat matrices that are more specific and more flexible than ATT&CK has proven to be. Personally, I think it's time for the community to create an Open Threat Matrix, because I agree that one numbering system would be ideal, but Mitre's ATT&CK isn't the solution for all of us.

  • FrancescoFaenzi I think the differences are quite obvious when you compare the two; the MITRE matrix for AAD is very high level and does not go into specificities, plus the techniques link back to the on-prem technique when AAD detections and ADDS detections are handled very differently. In addition, ATRM covers Azure resource techniques where MITRE doesn't. The reasoning behind this decision was explained in the article.

  • FrancescoFaenzi's avatar
    FrancescoFaenzi
    Copper Contributor

    Awesome … but what about these

     

    https://attack.mitre.org/matrices/enterprise/cloud/azuread/

    https://attack.mitre.org/matrices/enterprise/cloud/office365/

    What’s the difference/ what will it be?

    It’s about which TTPs are covered? I.e Mitre converse those belonging to APT and you cover the rest?

    Are you considering an all-in about TTPs? I.e those from MITRE and yours?

     

    It’s super important IMO to have one and only one MITRE like matrix for Azure & friends

  • SvenV_'s avatar
    SvenV_
    Brass Contributor

    As an Intune/Endpoint Management guy, please write Intune not as if it is an Apple product :lol::sad: But great job on this, I have shared this with our Security team. 

  • GarryU Thank you! I definitely understand that having separate data sheets amongst the many different companies is a pain to keep track of and can be annoying. There's a few reasons why we've made this:

     

    1. We've had several teams approach MITRE for a collaboration both in regards to Azure/AAD and other things, and MITRE's standpoint is that they prefer to not integrate TTPs that haven't been documented being used by an APT. This makes sense from a general standpoint as some trivial on-prem attacks would clutter their matrix, but this leads to point #2...

    2. MITRE ATT&CK Enterprise is purposely not specific to a certain technology. E.g. you can take a technique and apply it to Windows and Linux. The ATRM is very specific in that it only lists TTPs relating to purely Azure or AzureAD. Because of this, we can then include techniques whether they're proven to be abused by APTs or not.

    3. We felt as though since we own Azure/AAD, it is our responsibility to inform of the potential risks when using the platform. Nothing out of the box about Azure is inherently vulnerable, but there's some very easy configuration slip-ups that can have a detrimental impact on a tenant. Thus, we figured there should be no one better than to document on potential defensive suggestions + best practices than us.

     

    Hopefully that answered your question!

  • GarryU's avatar
    GarryU
    Copper Contributor

    Hi all,

    This is some really good work. Rather than spin-off a separate listing of TTPs can it not be added to Mitre Att&ck please. If things aren’t quite right, can we all work together?

     

    CyberSec is complex enough without everyone pulling in different directions. This is already the case with all the other IT type frameworks from ITIL, NIST, SANS, COBIT and ISO 27001.

     

    let’s work together!

    thanks for listening