Red team explained

It became trend last two years to ask for red team assessment instead of security assessment, pentests or application tests. Somehow a red team became a fancy word for an external penetration test with social engineering on selected targets. We, in Rolken, are firm believers that security works and it’s easy but not simple. Since there are no holy-cow-silver-bullet-solutions red teaming is not an example. 

There are multiple reasons why you want to use red teaming but let’s curb the first enthusiasm and set a little bit of the expectations:

  • there is no magic going to happen – a blue team and a red team have still to work security out and it is going to take time;
  • everyone is unique and it is not sufficient reason to do red teaming just because everyone is doing it;
  • the bad red team is worse than no red team – starting with red teaming is more about culture than results. The bad red team is going to move your culture at least one year back.

When to use red team

When you have basics done. These basics are: you have staff, you are able to monitor at least the network level, and you think you can respond to incidents. This carry you did at least these things:

  1. an asset inventory and you understand your landscape (where are devices, which firmware your switches have, how many access points you are operating, how many unsupported windows XP you have etc.);
  2. centralized logs and network monitoring;
  3. you did basic hygiene – regular vulnerability scanning and penetration tests;
  4. and fixed pentests and vulnerability scans outcomes and documented what could not be fixed. And you are monitoring the weak points which can’t be fixed.

You don’t need to have fancy tools like an anomaly monitoring, SIEM, security automation etc. In our experience, the motivated team of juniors with open source tools would give us way harder time than just one person with many fancy tools.

How to use red team

There is the sole purpose of a red team – to improve a blue team. It is like vaccination – if you want your immune cells able to react properly to a real adversary, you need to expose them to one in a controlled environment. Also, practice makes perfect and worst time to practice is during the real crisis.

There is another important thing to consider and it is continuity. You want continual improvement of a blue team and to achieve the continual improvement you need to do regular exercises.

This is how you can differentiate between bad and good red team. For bad one an objective is to hack you all the ways up and down. Good one focuses on the tested part and on skills transfer. During retrospectives, we often find the distribution of time is 40% testing, 20% recommendations, 40% skills transfer to the blue team.

What does it mean to win?

Our approach is “if we win, we lose”. A side note: we almost always win. The good thing is we tend to win using a different approach compared to the last engagement. Our payloads from last time did not work? Very well! Physical security caught us? Good. Immediate detection of scanning? We are very happy.

If our tricks from the last exercise did not work it means we did our job well and a blue team have improved. Bonus for us: we have to improve too and make another clever way to overcome a blue team countermeasure.

Simply put, we are iterating together to moment when we have to say, sorry there is no way how we can attack you.

In-house vs external?

Let’s speak a little bit about quality. In red teaming there is a correlation between quantity and quality in term there is no single person red team (that is why is it called team). Red team by definition is a team consisting from people with various skills. From security assessment via development, social engineering, physical security to business analysis.

This means if you do not have a budget for at least 3-4 persons there is almost no point in making an internal one. Your blue team will benefit more from less interaction with a good external party than from more interactions with a less skilled internal team.

It does not mean you should not have someone responsible for interaction with a red team and organisation of red teaming activities. But it could be a manager of a blue team – in the end, it is this role which strives excellence of his team. In our experience, we delivered the best results when on the other side was a technically competent project manager. Often it is pentester or security analyst with people and project management skills.

Decided to go for the internal one? Try to understand who you are hiring and what they are going to do. You can start by reading Red Team Field Manual and Blue Team Field Manual because you’v got to have defenders first.


Red teaming is less product or service and more cultural change. To embrace this cultural change you’ve got to know when and how to do it and understand nuances and motivations (what you want to achieve and what is on the market).

To succeed and implement red teaming into your organisation fix basics at first (assets, vulnerabilities, pentests and countermeasures), communicate with a blue team and let them know you want to transfer skills from red to blue not test and catch them with pants down. Decide on the best approach – whether you have enough resources to build internal one or you are going for the external route.