Getting started with MITRE ATT&CK Navigator

The MITRE ATT&CK Navigator is a web-based tool for annotating and exploring the MITRE ATT&CK framework. It is very useful for both offensive and defensive activities.

Here is a nice overview of the ATT&CK Navigator presented by MITRE:

Install ATT&CK Navigator

To make it easy to get started, there is a public instance running here that you can use.

You can also install the ATT&CK Navigator on your own machine.

To do this you will need Node and Angular installed to run. Once installed…

git clone https://github.com/mitre-attack/attack-navigator
cd attack-navigator/nav-app
npm install
ng serve

Now open up a browser and navigate to localhost:4200, you should see the

Model an intelligence report

For this first walkthrough I will use this post from the brilliant UNIT-42; Popping Eagle: How We Leveraged Global Analytics to Discover a Sophisticated Threat Actor to model the information against ATT&CK Tactics and Techniques.

The Unit 42 team have made it easy for us by detailing the ATT&CK Techniques and Sub-Techniques about the Popping Eagle Malware at the bottom of the post.

For reference, they are:

I will use a layer in ATT&CK Navigator to represent this report.

To do this I first, create a new layer choosing the appropriate ATT&CK Matrix. In this case that is the Enterprise domain (because the report does not mention mobile or ICS infrastructure).

When on the Matrix view, shown above, click the layer controls > layer information button and give the layer some contextual information including a title, description, and link back to the blog post (this very is useful to others viewing your layer in the future).

Now I can start adding the Techniques to the layer. This can be done in two ways; 1) by finding the Technique in the matrix, right clicking it, and select Add to Selection.

However, there is a much easier way…

Select; selection controls > search & multiselect.

Now it is possible to search and select from the results (under Techniques) to find the Techniques needed.

Once all the Techniques have been selected, you can make them more visible on the Matrix by selecting; technique controls > fill bucket. In the screenshot above, I have coloured the selected Techniques green.

It is now possible to export your layer as a .json doc by selecting; layer controls > download layer as .json.

The exported .json can then be shared and imported to other instances of the ATT&CK Navigator (or other products that support the structure of the exported .json).

Comparing intelligence reports

In many cases, you will want to compare Techniques between reports. For example to identify similarities between malware.

For this I will compare the Popping Eagle layer, with APT 39.

As you know from the previous posts, ATT&CK contains information about widely known Groups as STIX 2.1 Intrusion Set objects.

Therefore all that is needed is to create a new layer, click selection controls > search & multiselect, and search for APT 39 under “Threat Groups”. Clicking select will select all Techniques related to APT 39 which can then be coloured in the same way as before.

Now I have two layers. Before being able to compare the layers, I first need to assign each layer a score.

A score is a numeric value assigned to a Technique. The meaning or interpretation of scores is completely up to the user user - the Navigator simply visualizes the matrix based on any scores you have assigned.

As you can see there are a few ways scoring can be used. For this use-case I will assign a score of 1 to the Popping Eagle layer and a score of 2 for the APT 39 layer. The actual value of the score is irrelevant (in this scenario, but can be very useful for others) as long as they are different and within the supported range of 0 - 100.

Now I have assigned a score to each layer, I can create a new layer from the two layers.

Looking at the top tabs in the screenshot above you can see Popping Eagle has been assigned ID a and APT 39 b. Therefore the score expression needed is a + b. Now click create.

I have added a legend in the bottom right of my newly created layer; Popping Eagle vs APT 39.

  • Yellow shows Techniques unique to APT 39,
  • Red shows Techniques unique to Popping Eagle,
  • and Green shows Techniques used by both.

In this case, there is quite a difference between the Techniques Popping Eagle and APT39… so we might infer APT39 don’t use Popping Eagle as it is not aligned with their known behaviours.

There are many other uses for comparing layers, including;

  • tracking the evolution of an actor over time as new Techniques are discovered or the actor changes their approach
  • comparing known intelligence collected on the same campaign from different sources so that you can have the most comprehensive information available in one place
  • identifying gaps between Techniques that you have intelligence about and Techniques you are detecting for in your SIEM (or whatever) to identify blindspots in your defenses, which brings me on to…

Mapping to internal logs

One of the largest reasons for collecting intelligence is to ensure you are defending against it.

As covered in the last post in this tutorial, the ATT&CK data model contains the following Object types;

Data Sources (STIX 2.1 object: x-mitre-data-source): Data sources represent the various subjects/topics of information that can be collected by sensors/logs. Tracked using ID in format: DSNNNN (e.g. DS0029 - Network Traffic)

Data Component (STIX 2.1 object: x-mitre-data-component): Data components are children of Data Sources. Data Components identify specific properties/values of a data source relevant to detecting a given ATT&CK technique or sub-technique. For example, Network Traffic is the Data Source and Remote Services is one of the Data Components linked to it.

Each Data Component Object has a Relationship to one or more Technique.

For example the Data Source DS0026: Active Directory has a Data component Active Directory Credential Request which is linked to the following Techniques;

This is very useful information to have.

For example, if an organisation is using Active Directory, it is very likely their SIEM is ingesting Active Directory logs for detection.

Assuming the logs cover Active Directory Credential Requests, with the right detection rules, the organisation would be able to detect the Techniques shown above.

To better document this coverage of Data Sources flowing into the SIEM, the Organisation could create a new layer covering all the Techniques associated to the Data Sources being monitored.

To create a new layer for Techniques associated with Data Sources; search for the Data Source, find the correct Data Source(s), and click select.

Mapping Intelligence Reports to Data Sources being monitored

Continuing with the example, now imagine the organisation is analysing APT 39 and wants to ensure they are prepared.

Above, I’ve overlaid a layer containing APT 39 Techniques against the Techniques linked to Data Source being monitored by the organisation.

As you can see in the legend:

  • green: represents Techniques related to Data Sources being monitored and leveraged by APT 39
  • red: represents Techniques being leveraged by APT 39 but not Techniques related to Data Sources being monitored, and finally,
  • orange: represents Techniques related to Data Sources being monitored but not leveraged by APT 39.

In short, the Techniques in red indicate those used by APT 39 the organisation will not be able to detect.

If my organisation suspects we might be a target of this group, we might want to consider our detection rules.

Of course, the ability to detect the Techniques depends on whether the right detection rules are in place for the specific way the threat is exploiting the Technique (more on that in a bit).

However, before I get into that, let us take a Technique in red (related to Data Sources that I am not monitoring) and see what Data Sources are linked to it (so that the organisation can start ingesting them, should they be relevant to their network);

To uncover the Data Sources where there are blindspots, right click on the Techniques in red, and select view Technique.

This opens up the MITRE ATT&CK website on the Technique where the associated Data Sources are listed.

Take for example the Technique T1078: Valid Accounts highlighted in red. One of the related Data Sources is DS0028: Logon Session.

Therefore, it is important the organisation considers monitoring logs that contain Logon Sessions. In some cases, the Data Sources might not always be applicable, for example, if you are not using Active Directory (in which case cannot be exploited).

Detection Coverage in ATT&CK Navigator

Once you are collecting the necessary Data Sources to detect an attack, the next step is to ensure that detection rules exist for the Techniques.

In a similar way to before, this is just a process of taking a live detection rule, mapping it the relevant ATT&CK Techniques, and then modelling these on the ATT&CK Navigator.

Take this Sigma Rule:

It monitors azure activitylogs for Add member to role. operations, where the properties are upgraded to Administrator or Admins.

In the tags section of the rule the associated ATT&CK Tactic is TA003: Persistence and Sub-Technique T1098.003: Account Manipulation.Additional Cloud Roles

Adding ATT&CK data to your rules makes it easy to create layers for each of them in the Navigator.

The logsource part of the detection rule can also be directly tied to ATT&CK Data Source Objects which helps to perform the initial task of linking ATT&CK Techniques to a rule.

In this example the relevant Data Source is DS0026: Active Directory > Active Directory Object Modification (which is linked to T1098: Account Manipulation). In this case, the creator of this rule might therefore want to add the tags -attack.ds0026.

Once complete, the layers for each rule can then be combined into a single layer displaying a complete picture of your defensive posture.

To help me keep track of all the rules I have added, I make sure the rule ID is added to each layer (under layer metadata fields).

And by associating ATT&CK Techniques to detection rules, you can also take advantage of ATT&CK Mitigations:

Course of Action (course-of-action): represent ATT&CK Mitigations. Mitigations represent security concepts and classes of technologies that can be used to prevent a technique or sub-technique from being successfully executed.

Mitigations provide defenders with ways in which they can take action during an incident when a detection rule linked to an associate Technique is triggered.

For example, if I right click the Sub-Technique T1098.003: Additional Cloud Roles I can see that is has the following ATT&CK Mitigations:

In this case M1026: Privileged Account Management is most relevant to the detection.

Assuming this rule was triggered I could use some of this information to help with remediation and improving defenses