A Brief Look At Approaches To Red Team Operations

In this blog post, I will skip over talking about what red teaming is and discuss some common approaches to red teaming often used by internal corporate red teams. I will briefly mention some of the approaches and discuss some considerations of each and hopefully this will help internal red teams as they figure out and plan how they want to approach red teaming. Also of note: red teams often perform other tasks that are not listed in this blog as well…this blog just highlights different approaches specifically around red team operations.

Approach 1: A Long Running Operation

In this approach, an internal red team will spend a good amount of time planning for execution of a long running red team operation. There is no set time for how long this operation might be, but examples may include anything from a full quarter to 6 months and even up to a full year or more. With this approach, often the red team will emulate a real world adversary and plan to gain access, maintain and elevate access, bypass security controls to remain undetected, and live in the environment as long as possible en route to achieving mission objectives. This will often include having various accesses into the network with the assumption that at least one vector will be burned at some point by blue. This makes for an interesting approach to challenge mature blue teams with a realistic emulation (or simulation) of a threat actor.

Consideration: Something to keep in mind is that this approach is best utilized in environments with mature blue teams and where the basics have been covered (ex: MITRE ATT&CK matrix mappings, common TTP unit testing, etc.). On the red team side, this is also usually best for larger red teams, since running this type of op successfully will often require lots of resources (custom tooling, flexible/secure/scalable infra, etc.). So this would not be the ideal place for red teams to start, but this would be more of a north star to work towards as the blue and red teams grow together in maturity over time.

Approach 2: Linear Operations

I refer to this approach as “linear operations” due to the fact that this approach uses several different operations where a red team simulates an attacker and maintains that same attacker profile across each operation. These operations/exercises are often tightly scoped and shorter in duration (ex: anywhere from 1 week up through 1 month). An example is below:

• Op1: Red team does 2FA man in the middle phish (targeting publicly facing login portals) and tries to get access to sensitive systems/data
• Op2: Red team keeps the same TTPs from Op1 with a slight modification or introduces a new TTP (ex: adds payload-based phishing).
• Op3: Red team continues with the same goal and iterates on the same TTPs with additional modifications.

Using this approach the red team keeps the same “attacker profile” (i.e., continues being the same attacker) across each operation and seeks to demonstrate how an attacker targeting their organization would evolve over time as defenses and detections improve and force them to migrate to new TTPs. As such, the red team may opt to keep some “loot” that they gain in each op and use that data/info/access in the next op. For example, if during Op1 above the red team finds the corporate VPN client and profile then the red team may leverage that in Op2 once they gain access to credentials. This approach is an interesting approach and while it may not make sense to use this approach solely it may be useful to do this across a small handful of red team ops and see how it adds value to the blue team (i.e., hopefully it will help SIRT or threat intel with building and tracking an adversary profile, will help blue become more intimately aware of the attack path being used since the red team essentially keeps using it until they are prevented from doing so by quick response or preventions, etc.)

Considerations: While I think this is an interesting approach to red teaming, I think using this approach solely would limit what the blue team is exposed to in terms of real world attacks that could target the organization. There could be various other attack vectors relevant to the organization but since this method would be limited to the same adversary model and TTPs (which may not include various other vectors), then the red team would likely not use those vectors. So the end result could be that blue team does not get exposed to the breadth of relevant attacks that they should be preparing for. The positive side is that this approach would essentially force improvement in detections/preventions in the attack paths that the red team is using, since essentially red team will continue doing the same thing (with minor modifications) until forced to evolve by rapid response and preventions.

Approach 3: Non-Linear Operations

This red team approach includes the internal red team running different operations over time that are each individually scoped and that do not have any direct connection across operations. These operations/exercises are often shorter in duration (ex: anywhere from 1 week up through 1 month) and usually have very specific objectives (due to the shorter duration). An example of this approach to running red team ops is below:

• Op 1: Gain access to sensitive customer information
• Op 2: Demonstrate supply chain attack paths for our products that our customers use
• Op 3: Gain access to sensitive company financial data
• Op 4: Social engineer a publicly facing business unit (ex: support) and gain access to sensitive data

These are just examples of different ops an internal red team might run. In the instances above, none of the operations are connected. The red team may use different tactics, techniques, procedures, and tools (thus having different “attacker profiles”) across each en route to achieving mission objectives. So, if blue team developed solid detections from Op 1, those detections may not be applicable for Op 2 (depending on how the op is conducted).

Considerations: As long as the objectives are meaningful and tied to the business in some way, this method of red teaming can be pretty effective. The blue team gets to see variety in terms of the TTPs that they are exposed to across various ops (since red is not tied to emulating a single threat actor). This will help broaden the blue team’s knowledge and experience of what various attack vectors look like in their environment. However, depending on the cadence of red team ops (how frequently they are run), this could also lead to the “squirrel effect” where the blue team jumps to another attack vector without fully building out detections for what they have previously been exposed to. So spacing out these ops appropriately for your environment will be important so that the blue team has the necessary time to work with red to build AND validate detections for each op. This approach is also good for smaller red teams since the ops can be broken into very specific objectives that a small team can achieve over a short period of time.

Approach 4: Unit Testing

This approach is sometimes used as the starting point for a red team, especially when the red team is small (or in some cases an org only has 1 dedicated “red teamer”). In red team circles the concept of a “1 person red team” is frowned upon given the manpower and skillsets needed to effectively perform adversary emulation and simulation, but the reality is that there are several organizations that do start off with only 1 red teamer (with a plan to grow the team in the near future). In those instances, it may be helpful for that individual (or small red team) to perform unit testing of blue team detections across platforms and environments. One starting place could be simply running through the MITRE ATT&CK matrix detections and working collaboratively with blue to run tests of each to gauge the state of detections. This can be done by host (ex: Mac, Linux, Windows), network, cloud environment, etc. The goal with this approach would be to build a solid base of detections for common attacks and post exploitation methods across environments and systems so that you could then move into scoped blind red team exercises that can test blue team’s ability to respond to these detections and perform remediation.

Considerations: I think this is a good place to start if you are a “1 person red team” or a small red team in an organization with a new or inexperienced blue team. This is a good way to immediately help build relevant and high fidelity detections for your corporate environment. As the organization grows and matures, the goal would be for a detection or hunt team to perform this role on an ongoing basis so that as red team grows red team can focus more on operations planning and execution to give blue team the opportunity to respond to alerts and perform analysis and remediation.

In summary, this blog post is not fully exhaustive. There may be other approaches to red team operations that I have not included here. Additionally red teams may rotate between the approaches above in its overall strategy for the year. I simply wanted to quickly discuss approaches that I am aware of that I know provide value to the blue team and to the organization as a whole. I hope this post is useful in helping red teams looking to plan out their operations for the year!