WHAT IS RED TEAMING AND HOW DOES IT WORK

Red teaming is the closest thing to a real attack that an organisation can experience without actually being compromised. It is an objective-based adversary simulation where a team of offensive security professionals attempts to achieve a specific goal — reaching a high-value target, exfiltrating sensitive data, or demonstrating that a critical system can be compromised — using the same techniques, tools, and mindset as a genuine threat actor.

How red teaming differs from penetration testing

The distinction matters because the two disciplines serve different purposes and produce different outcomes.

A penetration test is scope-defined and coverage-driven. The client specifies a set of targets — a web application, a network range, a set of hosts — and the tester’s job is to find as many vulnerabilities as possible within that boundary. The result is a comprehensive list of issues ranked by severity.

A red team engagement is objective-driven and unconstrained. The client defines a goal — “reach the finance database,” “demonstrate domain admin access,” “exfiltrate customer records” — and the red team determines how to get there. There is no fixed scope. If the shortest path to the objective runs through an unpatched legacy system, a phishing email to a junior employee, or the fire exit of a regional office, those are all fair game.

A penetration test answers: “What vulnerabilities exist in this system?” A red team answers: “Can an attacker reach our most valuable assets, and would we detect them trying?”

The phases of a red team engagement

Red team engagements typically follow a structured methodology, even though the execution is deliberately unpredictable.

Reconnaissance

The red team begins by gathering intelligence on the target organisation. This includes:

• Passive OSINT. Public records, domain registrations, DNS records, job adverts, LinkedIn profiles, social media, leaked credentials from historical data breaches, and any other publicly available information.
• Technical footprinting. Identifying internet-facing systems, IP ranges, cloud infrastructure, email security configurations (SPF, DKIM, DMARC), VPN endpoints, and remote access portals.
• Human mapping. Identifying key individuals — IT administrators, executives, finance staff — who may be targeted for social engineering or whose credentials would provide the most value.

Initial access

Using the intelligence gathered, the red team attempts to gain a foothold inside the target environment. Common initial access techniques include:

• Phishing. Crafted emails designed to deliver malware, harvest credentials, or trick the recipient into taking an action that grants the red team access. These are not generic phishing emails — they are tailored to the target using intelligence from the reconnaissance phase.
• Exploiting internet-facing services. Identifying and exploiting vulnerabilities in web applications, VPN gateways, mail servers, or other systems exposed to the internet.
• Physical access. Gaining entry to a building to plant a device on the internal network, access an unlocked workstation, or steal credentials.
• Social engineering. Phone calls, in-person pretexting, or other manipulation techniques to obtain credentials, access, or information.

Persistence

Once inside, the red team establishes persistence — ensuring that they can maintain access even if their initial entry point is discovered and closed. This might involve deploying additional implants, creating new user accounts, or establishing alternative communication channels.

Lateral movement

From their initial foothold, the red team moves through the network towards the objective. This involves:

• Credential harvesting. Extracting passwords, hashes, or tokens from compromised systems.
• Privilege escalation. Moving from a standard user account to one with greater access — ultimately aiming for domain administrator or equivalent privileges.
• Network enumeration. Mapping the internal network to identify where the target data or systems reside.
• Exploiting trust relationships. Using legitimate access from one system to move to another, often through Active Directory trusts, shared credentials, or misconfigured permissions.

Objective completion

The engagement concludes when the red team either achieves the agreed objective or the engagement window closes. The objective might be:

• Accessing a specific database or file share.
• Demonstrating the ability to exfiltrate sensitive data.
• Achieving domain admin access.
• Reaching a physically secure area.
• Demonstrating that ransomware could be deployed (without actually deploying it).

Command and control

A critical component of any red team engagement is the command and control (C2) infrastructure. This is the communication channel between the red team and any implants or tools deployed inside the target environment.

Red teams build C2 infrastructure that mimics real-world threat actors: using encrypted communications, rotating domains, and blending traffic with legitimate services to avoid detection. The sophistication of the C2 infrastructure is part of the test — it challenges the organisation’s ability to detect covert communications within its network.

What the engagement delivers

A red team report is fundamentally different from a penetration test report. Rather than a list of individual vulnerabilities, it tells a story:

Attack narrative. A step-by-step account of the red team’s path from initial reconnaissance to objective completion. This narrative shows exactly how each weakness was identified and exploited, and how the chain of compromises led to the final objective.

Detection gaps. Throughout the engagement, the red team tracks which actions were detected by the organisation’s security team and which were not. This is one of the most valuable outputs — it shows where the organisation’s detection and response capabilities have blind spots.

Recommendations. Targeted recommendations for closing the specific gaps that the red team exploited, as well as broader improvements to detection, monitoring, and response capabilities.

Debrief. Most engagements conclude with a detailed debrief where the red team walks the client’s security and leadership teams through the attack path, answers questions, and discusses priorities for remediation.

When red teaming is the right choice

Red teaming is not a replacement for penetration testing — it serves a different purpose. Organisations typically benefit from red teaming when:

• They have a reasonably mature security posture and want to test it against a realistic adversary.
• They want to assess their detection and response capabilities, not just their preventative controls.
• They need to understand the real-world impact of a compromise — what an attacker could actually achieve.
• Regulatory or industry frameworks require adversary simulation (such as TIBER-EU or CBEST in the financial sector).
• They want to test across multiple attack surfaces — digital, physical, and human — in a single engagement.

For organisations that have not yet conducted penetration testing or have significant known vulnerabilities, addressing those gaps first will deliver more value. Red teaming is most effective when it tests a defence that the organisation believes is working.