APT Emulation Theory

This post is going to dive into purple teaming and detection testing again, however this time trying to emulating a very specific threat. The goal here is to verify and improve coverage of blue team detection and response models against a specific threat actor or group. Due to the threat specific nature of this emulation it can requires a ton of research and planning. The MITRE ATT&CK Framework is amazing for listing out the various tactics and techniques, but sometimes it doesn't go deep enough into explicit procedures. I'm going to briefly cover some of these short-comings in this post, such that if you are doing proper adversary emulation you can go deep enough. Terminology is key here, so it's important to get our definitions for tactics, techniques, and procedures clear up front. Adversary emulation will allow you to dig deeper into the specific procedures your threat group employs, not just the tactics and techniques highlighted in the majority of the ATT&CK framework. Once you understand your target threat groups specific procedures you can fan out within the techniques from there, as a starting point. I'm going to keep this at a high level and not cover setting up your testing environments or logging, to focus on the theory of threat emulation.

For the reason stated above, I find a lot of the attacker emulation tools don't go deep enough into emulating specific groups techniques and procedures. Many of these automated threat emulation tools emulate similar techniques, but often don't make the distinction of getting the procedures correct. This can give you a false sense of coverage in regards to detecting specific threats techniques. In practice I tested out MITRE's own CALDERA, which left a lot to be desired in terms of implementation, technique coverage, and specific threat emulation capabilities. Don't get me wrong, it helps to have repeatable tests and charted baselines, which is why I really like the ATT&CK navigator. But I often find myself setting up my own spread sheets, and keeping track of my own tests outside of ATT&CK, despite using it as a common language. This level of depth makes the independent research invaluable. You really need to dive into the reports and malware of the target threat group to do proper emulation in my opinion. By reversing the malware or reading the reports we can get a deeper look at the explicit procedures that are carried out.  Here is an amazing collection of threat intel reports, that can help you dive into specific operations, tools, malware families, and procedures used.

Once you have the basic procedures of your target threat group down, my previous post on the Johari Window and detection testing applies.That is to say, we want to emulate the specific procedures and techniques they employ, common variations within these techniques, and some potential evolutions of these techniques based on their tactics. I tend to follow my previous philosophies on record keeping in terms of prevention, visibility, detection, response, and containment times, in an effort to improve 1 - 10 - 60 times, however I don't often ramp up to blind testing here as the goal is to improve detection coverage. If you can automate this collection of metrics all the better! I've been enjoying using this VECTR platform for tracking variations and test cases, along with tracking response times.

Emulation and implementation is still a crucial step. I'm not denouncing these automated emulation tools, I'm just calling for the proper depth of emulation. Overall I suggest emulating with open source to save time, and you can piece-meal procedures and techniques together to create actor "phases" or "kill-chains". Gscript was built with these ideas in mind, so I use this a lot in my threat emulation, to iron out specific procedures and then bundle them up into larger, more contextual malware and automate the kill chain. I've made a decent effort to map many of my example gscripts back to the ATT&CK framework to help others, and I will gladly accept pull requests for more techniques! All of that said, threat emulation still often involves hacking on some custom tools, or at least custom scripting to emulate the specific procedures you find your target threat group using. Often, your emulating an APT group, which will be known for clandestine malware and custom/signature techniques.

Essentially, what I am calling for here is understanding the exact procedures of the threat actor your emulating, not just the tactics and techniques. This often involves extra research, and may require deeper documentation than the ATT&CK framework has. Don't get me wrong, the ATT&CK framework is amazing, but often generalizes a specific threat's procedures under broader techniques. The MITRE red teams had to put this same research in while creating their adversary emulation plan for APT3, which shows how valuable it is. Below is an amazing presentation where you can hear the MITRE red teams talking about these similar philosophies: