Despite the name of this blog, I really have no idea how to design a Red Team operation. I want this post to be my exploration of how to create and execute a successful Red Team. I want to expand my own knowledge on the matter as well as share it so that I might be able to help someone else out there. While I doubt this will be the greatest resource out there, I hope you can take something away from it.
Let's start at the beginning. What exactly is a Red Team? This slide deck defines it in a few ways:
- Alternate analysis.
- Threat emulation and attack modeling.
- A team dedicated to adversary simulation.
The slide deck also links to this article, which states "defined loosely, red teaming is the practice of viewing a problem from an adversary or competitor’s perspective. The goal of most red teams is to enhance decision making, either by specifying the adversary’s preferences and strategies or by simply acting as a devil’s advocate." So the idea is that a Red Team imitates actual attackers in order to test (and improve) the current controls in place. Through playing the role of the adversary, the overall security team can be better prepared for an actual event and/or better protect the organization from adversaries. An important thing to note here is that the threat emulation should be reflective of the actual threats an organization faces. An Internet Service Provider is at a higher risk of a complex attack vs a fast food chain, for example.
Red vs Blue ...or not?
Another concept I'd like to discuss is this mentality that these Red Team operations are an "us vs them" scenario. Instead, the idea is to improve the security of an organization. A little healthy competitiveness is fine, but we really are part of the same team. We are working together towards a common goal. At one point, I was frustrated that a new control was being put in place after my first (very successful) exercise. They took the findings and noticed a significant gap in the Blue Team's ability to prevent, detect, or deter an adversary. I should instead look at this new control as a huge benefit to the organization and even to myself. This new control will better protect the company and will also increase the challenge for the Red Team in future exercises. Implementation of this control is (at least partially) influenced by the Red Team exercise. This really shows how Red and Blue are working together.
Additionally, I want to look at what counts as success in a Red Team operation. From my naive point of view, it's only a success if the Red Team can meet their objective efficiently and quietly. That's not even the ideal scenario if you think about it. Instead, success can be defined by the takeaways of the operation. Was the objective met? If so, how difficult was it? Were the controls in place effective enough to stop an actual adversary? It's not about who "won" its about the current and future state of security.
I previously mentioned that my first exercise was very successful. However, it was really only successful in that the organization knows what work needs to be done. There actually were several things wrong with it. First off, it was very poorly planned. The Red Team stumbled upon a critical finding from a vulnerability scan and ran with it. There was no pre-exercise meeting, which meant there was no structured time frame, no rules of engagement, and really no actual objective beyond "pwn all the things!" The takeaway from this is that I need to better understand what a Red Team operation should look like, so the execution can be improved. Of course, like most things, its going to be an iterative process. If there is a small improvement each time, it can be counted as a successful operation.
I want this post to be more about the concepts and less about the technical side of things, so the below image (that I got from this awesome resource) quickly demonstrates what the process should look like.
However, a key component is missing from the graphic.
The very first step of an operation should be planning. First off, decide who should be "in the know" for the operation. Management is a given, but maybe a member of the Blue Team? Maybe not. For example, if the goal is to test the SOC's incident response, their management could be involved in the planning. Another key part of planning is determining an objective. What is it that you're testing for? Why does this need to be tested? Next, determine the scope and rules of engagement. What is allowed? Is anything off-limits? Does the operation end if the Blue Team successfully detects/stops the Red Team? Answer these questions (and probably some others that I've missed) before any part of the operation happens.
Another awesome resource that can be used for planning is MITRE ATT&CK. Straight from their site, it "is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations." It maps out common tactics used by real adversaries and can be used as a source to craft the operation. They have a wealth of information about these operations including an entire pre-engagement matrix. The PRE-ATT&CK matrix covers things like defining priorities, selecting targets, information gathering, and establishing infrastructure. Then they have the main Enterprise Matrix, which covers all the steps in the above lifecyle. Each technique has a link which defines the technique and gives examples of real attacks that used the technique. It also has sections on mitigation and detection which makes it a perfect resource for the whole team.
Hopefully you've taken something away from this exploration. Thank you for reading. Never stop learning and improving!