Red Teaming
To strengthen your defenders
Regular penetration testing with a clearly defined scope and a solid methodology is important and helps to increase the level of IT security in an organisation. Unlike a traditional penetration test, which focuses mainly on the technical aspects of IT security, a Red Team Assessment or Red Teaming provides a more comprehensive, sophisticated approach and added value. Red Teaming simulates a real cyber-attack and tests how an organisation as a whole reacts to a cyber-attack. In other words, Red Teaming makes it possible to assess not only the technical side of IT security, but also the response and behaviour of the organisation as a whole.
By simulating real cyber attacks with Red Teaming, we can answer questions such as Is the cyber-attack noticed by the organisation, how well does internal employee communication work, what visibility do their EDR and SIEM provide, does their Security Operation Centre (SOC) receive the attack, how quickly do their defenders locate the cyber-attack entry point, does the Blue Team succeed in removing the attacker from the internal network, etc.?
The methodology of red teaming is fundamentally different from that of a penetration test, e.g. a clear objective is defined at the beginning, e.g. to gain initial access, to compromise the CEO's client or a specific file server, etc. Communication with the company takes place only between our Red Team and the company's White Team or White Cell. Usually the Blue Team does not know that an attack simulation is planned, because this is the only way for the company to check how its own Blue Team reacts unprepared to a real cyber attack. In other words, you get an absolutely undistorted picture of how your organisation would react in an emergency. It is important to understand that the term Blue Team does not just refer to your company's technical defence team, but includes everyone in your organisation.
With Red Teaming we also want to show that even established EDR solutions such as CrowdStrike, SentinelOne, Elastic etc. have weaknesses and blind spots. We want to show that even established EDR solutions such as CrowdStrike, SentinelOne, Elastic etc. have vulnerabilities and blind spots that can be exploited by malicious hackers. At the same time, however, our primary goal is always to strengthen their blue team and show them, for example, how we can bypass their internally deployed antivirus (AV), endpoint protection (EPP) and endpoint detection and response (EDR).
A common misconception (both on the part of the service provider and the customer) about red teaming is that it is just about acting as a red team without being recognised. This makes sense until the agreed objectives have been met. However, if all the agreed objectives have been achieved, e.g. a particular server has been compromised, and the organisation has not yet reacted in any way, i.e. the attack has not yet been detected, the AV/EPP/EDR has not yet reacted, etc., the Red Team must give the Blue Team the opportunity to react to the cyber attack that has not yet been detected. This means that, if necessary, the red team should also perform a very conspicuous action at this point, such as executing code via fork and run to trigger the EDR, for example.
In other words, there is no shame in being discovered as a Red Team by the Blue Team, but ideally the Red Team should have control over when and by what action it is discovered after all objectives have been achieved. Only then will the organisation have the opportunity to gain real value from the Red Team assessment.