A red team is an authorized group of security specialists that emulates a realistic adversary against an organization, pursuing defined objectives with the stealth, persistence and techniques of real attackers. In security testing, a red team engagement measures not only whether systems can be breached but whether the organization’s defenders detect, investigate and stop the attack in time.
The term comes from military exercises, where a red force plays the opponent. In cybersecurity the defending security operations team is the blue team, and a small white team or control group oversees the exercise, approves risky actions and resolves conflicts.
What a red team engagement tests
A red team exercise is objective-based, not list-based. Instead of finding every vulnerability in a defined scope, the team receives goals such as reaching the payment system, exfiltrating a specific dataset or obtaining domain administrator rights, and may use any approved path to get there: phishing, exposed services, stolen credentials, physical entry or social engineering.
Because the defenders usually do not know the exercise is running, it tests the whole security program at once: technical controls, logging, the SIEM and EDR, analyst skills, escalation procedures and even management decisions under pressure. The key outputs are detection gaps and response weaknesses, not just a list of flaws.
| Team | Role | Knowledge of the exercise |
|---|---|---|
| Red team | Emulates the attacker | Full |
| Blue team | Detects and responds | Usually none until the end |
| White team | Controls scope, safety and deconfliction | Full |
| Purple team | Red and blue working openly together | Full, collaborative format |
Phases of a red team operation
Engagements typically run from several weeks to a few months, because realistic attackers move slowly to avoid detection. The phases follow the attack lifecycle and are often mapped to MITRE ATT&CK tactics for reporting.
| Phase | Activities | Output |
|---|---|---|
| Planning | Objectives, rules of engagement, legal authorization | Signed scope and contact plan |
| Threat intelligence | Select adversaries relevant to the sector | Attack scenarios to emulate |
| Reconnaissance | Map people, domains, exposed services | Target list and pretexts |
| Initial access | Phishing, exploitation, physical entry | First foothold |
| Escalation and lateral movement | Privilege escalation, credential theft, pivoting | Path to objectives |
| Objective actions | Access or simulated exfiltration of target data | Proof of impact |
| Reporting and replay | Timeline, detections, joint debrief with blue team | Prioritized improvements |
The rules of engagement document is the backbone of the exercise. It defines permitted techniques, forbidden systems, working hours, data handling and emergency stop procedures, and it ensures that every action is legally authorized by someone with the power to do so.
Red teams operate their own command-and-control infrastructure, with redirectors, aged domains and traffic profiles that imitate legitimate services, because defenders who spot a crude setup learn little about real threats. Operators keep a detailed action log with timestamps for every command, which later lets the blue team match each red team step against its own alerts and reconstruct exactly what was visible.
Red team compared with other security testing
Red teaming is often confused with penetration testing, but the two answer different questions. Penetration testing asks how many weaknesses exist in a defined target; red teaming asks whether a determined adversary could reach business-critical goals without being noticed.
| Method | Main question | Scope | Stealth |
|---|---|---|---|
| Vulnerability scanning | Which known flaws exist | Broad, automated | None |
| Penetration testing | How exploitable is this target | Defined systems | Usually low |
| Red team | Can objectives be reached undetected | Whole organization | High |
| Purple team | Which techniques do we detect | Selected techniques | None, by design |
| Bug bounty | What can external researchers find | Published program scope | Not a goal |
Regulated sectors use formal threat-led testing frameworks. TIBER-EU in Europe and CBEST in the United Kingdom define intelligence-led red team tests for financial institutions, and the EU Digital Operational Resilience Act (DORA) requires threat-led penetration testing for significant financial entities.
When an organization is ready for red teaming
A red team delivers the most value to organizations with a functioning detection and response capability. If basic hygiene is missing, an expensive multi-week exercise mostly rediscovers what a penetration test or vulnerability scan would have found faster.
| Situation | Better choice | Reason |
|---|---|---|
| No central logging or SOC | Penetration testing and hardening | Nothing to measure detection against |
| SOC exists, coverage unknown | Purple team exercises | Builds detections technique by technique |
| Mature SOC, critical assets defined | Full red team | Tests real-world resilience end to end |
| Regulatory requirement | Framework-based threat-led test | Meets supervisory expectations |
Success is measured by how quickly the blue team detects and contains each stage, not by whether the red team eventually succeeds. A skilled red team with enough time usually reaches its objectives; the useful insight is where the defense noticed and where it did not.
Risks and common mistakes
- Unclear authorization: testing third-party cloud or outsourced systems without their owners’ consent can be illegal.
- Production disruption: aggressive exploitation can crash systems, so the white team must approve risky steps.
- Poor deconfliction: real attacks can be mistaken for the exercise, or the reverse, without a trusted contact channel.
- Reports that blame people: findings about clicked phishing links should drive training and controls, not punishment.
- No replay with the blue team: skipping the joint debrief wastes most of the learning value.
The word red team is also used in AI safety testing, where specialists probe models for harmful outputs. That practice shares the adversarial mindset but differs in targets and methods from infrastructure-focused red teaming described here.
In simple terms
A red team is a group of friendly attackers hired to break in. They behave like real criminals, quietly and patiently, to show an organization what would actually happen during a serious attack.
It resembles a surprise fire drill combined with a test of the smoke detectors. The point is not only whether the building has weak spots, but whether alarms sound and people respond correctly before real damage occurs.
A practical example
A national insurance company commissions a ten-week red team exercise with one objective: access the claims database containing customer health information. Only the chief information security officer and two white team members know about it.
The red team sends targeted phishing emails, gains a foothold on an employee laptop, and spends three weeks moving laterally using stolen credentials. The SOC detects unusual remote administration tools on day 19 but closes the alert as a false positive. The team reaches the database on day 34 and stages a harmless test file to prove access. During the replay, analysts see exactly where signals were missed; the company tunes eleven detection rules, adds escalation training and repeats key scenarios in a purple team session three months later.