What Is a Red Team? Offensive Security Explained

Your vulnerability scanner returns a clean report. Your endpoint tool shows no detections. Your SOC dashboard is quiet. None of that tells you whether a determined attacker, given a foothold and a few weeks, could reach your most sensitive data without anyone noticing. A red team exists to answer that exact question by becoming the attacker and finding out.

A red team is a group of security professionals who emulate a real-world adversary against an organization to test how well its people, processes, and technology detect and respond to an attack. They do not just find vulnerabilities. They chain them together the way an actual intruder would, with the explicit goal of reaching a defined objective, such as domain admin or a specific database, while the defenders try to catch them.

This guide covers what a red team is, how a red team engagement works stage by stage, how it differs from penetration testing and from the blue team, what a purple team is, the techniques red teams use, and why the exercise is worth running. It is written for blue teamers who need to understand the discipline that is built to beat them.

What is a red team?

A red team is an offensive security function that simulates the tactics, techniques, and procedures of a realistic threat actor to evaluate an organization's defenses end to end. The name comes from military wargaming, where a "red" force plays the enemy against a "blue" defending force. In security, the red team is the sanctioned adversary, operating under rules of engagement but otherwise behaving like an attacker who wants in.

The defining trait is objective-driven, adversarial testing. A red team is not handed a list of systems and asked to scan them. It is given a goal and a scope, then left to figure out how to achieve that goal the way a criminal or nation-state crew would: quietly, creatively, and across whatever path is weakest. The measure of success is not how many bugs they find but whether they reach the objective and whether the defenders see it happen.

That framing matters because it tests the whole defensive chain, not a single control. A red team engagement answers questions a scan cannot: Does the SOC notice the initial access? Does anyone investigate the alert that fired? How long does it take to respond once they do? Are the runbooks followed? It treats security as an outcome under adversarial pressure, not a checklist.

How a red team engagement works

A red team operation runs through a sequence of phases that mirrors how a real intrusion unfolds. The stages map closely to recognized attacker models such as the cyber kill chain.

1. Reconnaissance. The team gathers information on the target: exposed services, employee names and emails, technologies in use, and anything that widens the way in. Much of this is passive, drawn from public sources before a single packet touches the target.
2. Initial access. They establish the first foothold inside the environment, often through phishing, a vulnerable internet-facing service, stolen credentials, or physical entry. This is the moment the engagement crosses from outside to inside.
3. Establishing a foothold and persistence. Once inside, the team secures reliable access so a single closed connection or reboot does not end the operation, and opens a command and control channel back out.
4. Privilege escalation. They elevate from the access they landed with to higher privileges, such as local administrator or, eventually, domain administrator.
5. Lateral movement. Using that access, they move from the initial host to other systems, hunting for the data, accounts, or systems that lead to the objective. This is where a single compromised laptop turns into a compromised network.
6. Actions on objective. They reach the defined goal: access to a target database, proof of domain dominance, exfiltration of a marked file, or whatever the engagement set out to demonstrate.
7. Reporting. The team documents the full attack path, what worked, what the defenders saw and missed, and concrete recommendations, then walks both the technical and leadership audiences through it.

Throughout, the red team works to stay quiet. Evading detection is part of the test, because an attack the blue team never sees is the worst case an organization can face. The report is the real deliverable. An engagement that proves a path in but produces a vague writeup has failed the people who have to fix it.

Red team vs. penetration testing

Red teaming and penetration testing get used interchangeably, but they answer different questions. A penetration test is breadth-first and vulnerability-focused: find as many exploitable weaknesses as possible in a defined scope within a set window, then report them. It is excellent for assessing the security of a specific application, network segment, or system.

A red team engagement is depth-first and objective-focused. It cares less about enumerating every vulnerability and more about whether a realistic adversary can achieve a goal without being caught. A pen tester might report twelve findings on a web app. A red team might use exactly one of those findings as a doorway, then spend three weeks proving it leads to the crown jewels while the SOC stays silent.

The other major difference is that a red team explicitly tests detection and response. A standard penetration test usually runs with the defenders' knowledge and is not graded on whether anyone noticed. A red team is graded heavily on exactly that. Stealth, dwell time, and the blue team's reaction are core to the assessment, not an afterthought.

Neither is better. They answer different needs. A scoped pen test is the right tool for "is this application secure." A red team is the right tool for "would we actually catch and stop a breach."

Red team vs. blue team

The red team and the blue team are two halves of the same goal seen from opposite sides. The red team attacks. The blue team defends. The red team's job is to get in, move, and reach the objective without being stopped. The blue team's job is to detect, investigate, contain, and evict them.

The blue team is the defensive function most security practitioners work in: SOC analysts, incident responders, threat hunters, and detection engineers who monitor, alert, and respond. Where the red team's success is measured in objectives reached and detections evaded, the blue team's success is measured in how fast and completely it catches and shuts the attack down.

The two are adversaries during an exercise but partners in outcome. The red team is most valuable not when it "wins" but when its findings make the blue team measurably harder to beat next time. Every path the red team takes is a gap the blue team can now close, a detection it can now build, and a runbook it can now rehearse against something real instead of a tabletop scenario.

What is a purple team?

A purple team is not a separate group of people. It is a way of working that fuses red and blue so the two collaborate in real time instead of meeting only at the final report. The name is literal: red plus blue.

In a traditional red team engagement, the red team operates silently and the blue team does not know the details until the debrief. That maximizes realism but slows learning, because the defenders find out weeks later what they missed. A purple team approach trades some of that realism for tighter feedback. The red team runs a technique, the blue team checks whether their tooling caught it, and if it did not, they tune the detection and the red team runs it again until it fires. The loop repeats across many techniques.

Purple teaming is the fastest way to turn offensive findings into defensive improvements. It directly closes the gap between "the attack worked" and "we can now detect it," which is the entire point of testing in the first place. Many mature programs run both: periodic full red team engagements for realism, and ongoing purple team sessions to build and validate detections technique by technique.

Common red team tactics and techniques

Red teams draw on the same playbook as real adversaries, which is why their work translates directly into defensive value. Techniques are commonly organized against the MITRE ATT&CK framework, the globally accessible knowledge base of adversary tactics and techniques based on real-world observations, so that each action maps to a named technique the blue team can hunt for and detect.

• Social engineering. Phishing, pretexting, and impersonation target the human layer, still one of the most reliable ways into an environment. A single clicked link can be all the initial access a team needs.
• Exploitation of vulnerabilities. Turning a known or discovered flaw in an exposed service or application into code execution and a foothold.
• Credential access. Harvesting passwords, hashes, and tokens through dumping, capture, or cracking, then reusing them to authenticate as legitimate users.
• Privilege escalation. Abusing misconfigurations, vulnerable software, or weak permissions to climb from a normal user to administrative control.
• Lateral movement. Pivoting from host to host using stolen credentials, remote execution tools, and trust relationships to expand reach toward the objective.
• Command and control. Maintaining a covert channel from compromised hosts back to the operators, designed to blend into normal traffic and evade detection.
• Defense evasion. Disabling or blinding security tooling, clearing logs, and using legitimate system utilities, so-called living off the land, to avoid tripping alerts.
• Physical and assumed-breach testing. Some engagements include physical entry, while others start from an "assumed breach" position, handing the team an initial foothold to test detection of the post-compromise stages directly.

The point of organizing techniques this way is shared language. When a red team reports that it used a specific technique and the blue team confirms whether it was detected, both sides are talking about the same named behavior, and the result is a concrete, trackable improvement rather than a vague lesson.

Why red teaming matters

Red teaming earns its place by testing what nothing else does: whether the whole defensive program holds up against an adversary who is actively trying to beat it.

It validates detection and response, not just prevention. Scanners and audits tell you what is misconfigured or unpatched. They say nothing about whether your SOC would notice an intruder or how fast it would respond. A red team is the only assessment that grades the people and processes under live pressure.

It finds attack paths, not isolated bugs. Real breaches rarely come from a single catastrophic vulnerability. They come from chaining several modest weaknesses into a route to the goal. A red team thinks in paths, surfacing the dangerous combinations that a vulnerability-by-vulnerability view misses entirely.

It tests realistically. By emulating the tactics of relevant threat actors, a red team gives a far more accurate picture of risk than a theoretical assessment. The result is grounded in how an actual adversary would behave against this specific organization.

It makes the blue team better. Every engagement is a supply of real attack data the defenders can use to build detections, fix gaps, and rehearse their response. A blue team that has been tested by a competent red team is measurably harder to breach than one that has only ever drilled against hypotheticals.

Together these make red teaming less a one-off audit than a forcing function for defensive maturity. It converts the abstract question "are we secure" into the concrete, answerable one: "when someone tries to break in, do we catch them, and what happens next."

Building red team skills

If you want to understand the discipline, learn to think in attack paths and to map every action to how a defender would detect it.

1. Learn the attacker lifecycle. Understand how reconnaissance, initial access, escalation, lateral movement, and actions on objective connect, because a red teamer reasons in chains, not single steps.
2. Study a technique framework. Working knowledge of adversary tactics and techniques is the shared language between offense and defense, and it structures both the attack and the report.
3. Practice in safe environments. Build skill in deliberately vulnerable labs and ranges where offensive techniques can be run legally and the results compared against detection.
4. Always think about detection. The most useful red teamer does not just ask "can I do this," but "what would the blue team see if I did," because that is the question the engagement exists to answer.

The bottom line

A red team is the sanctioned adversary that emulates a real attacker to test whether an organization can detect and stop an intrusion, not just whether it has vulnerabilities. It works objective-first and depth-first, chaining weaknesses into a path to a defined goal while staying quiet, which is what separates it from a breadth-first penetration test and from the defensive blue team it is built to challenge. Run alongside purple teaming, it turns each attack into a detection the blue team can keep. The clean scan and the quiet dashboard never prove you would catch a real intruder. A red team is how you find out before someone else does it for you.