Continue your mission
A red team operation is a full-scope adversary emulation exercise in which a dedicated attack team simulates the complete lifecycle of a targeted cyberattack against an organization, from initial reconnaissance through objective completion.
# Red Team Operations
A red team operation is a full-scope adversary emulation exercise in which a dedicated attack team simulates the complete lifecycle of a targeted cyberattack against an organization, from initial reconnaissance through objective completion. The goal is not to enumerate vulnerabilities. The goal is to test whether the organization can detect, respond to, and contain a real adversary pursuing a specific objective.
This distinction matters because most security testing stops short of it. Vulnerability assessments enumerate what is exposed. Penetration tests prove that specific vulnerabilities are exploitable. Red team operations do something different: they ask whether a sophisticated, persistent adversary could reach a specific crown jewel, and whether anyone would notice.
The spectrum of offensive security testing, from widest to most realistic:
Vulnerability Assessment: Scan every surface, document every finding, prioritize by severity. Scope is broad. Objectives are enumeration. Realism is low. Time spent on exploitation is minimal. Output is a prioritized list of vulnerabilities.
Penetration Test: Defined scope, defined targets. Exploit specific vulnerabilities to demonstrate impact. Output combines a vulnerability list with evidence of exploitation (screenshots, shell access). More realistic than a scan, but still bounded by scope and time pressure to maximize findings.
Red Team Operation: Defined objective (reach the domain controller, exfiltrate specific data, access the financial system), minimal scope restrictions, and a full adversary lifecycle. The red team is not trying to find every vulnerability. They are trying to achieve the objective by any means available within the rules of engagement. Realism is high. Dwell time is realistic. Detection becomes the variable being measured.
Red team operations live in VSD (Vulnerability and Surface Defense), CDA's ocean layer, because they test the attack surface by attacking it. The Continuous Surface Reduction (CSR) methodology asks: "Every surface you expose is a surface we eliminate." Red team results are the highest-fidelity evidence of which exposed surfaces actually matter to an adversary. Without red team validation, vulnerability management is theoretical prioritization. With it, prioritization is grounded in demonstrated attack paths.
No red team operation starts without a formal rules of engagement (RoE) document. The RoE defines the objective (what crown jewel the red team is targeting), the time window (a 2-week operation is common, though complex engagements run 4 to 6 weeks), the out-of-scope systems and personnel, the notification chain (who within the organization knows the exercise is active), and the escalation procedure if the red team discovers a real intrusion in progress or causes unintended disruption.
The objective drives everything else. Vague objectives like "get admin" produce unfocused engagements and unmeasurable results. Specific objectives produce measurable outcomes: "obtain read access to the Q4 acquisition data stored in the SharePoint finance library" or "authenticate as a domain administrator and extract Active Directory credentials." The executive sponsor approves the objective. The red team pursues it.
The liaison structure protects both the organization and the red team. A small, designated internal liaison (typically the CISO and one security operations contact) knows the engagement is active. The rest of the security team does not. This tests blue team detection authentically because the defenders are not performing differently than they would against a real attack. The liaison is also the escalation contact if the red team needs to pause the exercise.
Red team operations that use random attack tools and generic techniques produce findings that cannot be prioritized. The question they answer ("can we be compromised?") is almost always yes. The useful question is: "Can we be compromised by the specific adversary category that targets our industry, and would we detect it?"
Adversary emulation answers the useful question. The red team selects a threat actor profile relevant to the client's sector and emulates that actor's documented TTPs from MITRE ATT&CK. A financial services firm gets an engagement modeled on APT38 or Lazarus Group TTPs. A healthcare organization gets an engagement modeled on FIN12 (a ransomware affiliate known for targeting healthcare). A manufacturing company facing intellectual property theft risk gets TTPs modeled on APT10 or similar.
The adversary emulation plan documents which ATT&CK techniques the red team will use for each phase of the attack chain. Initial access methods, persistence mechanisms, privilege escalation paths, lateral movement techniques, command and control infrastructure, and exfiltration methods are all selected based on the threat actor profile. The red team is not improvising. They are executing a documented playbook, which makes the exercise repeatable and the results measurable against future engagements.
Reconnaissance. The red team begins with passive and active intelligence gathering. LinkedIn profiles reveal organizational structure and technology stack (job postings advertise the SIEM, EDR, and cloud platforms in use). WHOIS records, Shodan scans, and certificate transparency logs map the external attack surface. This phase runs before the engagement window officially opens and does not touch client infrastructure.
Initial Access. The red team attempts to enter the environment using the techniques documented in the adversary emulation plan. Common initial access vectors: spear-phishing (targeted email with malicious attachment or link), watering hole attacks, exploitation of internet-facing vulnerabilities, or physical access (tailgating, USB drops) if scoped. The phishing payload is crafted to pass through email security controls and match the target organization's communication style.
Persistence. Once inside, the red team establishes persistence so that detection and containment of the initial foothold does not end the exercise. Scheduled tasks, WMI event subscriptions, registry run keys, and implanted user accounts are common persistence mechanisms. The persistence technique is selected from the adversary emulation plan.
Privilege Escalation. From an initial low-privileged foothold, the red team moves toward the privileges needed to reach the objective. Local privilege escalation (exploiting a vulnerable service or misconfiguration to gain SYSTEM or local admin), then lateral movement toward an account with the required domain access.
Lateral Movement. Pass-the-hash, pass-the-ticket, Kerberoasting, and DCOM/WMI remote execution are common lateral movement techniques. The red team moves toward the target system hosting the crown jewel while staying as quiet as possible to test whether the blue team detects the movement.
Objective Completion. The red team reaches the crown jewel and documents the evidence of access: a screenshot of the target file contents, a proof-of-concept data extraction, or a demonstrated authentication to the target system. The operation does not end here; the red team may continue to measure how long it takes the blue team to detect and contain the intrusion.
Red team operations scoped to include physical and social engineering components test the human and physical layers that purely technical engagements miss. Tailgating into a facility (following an employee through a badge-controlled door without badging), vishing (phone calls impersonating IT support to extract credentials), pretexting (building a false identity to manipulate employees into granting access), and targeted spear-phishing are all legitimate red team techniques when defined in the RoE.
The rationale is straightforward: attackers do not restrict themselves to technical vectors when a phone call achieves the same goal in 20 minutes. A red team that never tests the human layer produces findings that overestimate technical defense effectiveness.
Red team operations produce two outputs: an attack narrative and a measurement of the blue team's detection and response performance.
Mean time to detect (MTTD) is the elapsed time from the moment the red team established initial access to the moment the blue team identified the intrusion as a confirmed incident. Mean time to respond (MTTR) is the elapsed time from confirmed detection to containment. These metrics are the primary performance indicators for the TID layer (Threat Intelligence and Defense). A red team engagement that produces an attack narrative without MTTD/MTTR measurement has left the most actionable data on the table.
Detection gaps revealed by the red team become detection engineering priorities (see TID-B01 and TID-H01). The specific techniques that the red team used without triggering a SIEM alert are the inputs to the next detection rule development cycle.
Purple teaming is the collaborative variant where red and blue operate simultaneously with knowledge sharing. The red team executes a technique, confirms whether the blue team detected it, and provides real-time feedback. The blue team tunes detection rules in response, and the red team re-executes to validate the fix.
Purple team operations are more efficient than pure red team engagements for organizations focused on closing detection gaps. They sacrifice some realism (the blue team knows an exercise is running) in exchange for direct, iterative improvement. Red team and purple team serve different purposes: red team measures current state authentically, purple team improves detection coverage rapidly.
Red team operations answer the question that no vulnerability scanner can: "If a competent, motivated adversary targeted us today, would we know?" This is the question every CISO owes their board a credible answer to.
The business impact case for red team operations is grounded in the cost of the alternative. A real attacker who achieves the red team's objective in a real attack has not just reached the crown jewel; they have potentially created a regulatory notification obligation, triggered a breach response, and caused reputational damage. Red team operations find the path before the attacker does, at a controlled cost.
Common misconceptions about red team operations: they are not the same as penetration tests, they are not pass/fail exercises, and they are not evidence that security controls are broken if the red team succeeds. Sophisticated red teams will reach their objective in most engagements against most organizations. The value is in the specificity of the path they took, the gaps they exploited, and the detection failures they revealed.
Board-level reporting on red team results should focus on MTTD (did we detect the intrusion within an acceptable window?), the objective outcome (did the red team reach the crown jewel?), and the remediation priority list that came out of the engagement.
In the Planetary Defense Model, red team operations sit in VSD (Vulnerability and Surface Defense), the ocean layer. The ocean surrounds the core. Red team operations are the most accurate test of how the ocean holds against a real current. They do not just map the ocean's surface; they navigate it under realistic conditions.
CDA's CSR (Continuous Surface Reduction) methodology drives red team scoping: "Every surface you expose is a surface we eliminate." Red team results identify which exposed surfaces an adversary actually traverses, enabling prioritized surface reduction work rather than indiscriminate hardening.
VSD-D04 (adversary emulation / red team operation) is the relevant TOP mission in the DRILL campaign phase. DRILL phase missions test whether the defenses built in BUILD and HARDEN actually hold. VSD-D04 sits alongside VSD-D01 (external penetration test), which tests technical exploitation specifically. The two missions address different questions: VSD-D01 asks "are specific vulnerabilities exploitable?" and VSD-D04 asks "can an adversary reach a specific objective?"
The cross-domain impact of red team findings flows directly into The Shield. VSD scores update based on validated attack paths. TID scores update based on MTTD measurements from the engagement. SPH scores reflect the hygiene gaps (unpatched systems, misconfigured services) that the red team exploited to move laterally. IAT scores reflect privilege escalation and lateral movement success rates. A red team operation is the most comprehensive single-engagement input to a Shield update because it validates multiple domain scores simultaneously.
CDA's approach to red team reporting emphasizes the attack narrative, not just a vulnerability list. An executive does not need to understand Kerberoasting to understand "the red team accessed the financial system in 36 hours from an initial phishing email without triggering a single alert." That sentence updates The Shield, informs the next mission selection in the TOP, and drives budget decisions.
MITRE Corporation. MITRE ATT&CK Framework: Adversary Emulation. https://attack.mitre.org/resources/adversary-emulation-plans/
PTES Technical Guidelines. Penetration Testing Execution Standard. http://www.pentest-standard.org/
Mandiant. M-Trends 2023 Special Report. Mandiant, 2023. https://www.mandiant.com/m-trends
NIST SP 800-115. Technical Guide to Information Security Testing and Assessment. NIST, 2008. https://csrc.nist.gov/publications/detail/sp/800-115/final
CDA, LLC. Planetary Defense Model Master Reference. CDA Canon, 2026.
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.