The MITRE ATT&CK™ knowledge base framework is not only an excellent resource, it also provides the global cybersecurity community with a common language for explaining incidents and understanding how attackers operate. Incorporating it into our deception solution allows us to represent and visualize what is actually happening in a controlled and monitored environment, modeling the cyber attack in real time. Further to this, it displays information in a way we, analysts, are becoming more familiar with, giving us an increasingly thorough understanding of what the data is showing us.
Image: Threat activity modeling as TTPs. Click to enlarge.
Upon adoption and implementation of the MITRE ATT&CK™ framework, we immediately appreciate its robustness. However, it does come with a number of limitations inherent with its design. It’s important to note that many people, through sheer excitement, have high and unrealistic expectations that it will solve all problems.
This method of threat modeling involves trying to categorize very complex events that take place in a specific context, within a narrow table. Data is inevitably lost along the way, and whether this is for better or worse, that data could represent decisive factors.
The MITRE ATT&CK™ knowledge base is certainly paving the way forward for threat hunting analysts and operators. It does not matter if a sequence of several events was detected; whether a connection was observed from an internal network computer, followed by a login and the execution of a process; or if the use of a known pattern was detected, and an existing connection to another system was hijacked through an active SSH (Secure Shell) session. It’s initially clear to the analyst that a lateral movement has occurred, without knowing the exact detail. With this ability to immediately identify what’s happened, the analyst is able to focus on the most relevant data and explore more details within or around the events that the TTPs (Tactics, Techniques and Procedures) have defined.
On the other hand, there are techniques that the MITRE ATT&CK™ Matrix does not easily accommodate, and behaviors that we want to be detected and shown but that do not necessarily have a place in MITRE ATT&CK™. For example, the download and subsequent execution of a binary may be considered an interesting action we wish to detect, and may even indicate that the subsequent actions belong to a piece of software/malware and not to the human being that is messing around, but the triggering action itself may or may not have a place in the matrix.
As we ‘color cells’ by integrating behavior abstractions into MITRE ATT&CK™, the matrix defines a set of techniques we want to detect and show at a high level. Common sense tells us that the number of cells we are able to ‘color’ shows us what we are capable of detecting. This is quite misleading, as detecting a technique’s implementation does not mean detecting all possible implementations or ways of executing the same purpose. Therefore, when analyzing a coverage map showing detection capacity, we should understand that what it is actually showing us is its overall capability to detect at least one way of implementing each marked technique. What we must not do is assume that it is capable of detecting all of its various implementations.
Now we might start to think that the problem at hand is more complex than it initially seemed.
Taking a step further, and based on all agent data available as TTPs, together with data we can produce ourselves, we can come up with two possible applications:
• Crystal ball: While we monitor an attack, why not use the data available to find out what is going to happen next?
• Attribution: Who may be responsible for the attack?
It is possible to correlate events to try to determine what technique is most likely to be used next, but we must always be realistic and remember that we cannot predict the future. When attempting to solve this issue, MITRE presents different approximations, yet it’s possible that we frequently lack very useful data, such as the order in which each technique was detected, the period of time between techniques, or a record of each time that each technique was detected. Usually, the data available consists of a simple list of techniques that lacks contextual information, and this is not helpful for getting the most out of the available knowledge base.
The attribution based on Modus Operandi is also interesting, but is not completely reliable. There is plenty of information about attackers, but once again, some data is missing. Published data about an agent usually indicates what was observed during the analysis, may be limited by an NDA, and may be biased towards what the author has considered relevant – both when analyzing the incident and when publishing the report. Furthermore, the data references the attacker’s activity in a specific environment and under specific circumstances, and while some tools and techniques provide relevant data, some others depend on the specific target and the environment found during the attack. Similarly, the information typically lacks data such as the order and number of times each one occurs, in favor of including only those that are most prevalent.
With this in mind, it’s very important to be cautious when drawing conclusions using MITRE ATT&CK™, and to be able to justify why we think a particular technique is more likely to take place, or explain why we’ve applied a certain behavior attribution to a group.
We know there’s still work to be done, but the growing consensus is that we are doing things in the right way. MITRE ATT&CK™ is a project that is very much alive, continuously attracting more supporters and, as well as updating the knowledge base, the matrix is becoming an even more valuable resource for a more in depth analysis. So, we must continue to work towards obtaining data that is relevant, useful and accurate. As a community we must continue to encourage the global adoption and application of the excellent work done by MITRE, making the most of everything that’s available while always being aware that every tool and set of data we use comes with its own strengths and weaknesses.
Research on TTPs conducted by CounterCraft has been supported by funding received from Gipuzkoako Foru Aldundia – Diputación Foral de Gipuzkoa.
[1] MITRE ATT&CK Blog Finding Related ATT&CK Techniques
[2] MITRE ATT&CK Sightings
[3] Blogpost CounterCraft: How to fight threats in the modern age
Author: Mikel Gastesi, Senior Threat Intelligence Analyst