In my second post of this series, I will cover how to shore up your defenses with the help of the MITRE ATT&CK Navigator.

A short recap

A few weeks ago I talked about modelling intelligence reports using the ATT&CK Navigator.

One of the largest reasons for collecting intelligence is to ensure you’re defending against them.

In this post I want to show you how intelligence can be used to improve your defensive security posture with the help of the MITRE ATT&CK Navigator.

ATT&CK Data Sources

As I wrote in my previous post covering some of the basics of MITRE ATT&CK;

Data Sources (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 (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 has a Relationship to a Techniques.

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

Let’s think about this practically…

If “My Organisation” is using Active Directory, I will be ingesting AD logs into my SIEM for detection.

These logs cover Active Directory Credential Requests which means I could, with the right detection rules, be able to detect the Techniques shown above. 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).

To better document this coverage, one of the first things “My Organisation” could do is create a new layer with the Techniques associated to all of the Data Sources currently being ingested into our SIEM.

MITRE ATT&CK Navigator Layer Information

I showed you how to create a new layer in my previous post. To do this for Techniques associated with Data Sources; search for the Data Source, find the correct Data Source(s), and click select.

Here’s a dummy .json file I’ll use for the Techniques related to the Data Sources of “My Organisation” (selected at random to illustrate the concept).

Mapping Intelligence Reports to Data Sources being monitored

Continuing with the example, now imagine I am analysing APT 39 and want to ensure “My Organisation” is prepared.

Here is the ATT&CK Navigator layer .json created for it.

MITRE ATT&CK Navigator Layer Information

Above, I’ve overlaid the APT 39 Techniques against the Techniques monitored by the Data Sources being monitored by “My 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 we won’t be able to detect.

Again, it’s important to stress here that the Techniques in green do not mean we can detect this part of an attack from APT 39. It just means “My Organisation” is collecting logs that are able to detect that particular stage of the attack being carried out by APT 39. It is an active detection rule to detect that part of the attack that determines if it can be detected (again, more on that later).

However, before we get into that, let’s take a Technique in red (related to Data Sources that we are not monitoring) so that I can tell the SIEM admins at “My Organisation” to start ingesting the associated logs;

MITRE ATT&CK Navigator Lookup Technique

To uncover the Data Sources where we have blindspots I can right click on the Techniques in red, and select view Technique.

MITRE ATT&CK Navigator Techniques

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 “My Organisation” starts monitoring logs that contain Logon Sessions. In some cases, the Data Sources might not always be applicable because they are not applicable to an organisations environment (in which case can’t be exploited).

Detection Coverage in ATT&CK Navigator

Once we’re collecting the necessary Data Sources to detect an attack, the next step is to ensure that detection rules exist for the Technique.

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

Take this rule:

title: User Added to an Administrator's Azure AD Role
description: User Added to an Administrator's Azure AD Role
date: 2021/10/04
    product: azure
    service: activitylogs
       Operation: 'Add member to role.'
       Workload: 'AzureActiveDirectory'
           - 'Admins'
           - 'Administrator'
   condition: selection
    - PIM (Privileged Identity Management) generates this event each time 'eligible role' is enabled. 
level: medium
status: experimental
    - attack.persistence
    - attack.t1098.003

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 Techniques:

In this case, the rule covers one ATT&CK Tactic and Technique, however rules can have more than one Tactic and Technique linked to them.

MITRE ATT&CK Navigator Detection Rule

Adding ATT&CK data to your rules makes it easy to create layers for each of them. These 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 add the rule metadata (including SIEM Rules link) to the ATT&CK Navigator layer information.

The logsource part of the detection rule can also be directly tied to ATT&CK Data Sources which helps to perform the task of linking ATT&CK data 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).

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 T1098.003: Additional Cloud Roles 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 contact the Active Directory admins at “My Organisation” to check if this detection represents a valid account change. I can also ensure the correct procedures are in place to ensure such changes can only be made with proper reviewed.

Putting it all together

You can now create new layers in the ATT&CK Navigator to model:

  • threat intelligence reports
  • existing ATT&CK data (e.g. Threat Groups, Software, Data Sources, Mitigations)
  • detection coverage (and use Mitigation information when rules are triggered)

And then compare all of these layers to identify gaps in your intelligence collection and/or detection coverage.

Join the Signals Corps on Discord

Join our public community of intelligence analysts and researchers sharing new content hourly.



Turn any blog into structured threat intelligence.


Stixify. Extract machine readable intelligence from unstructured data.

Extract machine readable intelligence from unstructured data.



Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.

SIEM Rules

SIEM Rules. Your detection engineering database.

View, modify, and deploy SIEM rules for threat hunting.