Red teaming is a goal-based adversarial security exercise in which a team of ethical attackers attempts to achieve a specific objective against an organization's live defenses, to test not just whether vulnerabilities exist but whether the organization can detect and respond to a real attacker.
What is red teaming?
Red teaming is a goal-based adversarial security exercise. NIST defines it as "a group of people authorized and organized to emulate a potential adversary's attack or exploitation capabilities against an enterprise's security posture." The key word is "adversary": red teamers do not work through a checklist of known vulnerabilities; they behave like a real threat actor pursuing a specific objective, using whatever combination of techniques gets them there.
The practice has roots in military war-gaming and intelligence: you field a team whose job is to defeat your own defenses, so you find the failure before an adversary does. In cybersecurity, the team is made up of ethical hackers who have been given permission to compromise systems, move laterally, escalate privileges, and reach a defined target: exfiltrating a data set, gaining control of an operational system, or reaching a specific account. The test succeeds when they get there, or fails when the defenders catch them.
A common misconception is that "red team" means any offensive security work. It does not. Red teaming is specifically objective-based, adversary-simulated, and designed to test detection and response, not just to enumerate vulnerabilities. A penetration test, a bug bounty, and a red team engagement are three distinct practices.
Red teaming versus penetration testing
A penetration test and a red team engagement both involve skilled testers attacking your systems with permission. The difference is in purpose, scope, and what they measure.
A pen test is broad and finding-oriented. Testers work through a defined scope, enumerate as many exploitable weaknesses as possible, and document each one. The output is a list of vulnerabilities, rated by severity, with reproduction steps. The organization typically knows the test is happening. A pen test tells you the state of your vulnerabilities.
A red team engagement is narrow and objective-oriented. Testers pick a goal a real adversary would pursue (reaching your production database, accessing payroll records, compromising a privileged account) and attempt to reach it by any realistic means available. Scope is deliberately wide: if social engineering or a supply-chain path gets them to the objective, it is in bounds. The security team is typically not told a test is happening, because their detection and response is part of what is being measured. A red team engagement tells you the state of your detection and response.
Both are valuable. They answer different questions.
How a red team engagement works
Scoping and rules of engagement
Before any attack begins, the red team and the organization agree on an objective, the boundaries of the test (what is in scope and what is off limits), and the rules of engagement. Common objectives include: reach and exfiltrate a sensitive data set, achieve persistent access to a production system, or successfully compromise a named account. The rules of engagement define what techniques are permitted and which systems are excluded (for example, a shared SaaS infrastructure that the organization does not own).
The attack simulation
Red team engagements map to the MITRE ATT&CK framework, which documents the tactics and techniques real threat actors use. A full engagement chains across these stages:
- Initial access. Gaining a foothold: spear phishing, exploiting an exposed service, abusing a misconfigured authentication path.
- Execution and persistence. Running code on a compromised host and establishing a way back in, even if the original foothold is discovered.
- Privilege escalation. Moving from a low-privilege account to a higher one, toward domain admin or a cloud root credential.
- Lateral movement. Spreading from the initial foothold to other hosts and services, moving closer to the objective.
- Exfiltration or actions on objective. Reaching the agreed target and demonstrating impact.
At each stage, the red team is also observing whether the defender's tooling fires: whether alerts are generated, whether anyone investigates, and how quickly.
What a red team delivers
The output of a red team engagement is not a vulnerability list. It is a narrative: the attack path taken, the techniques used at each step, where defenses held, and where they failed or went undetected. It typically includes a timeline of events correlated against the defender's detection log, so the team can see exactly which stages were visible and which were invisible. That gap between what happened and what was detected is where the actionable work lives.
Red team, blue team, and purple team
The red team attacks. The blue team defends, monitors, and responds. In a standard red team engagement, the two operate independently: the red team tries to stay undetected, the blue team tries to catch them.
A purple team exercise is a different format: the two work together. The red team runs a technique, the blue team watches whether their tooling detects it, and then both sides discuss the result in real time. It is less about the realism of the attack and more about efficiently finding detection gaps across a known set of techniques. Purple teaming covers more ground in less time than a fully adversarial engagement, at the cost of some of the realism.
Many organizations use both over time: purple teaming to build and validate detection coverage across MITRE ATT&CK techniques, and a full red team engagement periodically to test whether the whole system, the tooling, the alerts, and the people hold up under a realistic, sustained attack.
When red teaming is worth it for lean security teams
Red teaming is not the right starting point. It assumes detection and response capability to test: if your SIEM is not tuned, your alerts are not triaged, and your team has no response playbooks, a red team engagement will confirm that you cannot catch an attacker. You already knew that. The more useful investment at that stage is building the detection capability first.
For lean security teams, the question is whether you have something meaningful to stress-test. Red teaming earns its cost when you have the basics in place, the known vulnerabilities are found and fixed, and the real uncertainty is "would we catch a competent attacker using realistic techniques." At that point, a red team engagement gives you an answer, not just another list of things to patch.
Cost and attention are also real constraints. A red team engagement requires someone on your team to review the findings, correlate them against your detection logs, and drive changes to your tooling and playbooks. Budget for that time alongside the test itself. An engagement that surfaces twelve detection failures and sits in a shared drive helps no one.
Find out what's exploitable before a red team does
Most teams researching red teaming are asking the right question, just one step ahead of where they are. A red team tests whether your detection and response hold up; getting there requires the exploitable paths in your environment to already be known and fixed.
Fencer's AI pen test gets you that baseline on demand. It scopes your environment, probes it the way an attacker would, and delivers confirmed attack chains with the exploit proven end to end, plus an audit-ready report in hours. Findings land in your issue tracker with remediation guidance. When you retest, Fencer confirms the fix is closed.
When your team is ready for a red team engagement, that coverage means the exercise is testing your detection, not your patch backlog. Book a demo or start a free trial to see what your attack surface looks like today.