An Alternative Way of Using MITRE ATT&CK® for Threat Hunting and Detection

MITRE ATT&CK framework has been widely adopted by the industry, and almost everyone counts on it. Unfortunately, however, many people use the framework in a way that proper threat detection coverage is never possible, and the way they use the framework is not proactive enough. This post covers some critical aspects of the MITRE ATT&CK framework and provides an alternative way of using the framework for better threat detection coverage.

Never forget: MITRE ATT&CK is not a complete framework

MITRE ATT&CK framework is built upon adversary intel coming from public incident reports. Unfortunately, only a small portion of incidents are reported publicly. Although the intel coming from these reports might cover most of the TTPs, full coverage is not possible. If you are trying to “cover the framework”, you are trying to cover something that doesn’t cover everything. Even if the framework covers all TTPs, full coverage of the TTPs is not technically possible.

Keep in mind: MITRE ATT&CK is not current

Threat intel coming from incident reports is usually weeks or months old. When you receive a threat intel, you are probably looking at the past. How can you be proactive by looking at the past if adversaries have lots of options for changing the way they execute their attacks?

Ask yourself: What is the ultimate goal?

Are you trying to detect a threat? Or, are you trying to detect all TTPs in the framework? If detecting only one TTP of a threat is enough for detecting the threat itself, do you have to detect all TTPs?

Avoid: Focusing only on the Procedures

There are few tactics, hundreds of techniques, and probably thousands of procedures. We keep seeing new ways of executing the same tactic/technique every day. Considering the fact that the intel we receive is quite old, focusing on the procedures is like playing the whack-a-mole and may not be a proactive approach.

Doing More with Less

Although there are several procedures for a technique, the outcome is usually the same. The same applies to the tactics as well. For example:

• The majority of the Persistence techniques result in network communication.
• Initial access usually results in unusual process execution chains. In fact, process execution chain analysis can cover a lot of techniques/tactics.

If our main goal is to detect threats instead of covering a framework, we can generate chains of activities like above and achieve pretty good coverage of tactics without having to detect every single technique or procedure.

In addition, since it is enough to detect only one tactic of a threat, we can select one or two(maybe three) of the most common tactics and try to cover them as much as possible. 90% coverage of Command and Control vs. 35% coverage of all techniques; Which one would you choose? (You can still achieve a good overall coverage by covering 35% of each tactic in practice, but not in theory)

If you prefer having a proper coverage of few tactics, you can choose:

1. Initial Access: easy to detect with process tree analysis
2. Lateral Movement: can easily be detected with logon anomalies
3. Command and Control: high coverage is possible with statistical analysis

Of course, this doesn’t mean that you should do nothing for other tactics. The point is to have high coverage of at least one tactic.

I’ve already provided ways of detecting these tactics on the behavior level:

Enterprise Scale Threat Hunting with Process Tree Analysis

Building a Custom UEBA with KQL to Hunt for Lateral Movement

Implementing RITA in Azure Sentinel using KQL

MITRE ATT&CK is a knowledge base of adversary tactics and techniques based on real-world observations. Use it as a knowledge base to analyze the techniques in the context of an attack. Stop seeing it as something to cover. You need to cover risks and threats, not the framework.

Happy hunting