In brief

A thunderstorm is brewing. Two men claiming to be service technicians enter a branch and ask whether the internet is still working. They explain that there have been partial outages in the neighbourhood. An outage would be critical for the business: without the internet, the till systems won’t work. The technicians offer to set up a backup connection as a precaution. They are willingly shown to the server room. There, however, they do not install a backup connection, but instead plug a device into a spare network socket.

The perimeter has been breached. Not through a highly complex technical vulnerability, but through a plausible pretext.

The scenario is taken from a red team assessment – that is, a controlled security test in which ethical hackers, working within clearly defined rules, test how far they could penetrate a company’s systems. This example illustrates what modern cyber security is all about: it is not just firewalls, end devices and cloud systems that form part of the attack surface. Routines, areas of responsibility, access procedures, a willingness to help and time pressure can also pose a risk.

Many companies have significantly expanded their cyber defences in recent years. They operate Security Operations Centres, deploy security solutions for end devices such as laptops, servers and workstations, define incident response processes, train staff and monitor critical systems. This is necessary. But it does not yet answer the crucial question: does everything work together effectively in an emergency?

Traditional audits often reveal whether security controls are in place. Red Teaming shows whether they are effective under pressure. This is because real-world attacks rarely follow neatly documented process chains. Attackers do not look for the strongest defence mechanism, but for the weakest link: between technology and organisation, between policy and actual practice, between an alert and a response. This is precisely where Red Teaming comes in.

Red Teaming highlights the fact that cyber security is not solely a technical discipline. A realistic attack can begin in various ways.

• Technical Breach: The entry point is the technical attack surface: publicly accessible systems, subdomains, open services, misconfigurations, exposed interfaces or clues gleaned from publicly available information. Typically, the process begins with OSINT and reconnaissance – that is, the collection, analysis and correlation of freely accessible information, as well as technical reconnaissance of the IT infrastructure.
• Social engineering: The point of entry is the individual: an email, a phone call, a plausible story or a situation where time is of the essence. The white paper describes, for example, scenarios involving helpdesk calls to change passwords and phishing attempts, in which vigilance, scepticism and clear processes are crucial.
• Physical Breach: The point of entry is physical access: buildings, reception areas, meeting rooms, server rooms or freely accessible network connections. The example involving the supposed service technicians illustrates how a plausible pretext can put visitor procedures, trust in roles and access controls to the test.

The key insight is that physical security, IT security and organisational processes cannot be considered in isolation. An open network connection can be just as critical as a technical misconfiguration.

Breaching the perimeter is only the first step. After that, the more important question arises: how far could an attacker get? Red teamers assess whether lateral movement within the network is possible, what access rights exist, whether sensitive data would be accessible, and whether critical systems could be taken under control. They do not carry out acts of sabotage. But they demonstrate what might be possible. It is precisely this change of perspective that is valuable. Organisations view their security posture not from the perspective of their own architecture, but from that of a motivated attacker. The result is a more realistic picture of the risks involved.

A good Red Team assessment does not end with the identification of a vulnerability. It ends with concrete improvements. These include a detailed report, documented attack paths, a timeline of events and practical recommendations for action. The assessment also evaluates how well the organisation detects and responds to attacks. Our white paper describes this improvement process as an interplay between red teaming and blue teaming: the combination of attack and defence gives rise to purple teaming – with the aim of identifying detection gaps, accelerating feedback loops and continuously improving cyber defences. Red teaming is therefore not a vote of no confidence in an organisation’s own cyber defences. It is a stress test of their effectiveness.