Incorporating MITRE ATT&CK in your Security Operations9 min read

Now I know what you’re probably thinking, oh great another blog post about MITRE ATT&CK, and I get it. MITRE has taken the cybersecurity world by storm over the last 10 years, and it seems like everyone is talking about ATT&CK but not explaining how to actually use it. And, well here I am; another blog on the Internet talking about MITRE ATT&CK. Except, I want to provide some practical use cases on how I use MITRE ATT&CK. I’m certainly not the authority on all things Cybersecurity and you are free to completely disagree with me if you want, I won’t be mad. This is just my attempt to explain how I used MITRE ATT&CK when I was conducing ops; both Red Team, and Blue Team.

What is MITRE ATT&CK

No discussion on MITRE ATT&CK would be complete without a discussion on what the ATT&CK matrix actually is.

ATT&CK is a matrix of real observed techniques that adversaries use when conducting cyber operations. It consists of 14 Tactics (the top of the matrix) which are divided into two categories; pre-attack and attack. The 14 Tactics move from reconnaissance and all the way to creating an impact on the environment. Below that are over 150 Techniques and more than 200 Sub techniques.

You can think of this as divided into ‘What an adversary is trying to do’ (the Tactics) and ‘How they are going to do it’ (the techniques). This framework provides a major benefit of creating a common lexicon of descriptors for cyber-attacks. The MITRE ATT&CK Matrix also provides a granular look into each step in an attack lifecycle. The sub-techniques allow in-depth reporting to distinguish between things like an adversary using PowerShell vs. and adversary using Bash to execute their malware.

Many security products have started categorizing their alerts based on techniques listed in the MITRE ATT&CK matrix. Cybersecurity reporting has also started taking on the task of including the ATT&CK ID when discussing adversary actions. In addition to all that most EDR have started looking for specific actions an adversary takes rather than just a known bad file hash.

The Problem

The things mentioned above are important factors in cybersecurity; however, they’re largely passive ones. For the average SOC analyst does it matter that a certain attack is listed as “exploitation of remote services”? Not particularly. It’s useful to include in reports because it helps with making neat graphs and fun stats, but the analyst cares more about what the IDS is actually looking for rather than what ATT&CK ID it’s assigned.

In Incident Response the ATT&CK IDs can help responders by giving us ideas of what to look for when responding. The IDS alerted on T1059.001 (PowerShell) which now tells us as incident responders that we should be searching Windows event logs 200-500 and 4100.

Today however, I want to talk about how to use MITRE when planning for an operation; both offensive and defensive.

Defensive

A little while ago I made a post about interviewing for Hunt. In it I discussed an Adversary COA approach. I discussed creating a hunt plan based on what we believed the adversary was likely to do; what their course of action was. But how do we come up with this course of action? That is where the MITRE ATT&CK framework comes into play; and where threat intel should get involved, but that’s a topic for another day.

Whenever I was planning for Hunt operations, I would put the MITRE ATT&CK Tactics up on a whiteboard. no techniques; not yet.

Placing the ATT&CK framework up a whiteboard helped me ensure that I was accounting for every step in the chain. After placing the framework on the board, I would work with my Threat Intel team to start filling in the chart with techniques we knew the adversary was capable of.

We would then go through and eliminate techniques we knew weren’t possible in our environment. In the interview post I discussed the Data Driven Approach. This approach sought to gather as much information as possible about the environment we’re hunting in. Using the Data Driven Approach we could eliminate possibilities.

In this example we are saying that Cobalt Kitty uses T1059 (command and scripting interpreter) as one of their execution methods. Underneath that technique are eight sub-techniques. When I’m using a data driven approach, I might ask the system administrators if a Python interpreter is included in the standard desktop configuration. If the answer is no, then I might ask if users have rights to install programs (I would actually ask this question anyways). If the answer again is no, then we would be able to eliminate T1059.006 (Python) as a possible technique to hunt for.

We would iterate through this process over and over until what was left on the board was techniques that were actually viable attacks against our environment. Side note: I never removed things off the board, we only crossed them off, that way we could tell that we already address the topic.

When finished we will have a list of techniques that we suspect the adversary could use on our environment based on techniques we’ve seen them use in the past and techniques that are feasible to execute.

From there we would start generating an attack tree to plan which specific techniques we expect that adversary to use.

With this attack chain we can go one of two ways; we would either attempt to place specific capabilities where possible. For example; if we said we were looking for exploitation of remote services than we might get more specific and say that Cobalt Kitty would likely use EternalBlue as their exploit. Using our Data Driven approach we could review our documents, or ask the system administrators if the endpoints are patched against this exploit.

After coming up with as specific of an attack path as we can we then need to use our Capabilities Based approach to figure out how to deploy our sensors to collect this traffic, what logs we should pull and where we can pull them from, and where we need to deploy additional host level collectors.

This process is often referred to as “hypothesis based hunt” and MITRE ATT&CK is the core of it.

Offensive

Similar to with Hunt the MITRE ATT&CK Matrix can be used to support offensive operations (Red Teaming). I’ve written about my thoughts on CTFs before and I still hold those same thoughts now. CTFs are not a good representation of Red Teaming. Yes they can help you learn how to research a vulnerability and exploit a box but actual Red Teaming goes far beyond simply exploiting individual boxes.

The best Red Team ops I worked were where we had an actual objective to achieve that wasn’t just “get Domain Admin” or “see how far you can get”. When we were given specific objectives like “We want to see if you can get our R&D schematics” or “We want to see if you can get Ransomware on our financial systems”. These objectives are more realistic to what an adversary would actually do.

Our adversaries, not the hacktivists or script kiddies, have specific objectives they’re looking to complete. Yes it may start out as ‘just get into the network’ but it’s rarely as simple as ‘just for the lulz’. Security systems are too good in today’s world for people to just do things for the lulz. The more advanced the adversary the more likely they’re going after your company for a specific reason.

Proper Red Teaming involved trying to simulate a true adversary and find the impacts to the business. If I encrypt your customer database that would have second and third level effects in XYZ places. In the military we referred to this as Center of Gravity (CoG) analysis.

When approaching Red Teaming with this mind set it’s easy to link the MITRE ATT&CK into the planning stage of an operation. I’m not going to get into everything that went into planning a Red Team op (maybe another post), but I will explain where we used MITRE.

When planning an OP one of the first steps was to put the MITRE ATT&CK matrix up on a whiteboard. As we investigated what we knew about the environment and discovered more we would start filling in the tactics with specific techniques we could use. If we learned that the environment was running Windows then maybe we should plan for to use PowerShell for execution and PSExec for lateral movement. We can use Mimikatz for Credential Access and set malware to run in HKLM: Run Keys for persistence.

Placing the MITRE ATT&CK Matrix up on the board helped us ensure that we were planning something for each step of the operation. If we forgot to plan initial access it was very obvious to see as there would be nothing written on the board under the initial access category.

Doing this also helped us plan contingency actions for things like ‘what do we do if we get on a box and PowerShell is locked down?’.

Conclusion

I love the MITRE ATT&CK Framework. It can be incredibly useful; however, I don’t feel like we as a community do a good job of explaining ways to use it practically. We focus a lot on it’s ability to categorize and bin data but not, but that’s not the only things it can be used for.

Hopefully this post gave you some ideas about how you can employ MITRE ATT&CK in your ops.