On a day to day basis I get asked why companies should care more about red teams. Often within the same sentence it is stated that a standard penetration test is sufficient and that other forms of offensive security assessments aren’t needed “because everything is covered already” or “else it might break”

One thing I’ve seen from both client side and business side, is that this statement is incorrect by design. You don’t know what you don’t know. A lame statement, I know. Think about it though, how sure are you about everything you have inside your IT landscape? Developers work on servers every day, but do they always follow the protocol to the letter? Does everything always work 100% of the time? I’m pretty sure it doesn’t, this is the reason why red teaming is so interesting and valuable.

Besides anything else, it’s a real genuine challenge for a company’s defense to see how well they are capable to detect attacks from adversaries without the real attack to worry from.

This article will be about how red teaming works and why they are a very welcome addition to other conducted security assessments.

I will try to cover the business side of things like conflict of interest, scoping, setting quality flags and objectives, white team meetings, added value for blue teams and finally a thing or two on purple teaming.

The technical and process methodology side of red teaming will be covered in a later article. If you are looking for the tl;dr, I’ve placed that on the bottom with the summary.

Business and conflict of interest

The dubious parts of scoping that I’ve encountered in the past is that the company that pays you and requests the assessment also is the company who dictates the ground rules in most cases. This means that they tell you what you cannot do in terms of systems and networks.

It means that it can result in a conflict of interest, as you can never know for sure why these limitations are set up. Is it because the company knows they have weaknesses in those systems that you cannot discover, or are they hiding something else?

For a truest and most valuable red team, everything should be allowed. This includes third party suppliers, all company office locations and every single employee and system available.

Also, an independent referee should be included, which is known as the white team leader. The white team consists out of the offensive party, the red team as well as the defensive party, the blue team.

Together they have frequent sessions that demonstrate what has been done and what should be done.  

Scope: let the hacker pick their own battle route!

One of the biggest differences between scope in normal security assessments and a red team approach are the limitations and boundaries set by the requesting company.

During a pen test or web-based security assessment, the scope is limited and usually set to only one application. This is still really necessary to do and remains valuable for now (agile development and security is a different topic that I will address in later articles) but it usually doesn’t look well into system integrations and what happens to system B when malicious data is inserted into system A, because that is not in scope and can cause serious trouble for the researcher when looked into.

During a red team exercise, the entire company’s premise is in scope. There are flags set that the hackers of the red team must obtain, one way or the other. There are no limitations in terms of people, process or technology. They basically get a “carte blanche” to do whatever is needed to get to the flag.

The great thing about this, is that you let fresh eyes look at the things that you’ve always taken for granted. A hacker is known for having a different view on the world and can-do things with systems, people and services that others have not thought of. They consider that one your server you haven’t though of to be a perfect way into your network.

This means that new and innovative attacks are inevitable and very much needed to happen! You cannot gain new insights if you are the one telling what to do all the time, can you?

Are there really no limitations?

For reasons that are even debatable, usually extortion and bribery are not allowed. I state this is debatable, as true adversaries at higher levels don’t hesitate to do this. For this purpose, the possibility of a bypass is created.

When a red team can prove that it is possible to conduct a highly unethical attack, certain access can be granted by the referees, which are called the white team during these exercises.

The white team also always has the veto possibility to stop all activity, this is done through a red button procedure. This is a final resort and usually means the red team is going way out of line or a real attack is incoming and require more resources.

How do you set the correct flags?

Flags are concrete objectives that are complex in obtaining but are achievable. A flag can be something like obtain domain administrative rights, but also something like obtain information that can be used to manipulate stock prices or get into the mailbox of the CEO.

The general red team objective must be set up in a smart smart in order to be valuable for the company’s blue team, executive management and red team provider itself.

It usually is something along the following lines:

“In order to test the company’s security resilience, the red team will attempt to obtain the set flags within a time period of 6 months without being detected by the company’s blue team while mimicking a professional organized crime syndicate conducting a targeted attack against the company with all available means and keeping close communication with the white team at all times”

This is a very long and detailed statement, so feel free to read it a few times carefully. It should be: Specific, Measurable, Acceptable, Realistic and Time-bound.

A very important notice to the objective is the attacker level that is mimicked. I created 5 levels throughout the years that I’ve used in assessments.

1. The first level is that of an attacker who requests anonymity and needs the cheapest possible access attempts to access systems using open source software. The attacker will be looking for standard vulnerabilities that can be implemented quickly on many servers at once.
2. The second level is a novice where a limited budget is available to gain access to the networks of the party under consideration. The attacker will focus more on a specific target and has a focused goal.
3. The third level is a professional who works alone but has professional resources and knowledge to deploy his own exploits written for an attack. Specific attacks such as the use of proper written exploits of Social Engineering attacks are used to achieve the goal.
4. The fourth level is the adversary-for-hire. Multiple adversaries are hired by an organization that tries to enter based on a P/L-based attack. The greater the value of the hack, the more resources are used during the attack.
5. The fifth and final level is that of a so-called ‘State Operated’ organization. There are unlimited resources available and will at all costs be attacked until it reaches the target.

A nation state scenario is close to impossible to mimic, as these have unlimited budget and time and attack for ideology and not for profit.

How to conduct these types of tests will be explained in a different article, as it aims more for proving how a theoretical vulnerability can be exploited. It also focuses much more on exploiting third parties to get into the primary targets network.

What to look out for in white team meetings

There are many pitfalls you can walk into during white team meetings. Each one can cause major disruption of the entire project.

1. Lack of chairman leadership. The chair must be an unbiased and independent entity, which is usually a challenge to get into the picture. The chair is the only one who can make a formal go/no go decision on attacks.
2. Fights between blue and red team. When actions are discussed in to much detail, red and blue can massively differ in opinion as usually both parties are colliding head on. The red team is trying to prove that there are holes in the network that the blue team defends. It can very easily become to “feel personal”
3. Scope limitations; it is easy to discard ideas and radical suggestions from the red team as “not possible because xyz”. Often the red team is bound by time and will suggest to help the project forward without loosing time in for example exploit development. Saying no for the wrong reasons is a limitation of value to the project.
4. Lack of communication by the red team before and during attacks. Being attacked is a very scary thought, and hackers underestimate the feeling this gives at the company they attack. Clear communication protocols, like a tcp handshake, before starting an attack is a real good added value to white team meetings.
5. Not taking minutes and sharing them in concrete, actionable steps. When the meeting is over, everybody starts to go back to their normal routine. People forget things, unintentionally. When discussed topics during the meeting are actioned, they are easy to follow up on.

Detection by the blue team

The fun part for the blue team is that they play the game without knowing they are in it. They must detect the anomalies within the network like any other day. They don’t that there is an assessment ongoing.

It therefore means that red team activities are considered legitimate malicious activity. It is vital that there is a procedure in place that must be followed to prevent police reports can be filed against the red team. The last thing anyone needs is having to deal with authorities during these types of activities. This means that the blue team leader should be in the white team and is fully aware of the actions without telling its team members.

The red team is limited by law, where adversaries are not. This means that they cannot go the lengths adversaries can, and therefore it will always be possible to track and identify.

It is important to overcome these “detections” by trying to understand how the detection was done. Was it because of an error by the red team that they should have avoided (traceable code or use of emails / domains that belong to red team members) or was it a genuine detection that also could be done with an adversary? Only the latter step adds real value.

Mix up colors, make it purple!

Often the most valuable part of the entire project is the purple team phase. This is basically a re-enactment of what has happened to understand the why part of it all.

To perform a good purple team replay, it is vital that good time log is kept during the activity. A blue team should do this already to have their SOC, SIEM and all other procedural stuff in order.

They should be able to retrieve the logs easily. If not, it’s an issue that needs adequate resolution. After all, if you can’t reproduce what you have done to defend attack, how can you tell anyone in court that the adversaries should be punished for what they did….

Anyhow, a new red team is not used to do this carefully and meticulously, and therefore is at risk not delivering a good purple team play. To come properly prepared, red teams should keep a log book in which is described who is doing what where, how why and when.

Every action they take should be written down and documented well with screenshots and code when used. They do this so that the attack can very easily be replayed and demonstrated during the purple team phase.

The purple phase brings everything together and is the part where most value is added. It is important to ensure that blue and red team don’t end up in a “yes” or “no” fight about why things happened the way they did.

It is meant to gain understanding how things happened, and the red team can demonstrate how they gained access to the targets and how they captured flags. From blue team perspective, get the opportunity to demonstrate to the red team how they detected actions and how they eradicated the persistence from the network.

Both teams learn a lot from this phase and must be open to understand where mistakes have been made. These should be embraced before you can grow stronger and beat real adversaries when they attack your company!

You’ve made it! Time for a Wrap up!

If you made it here, thanks for sticking by! I know it’s a long one, but I felt it was needed to set the playing field right. If you chose the tl;dr route, also thank you! J

 In short, we discussed the following five key points of red teaming:

1. Avoid the possible conflict of interest bias and hackers decide what their scope is
2. Set concrete flags and a SMART overall objective for best results
3. Remember the common pitfalls during white team meetings!
4. The blue team is unaware, set a safety net
5. Mix up colors and have a purple team session!