What a red team actually does.

Most people picture a red teamer as someone in a hoodie typing fast until a screen flashes "ACCESS GRANTED." The reality is closer to a long, patient, heavily documented project that starts with a signed contract and ends with a written report full of recommendations. A red team's job is not to "hack in" — it's to answer one uncomfortable business question honestly: if a real, determined adversary decided to come after us, would we detect them and stop them before they reached the thing that matters?

This is a deep dive into how that question gets answered. If you want the wider map of who attacks, who defends, and how the colors fit together first, our red, blue and purple team breakdown covers that fork; this article assumes you already know red teams are the offensive side and want to see inside an actual engagement — the authorization that makes it legal, the lifecycle it follows, the tools it runs, and what lands on the client's desk at the end.

Objective-based, not vulnerability-based

The defining trait of a red team engagement is that it's built around a goal, not a checklist. Instead of "find every vulnerability," the mandate is something like "prove an attacker could reach the domain controller," "demonstrate the customer database could be exfiltrated," or "show a business email compromise leading to a fraudulent wire transfer is possible." Everything else — which host to compromise, which path to take — is a means to that end.

That single choice changes the whole character of the work. A red team will ignore a hundred real vulnerabilities if none advance the objective, then chain three low-severity misconfigurations a scanner rates "informational" into a full compromise, because that chain is the realistic path. The output isn't a list of findings sorted by CVSS score — it's a story: here is exactly how someone gets from the public internet to your crown jewels, and every place along the way you could have stopped them and didn't.

The word that makes it legal: authorization

Before a single packet is sent, the engagement lives entirely on paper. This is what separates a red teamer from a criminal running identical commands, and it deserves more than a footnote. Unauthorized access to a computer system is a crime almost everywhere — the Computer Fraud and Abuse Act in the US, the Computer Misuse Act 1990 in the UK, and equivalents nearly everywhere. The tools a red team uses are, stripped of context, the same ones a ransomware crew uses. The only difference is explicit, written, informed authorization from someone with the authority to grant it.

That authorization is captured in a scope and a set of Rules of Engagement (RoE), negotiated and signed before anything starts. A serious RoE document typically pins down:

• What is in and out of scope — specific IP ranges, domains, applications, physical sites, and people. Anything not named is off-limits by default, not by omission.
• Which techniques are permitted — is phishing allowed? Physical intrusion? Attacks against third-party or cloud infrastructure the client doesn't own (which the provider must also authorize)? Denial-of-service is almost always excluded.
• Timing and windows — start and end dates, permitted hours, and blackout periods around business-critical events.
• Data handling — what happens to any sensitive data the team touches, how it's stored, and how "proof" is captured without actually stealing real customer records.
• Escalation and abort — a named point of contact, and clear "stop the exercise" conditions if something breaks or a genuine incident is discovered.
• Deconfliction — a way for the blue team or authorities to tell "is this the red team, or a real attacker?" during the engagement.

Operators carry an authorization letter — a "get out of jail free" card — to produce if a guard or a panicking sysadmin catches them mid-exercise. Regulator-driven frameworks standardize all this: the European Central Bank's TIBER-EU framework for threat-intelligence-based red teaming, and testing standards such as NIST SP 800-115. Staying precisely inside the signed boundary — not "close enough" — is a core professional skill, not paperwork to rush.

The shape of an engagement: the attack lifecycle

Once authorized, a red team works through a recognizable lifecycle. Two models describe it. Lockheed Martin's Cyber Kill Chain gives a seven-stage narrative (reconnaissance, weaponization, delivery, exploitation, installation, command-and-control, actions on objectives). MITRE ATT&CK is the more granular and now-dominant model: a living matrix of tactics (the "why" — the attacker's goal at each step) and techniques (the "how"), catalogued from real-world intrusions. Red teams plan and report against ATT&CK because it gives them and the defenders a shared vocabulary. Here's the lifecycle, phase by phase.

Reconnaissance

What happens: the team learns everything it can about the target without touching it — corporate structure, employee names and email formats, exposed infrastructure, technologies in use, leaked credentials. Much of this is pure OSINT. Example: harvesting employee emails and titles from LinkedIn and search engines to build a phishing list, then fingerprinting internet-facing services with a scanner like Nmap or an attack-surface mapper like OWASP Amass (T1589, T1590).

Initial access

What happens: the first authorized foothold inside the perimeter. Example: a spearphishing email carrying a malicious document or link to a consenting user population (T1566), exploiting a vulnerable public-facing web application (T1190), or simply logging in with valid credentials found in a breach dump (T1078). Realistic engagements often prove that the boring option — a reused password — works better than any exploit.

Execution

What happens: the payload runs code on the compromised host. Example: a macro or script launching PowerShell to load the team's implant into memory (T1059.001). This is the moment a well-tuned endpoint detection product should scream — and where the red team learns whether it does.

Command and control (C2)

What happens: the implant "phones home," opening a covert, resilient channel the operator uses to control the host remotely. Example: a beacon that blends into normal traffic by tunneling over HTTPS to a domain that looks legitimate, checking in on a slow, jittered schedule to avoid standing out (T1071.001). C2 is the backbone of the "stay quiet, stay persistent" phase — and choice of C2 framework is one of the most consequential decisions a team makes (more on that below).

Privilege escalation

What happens: turning a normal user's access into administrator or SYSTEM. Example: exploiting an unpatched local vulnerability (T1068), abusing a misconfigured service, or dumping credentials from memory to find a more privileged account (T1003). In Windows/Active Directory environments — where most enterprise red teaming happens — mapping attack paths with BloodHound often reveals a chain of misconfigurations that leads straight to domain admin.

Lateral movement

What happens: hopping from the first host toward the systems that actually hold the objective. Example: reusing a stolen password hash to authenticate to another machine without ever cracking it — a pass-the-hash attack (T1550.002) — or using remote-execution tooling like Impacket across SMB. Persistence (surviving reboots, e.g. via scheduled tasks, T1053) and defense evasion (obfuscation, disabling logging, T1027/T1562) run in parallel throughout every phase, not as a single step.

Actions on the objective, and exfiltration

What happens: the team reaches the agreed goal and proves it, then demonstrates that data could leave. Example: pulling a sample of records from a sensitive repository (T1213) and exfiltrating a marked, non-real "canary" file over the existing C2 channel to prove the path works end to end (T1041) — without ever removing genuine customer data, per the RoE. The proof is the point; the theft never actually happens.

The lifecycle at a glance

"Assumed breach": skipping to the interesting part

Getting that very first foothold can eat weeks and, in a mature target, might never succeed within the engagement window. That's a realistic outcome, but it's an expensive way to discover that the rest of your internal defenses were never tested. So many modern engagements use an assumed breach model: the client deliberately hands the red team a starting position — a standard corporate laptop, a low-privilege domain account, or a planted implant — as if a phishing email had already succeeded.

This isn't cheating; it's economics and realism. Determined attackers eventually get a foothold — the interesting question is what happens next. Assumed breach guarantees the budget tests detection and response across privilege escalation, lateral movement, and exfiltration, rather than burning it all on the front door. It mirrors the threat model most organizations actually face: not "can someone get in?" but "how far can they get before we notice?"

Adversary emulation vs adversary simulation

Not all offensive testing tries to be a specific villain. Two related but distinct approaches sit under the red team umbrella:

• Adversary emulation reproduces the specific tradecraft of a named, real-world threat actor. If your organization is realistically targeted by a group like FIN7 or APT29, the team replicates that group's documented TTPs, in their order, to test whether you'd catch the adversary you're actually likely to face. MITRE's Adversary Emulation Library publishes ready-made plans for exactly this.
• Adversary simulation is broader — exercising realistic attacker behavior in general to test people, process, and technology, without necessarily impersonating one specific group.

Two open-source tools anchor this space. Atomic Red Team is a library of small, self-contained tests mapped to ATT&CK techniques — run one "atomic," check whether your detection fired, move on. MITRE CALDERA automates whole chains of techniques so a full emulation runs largely hands-off. Both are also heavily used by defenders to validate detections — exactly the point where red work turns purple, a loop our SOC roles breakdown shows from the blue side.

The toolbox

Red team tooling clusters around the lifecycle. For reconnaissance: OSINT gatherers, Nmap, Amass, and cloud/attack-surface mappers. For post-exploitation inside a Windows estate: BloodHound for attack-path analysis, credential tooling such as Mimikatz, and Impacket for remote execution.

The centerpiece is the command-and-control (C2) framework — the platform that manages implants, tasks them, and moves data. The commercial standard is Cobalt Strike, so widely used (and pirated by criminals) that detecting its defaults is a defensive cottage industry. That has driven teams toward modern, often open-source alternatives: Sliver (Go-based, cross-platform, free), Mythic (modular, with pluggable agents), and Havoc. The distinction between a classic exploitation framework and a purpose-built C2 matters — our Metasploit vs Sliver comparison walks through how two of them actually differ.

Cutting across all of it is evasion and OPSEC: the discipline of not getting caught. Conceptually that means shaping traffic to look normal, controlling how and when implants call home, minimizing on-disk footprint, and being deliberate about the noise each action generates. Good operators think like the blue team watching them — a red teamer who understands what a SOC analyst sees in their SIEM beats one who just runs tools. Which techniques are acceptable is bounded by the RoE.

Red team vs pentest vs purple team

These three get used interchangeably in job posts, but they're genuinely different activities with different goals.

What you actually get: the deliverables

An engagement is only as valuable as what the client can act on afterward. A strong report has distinct parts. The executive summary answers the business question in plain language for leadership: was the objective achieved, what's the risk, what should change. The attack narrative is the heart of it — a chronological, readable story of the whole intrusion, mapped to ATT&CK with timestamps and evidence, so a defender can replay every step. Crucially, it pairs each attacker action with the corresponding detection opportunity: what the blue team should have seen, and why they didn't.

Then come prioritized recommendations — not just "patch this box," but systemic fixes: tighten this Active Directory misconfiguration, add this detection rule, segment this network, retire this legacy protocol. The best reports feed directly into how the organization decides what to protect and where its weak points are — the same thinking that structured approaches like threat modeling with STRIDE bring to the design phase. Many engagements end with a purple-team debrief and a retest, so the lesson lands on the defensive side instead of gathering dust in a PDF.

How to become a red teamer

Red teaming is not an entry-level job, and treating it as one is the most common beginner mistake. You can't credibly attack systems you don't first understand how to build and defend. The strongest red teamers have real grounding in networking, operating systems (especially Windows and Active Directory), and often some blue-team or sysadmin time. Start with fundamentals, then layer offense on top.

For hands-on practice, hosted labs are the standard on-ramp: Hack The Box and TryHackMe let you exercise the full lifecycle legally, against machines built to be attacked. Build a home lab with a small Windows domain and break it repeatedly.

On certifications, three form a realistic progression. The OSCP (OffSec's PEN-200) is the well-known, hands-on benchmark for offensive fundamentals. From there, red-team-specific certs go deeper into engagement tradecraft: CRTO (Zero-Point Security's Red Team Ops, heavy on C2 and Active Directory) and the PNPT (TCM Security), whose five-day exam ends in a real report and debrief — closer to the actual job than a pure capture-the-flag. Certs open doors; the ability to think through an attack path and write it up clearly keeps them open.

A note on authorization and ethics. Everything in this article describes work done with explicit, signed permission against systems the client owns or is authorized to test. The same tools and techniques used against a system you don't have written authorization for are crimes — full stop, regardless of intent or curiosity. There is no gray area and no "I was just testing" defense. Practice exclusively on systems you own, on deliberately vulnerable labs, or on platforms like Hack The Box and TryHackMe that grant you that permission. The written authorization is not a formality around the job — it is the job.

Frequently asked questions