What is Red Teaming in Cyber Security? The Complete Guide

Red teaming explained

Red teaming is the practice of asking a trusted group of individuals to launch an attack on your software or your organization so that you can test how your defenses will hold up in a real-world situation. Any organization reliant on software – including banks, healthcare providers, government institutions, or logistics companies – is potentially vulnerable to cyberattacks, such as ransomware or data exfiltration.

For software providers, red teaming is an effective way to test the security of your product or service and protect your users from attacks made via your software in the future. A red team can either be an internal team or a third-party group of ethical hackers hired explicitly for the task.

Red teaming vs. blue teaming

The term “Red Team” originates from the military practice of using war games to challenge operational plans by testing how defenses perform against an intelligent adversary. The “Red Team” refers to the group playing the enemy role, whose job is to get past the defenses of the “Blue Team,” who represent the home nation.

In a cybersecurity context, the red team is a group of ethical hackers tasked with launching an attack. At the same time, the Blue Team refers to the security analysts, operations team, or software developers responsible for the system(s) under attack. Typically, the red team is tasked with a particular goal, such as accessing sensitive data, disrupting a service, or planting malware that will enable future attacks. 

The red team’s only information about the system is what could be gleaned by an actual attacker. The Blue Team is not informed in advance of the attack and should treat any suspicious activity as a live situation and address it accordingly. The red team responds to any defensive measure by adapting their approach and persevering until they reach their goal or are routed by the Blue Team.

Once the attack is concluded, the red team reports their activities, including any vulnerabilities they found and any defenses that worked against them. This information is then used by the security team and/or software developers to strengthen their defenses for the future. The sharing of information from the red team following the exercise is an essential part of the process, turning the simulated attack into an opportunity to improve security operations.

In some contexts, you may come across the term “purple team,” referring to an amalgamation of red and blue teams. The aim of creating a purple team is to focus on sharing the tactics, techniques, and procedures used so that the security staff can learn from them. However, to run an effective simulation, it’s essential that the red team does not have insider knowledge that an attacker would lack, and the blue team reacts as they would in a real-world scenario. Equally, to get value from red team exercises, it’s essential that the red team shares their findings to improve security.

Red teaming vs. Pen testing

Although closely related, red teaming is not the same as penetration testing (aka pen testing). While both types of security testing are designed to assess whether an attacker could achieve a particular goal, their scope is different. 

With a pen test, your security team would typically be made aware of the test before it takes place. The pen testers will work through multiple tactics to achieve the goal, recording any observations along the way.

Red teaming takes security testing a step further. Because the role of the red team is to emulate real attackers, the security team should be unaware of the details or timing of the attack. Furthermore, the red team will operate by stealth, seeking to evade detection and cover their tracks the same way an actual cybercriminal would work.

To make the simulated attack as accurate as possible, red teams go further than pure software testing and may use social engineering techniques and attempt to breach physical security to pursue their goal, just as an actual attacker would.

What does a Red Team attack?

A red team’s attack will depend on what you’re trying to test – your organization, your software, or a combination of the two (as in the case of software-as-a-service providers). To emulate a real cyberattack, a red team may challenge:

• Your network – by attempting to gain access via open ports, compromised devices, or insecure user accounts, to name just a few options. This applies as much to cloud-hosted systems as it does to on-premise installations. Once inside your network, the red team will try to move laterally to systems of interest, exploiting security vulnerabilities to elevate their privileges.
• Your software – by searching your software for vulnerabilities that will enable many types of attack, from buffer overflow to SQL injection, cross-site scripting, to confused deputy. Red teams might also try fuzzing – a technique that involves finding ways to crash your software and then diagnosing the cause of the crash to find a way to use your program for malicious purposes, such as executing malicious code or accessing data that is used by attackers to create new exploits in software that can then be sold on the dark web, resulting in many future attacks on your users.
• Your physical security – by using tools such as RFID cloners to forge security passes or underhand tactics such as bypassing security camera blind spots or picking locks to access a physical network port or server room.
• Your people – by using social engineering to gain access to your physical premises, plant malware via carefully targeted phishing scams, or retrieve information about your organization that can facilitate an attack.

In practice, these areas overlap, and a red team will often use tactics that cover some or all of these areas. For example, although your remote access protocols might defend your systems from network intrusion, weak building security combined with some simple social engineering could allow your red team (or a malicious actor) to gain entry to your offices and get their hands on an unattended employee laptop or connect their own device to an available network socket. 

Once inside your network, they can use privilege escalation tactics to access critical systems. Having gained access, they will demonstrate how they could exfiltrate valuable data or plant malware that could be used to encrypt your files and demand a ransom.

When should you use a Red Team?

While red teaming and pen testing are effective ways of testing your organization’s cyber defenses, they are not designed to provide you with an exhaustive list of all your security vulnerabilities. That’s the role of a vulnerability assessment.

Before you embark on red team testing, it’s vital to lay the groundwork with a detailed vulnerability assessment to identify, prioritize and address as many security flaws as possible. Findings might range from unpatched servers and default admin passwords to use of compromised third-party libraries or failure to sanitize user inputs.

Having addressed all known issues, it’s time to use a threat assessment to identify the highest risks to focus your testing accordingly. The type of cyber-attack you’re most likely to face will depend on your organization and industry. 

The lowest level of attacks are those launched by individual opportunistic hackers using known exploits and off-the-shelf tools to see what they can find, from user account credentials to servers on which to deploy cryptocurrency miners. 

More high-profile organizations and those with valuable assets are at higher risk from advanced attackers that will invest time in employing underhand tactics to deploy ransomware, steal sensitive information, or craft new exploits for your product or service. Finally, there are nation-state-sponsored attackers with vast resources at their disposal to select strategic targets.

Once you have put your security measures in place and have determined the types of risk you likely face, you can test your defenses with a pen test to check for more complex vulnerabilities. Having fixed all you can, it’s time to see how they stand up against a sustained assault via red teaming.

Ideally, red teaming should be an ongoing activity that continuously assesses your security posture. As changes are made to your systems or software, and new exploits are discovered, you must keep testing your defenses against realistic attack techniques.

What are the benefits of red teaming?

An effective red team will adapt their tactics in response to your defenses, looking for any opportunity to gain access to your systems, which means they are well placed to find unanticipated ways. 

Organizations that regularly use red teaming to challenge their security posture can use the findings from those exercises to strengthen their defenses, improve their ability to detect attacks early on, and limit any damage. By emulating all aspects of a likely attack, red teaming tests the ecosystem as a whole rather than just one element of it.

Sharing the results of a red team attack with your employees – mainly where social engineering formed part of the approach – can help minimize complacency and foster a security culture. Showing the impact of a seemingly insignificant breach is often far more compelling than a corporate training video.

Continuous red teaming also provides real-world metrics for your SOC team to measure their performance over time and provide valuable evidence to inform and justify investment in security enhancements.

How does the red team security testing process work?

The starting point for red team activities is to set out their terms of engagement. This should include details of anything that is expressly off-limits, describe how authority is given for an activity, agree on how personal and sensitive information will be handled, and detail the conditions for ceasing a red team attack.

Although your security team (the blue team) should be largely unaware of a red team engagement (including the planned date and time), it’s vital that someone in authority is aware of upcoming activities and can provide the necessary assurances – to both law enforcement and stakeholders – that their actions have been authorized. This is true whether the attack is against your organization or a software product – in the latter case, if you integrate with third-party providers, they should be notified that red teaming may occur.

Once terms are agreed upon, and a goal has been defined, the red team process can begin. This includes:

• A reconnaissance phase to gather as much information as possible about the target. To make the attack as realistic as possible, the red team should not benefit from insider knowledge that would not be available to a likely attacker. However, they can use any means at their disposal to gather intelligence – from reviewing web and press content, satellite images, and social media posts to covert observation or tricking employees into unguarded conversations.
• A planning phase to determine the best tactics, techniques, and procedures to use, together with contingency plans. In the case of an attack on your organization, this might include using social engineering to get an employee to connect a USB drive to a networked device or simply getting close enough to use office Wi-Fi with weak credentials and broad permissions.
• The attack phase. This is when the red team puts their plan into practice. Depending on tactics, this could last for hours to days or weeks. The security team should be operating as usual.
• The attack phase ends when either the red team achieves their goal or is detected and stopped. The point at which the red team reveals themselves by presenting their letter of authority or calling in the senior stakeholder to vouch for them can vary. In some situations, it’s helpful to allow some of the security response to play out as if it were an actual attack, to derive as much learning as possible from the test.
• A report and retrospective phase to provide feedback on the exercise. The report should include complete details of the attack, including those defenses that worked well and those that were breached, what techniques were used to move laterally and/or escalate privileges, and any additional harm that could have been done beyond the defined goal.

Once the process is complete, it’s over to the security team or software developers to start addressing vulnerabilities and updating procedures, ready for the next attack.

Common red teaming tools

If you’re new to red teaming, various tools can help you get the most value out of this security testing activity.

The MITRE ATT&CK framework is a valuable resource for recording and analyzing the phases of an attack. As a red team, you can use the framework to identify strategies and document your approach for reporting after the event. As a Blue Team, identifying the tactics, techniques, and procedures used in an attack will assist you in identifying mitigations better to protect your organization or your software in the future.

MITRE Caldera is an open-source project from the creators of the ATT&CK framework, which you can use to automate elements of both a red team attack and a Blue Team response.

Finally, tools such as Vectr assist with planning and reporting on red teaming activities, including collecting metrics to assist you in measuring the performance of your defenses.

Conclusion

Red teaming provides the most realistic test of your systems’ and your organization’s defenses against a cyber attack. If your organization is responsible for user data or relies on software systems for day-to-day running, you’re vulnerable to ransomware and data exfiltration attacks. If you’re developing software, verifying the security of your products and services is essential to protect your users from attacks that exploit your system. To get the most out of red teaming, make it an ongoing practice and ensure all findings are shared and acted upon.