Red Team Operations: Planning and Execution Guide
A penetration test answers 'can we get in?' A red team operation answers 'can you detect and respond?' These are fundamentally different questions that require different scope, methodology, and reporting. Red team operations simulate a realistic threat actor pursuing defined objectives — obtaining sensitive data, reaching critical infrastructure, achieving domain dominance — over weeks or months, using realistic TTPs drawn from actual threat actor playbooks. The value is not the techniques executed but the detection and response gaps revealed. This guide covers how to plan, execute, and report a red team engagement that produces actionable defensive improvement.
Red Team vs. Penetration Test vs. Purple Team
Organizations frequently conflate these distinct security testing types. Clarity on the differences prevents misaligned expectations.
Penetration test
Finds exploitable vulnerabilities in a defined scope within a defined timeframe. The SOC is typically notified (white box) or not (black box). Output: vulnerability list with severity ratings. The test is concluded when vulnerabilities are found or the timeframe ends. Does not test detection and response. Annual or quarterly cadence.
Red team operation
Simulates a realistic threat actor pursuing defined objectives. The SOC is not notified (the test includes detecting the team as a success criterion). Output: narrative of the attack path, detection gaps, response failures. The test continues until objectives are achieved or the timeframe ends. Tests the full kill chain including post-exploitation. 6-12 month cadence for mature programs.
Purple team exercise
Red and blue teams work together with full transparency. Red team executes specific techniques while blue team observes and attempts detection in real time. Output: ATT&CK coverage map showing which techniques were detected and which were missed. Detection rules are written or updated during the exercise. Accelerates detection improvement faster than a traditional red team but does not test the full detection lifecycle.
When to use each
Penetration tests for compliance and technical vulnerability management. Red team operations for mature security programs testing detection and response capability. Purple team exercises for detection engineering improvement at any maturity level. Red team operations are not appropriate for organizations without a functional SOC — testing detection capability requires something to detect with.
Scoping and Rules of Engagement
The Rules of Engagement (ROE) document is the red team's legal and operational foundation. It must be detailed, mutually agreed, and signed before the engagement begins.
Objectives definition
Define specific, measurable objectives rather than 'compromise the network.' Well-defined objectives: obtain the AD NTDS.dit file, achieve persistent access to the CFO's email, access the production database containing customer PII, reach the SCADA control network. Objectives drawn from realistic threat actor targeting relevant to the organization's threat model.
Scope definition — what is in and out
Define explicitly: which IP ranges, domains, and physical locations are in scope; which systems are explicitly out of scope (production databases that cannot tolerate testing, life-safety systems, customer-facing services during business hours); which attack types are prohibited (DoS, destructive actions, actual data exfiltration of real sensitive data).
Deconfliction procedures
Establish how to distinguish red team activity from real threat actor activity. The deconfliction contact is a small group (CISO, security director) who can verify whether suspected malicious activity is the red team. The deconfliction phone number must be available 24/7 and must be answered — a real incident that cannot be deconflicted triggers a full IR response that burns the engagement.
Notification list
Who knows about the red team engagement? Minimum: executive sponsor, legal counsel, and deconfliction contacts. The SOC and IR team must not know (they are the test subjects). IT operations may need a smaller notification list to prevent inadvertent systems being disrupted. The smaller the notification list, the more realistic the test.
Time constraints and testing windows
Define permitted testing hours, whether 24/7 or business-hours-only. Realistic threat actors operate 24/7; constraining to business hours limits test realism but may be necessary for operational safety. Define hard stop dates and conditions for early termination (real security incident discovered, significant operational impact).
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Threat Actor Profiling: Grounding the Simulation
The most valuable red team simulations are grounded in the TTPs of threat actors relevant to the target organization's industry and threat model. Generic red teaming produces generic findings; threat-actor-specific simulation produces findings relevant to actual risk.
Identifying relevant threat actors
Use MITRE ATT&CK Groups, Mandiant threat actor reports, industry ISACs, and sector-specific threat intelligence to identify which threat actor groups actively target the organization's industry. A healthcare organization should model FIN12 or Vice Society ransomware operations; a financial institution should model APT38 or FIN7.
TTP selection from threat actor profiles
ATT&CK Group profiles list the specific techniques used by each threat actor. Select the subset of techniques most relevant to the organization's environment (Windows-heavy environments mean Windows-specific techniques; cloud-heavy means cloud-specific TTP selection). Red team scenarios should mirror the prioritized technique list.
Intelligence-led red teaming
TIBER-EU and CBEST frameworks formalize intelligence-led red teaming: a threat intelligence provider develops a targeting report profiling the organization's threat landscape before the red team engagement begins. The red team uses this intelligence to develop realistic scenarios. This methodology produces the most risk-relevant findings and is increasingly required for regulated financial sector testing.
Attack Lifecycle Planning
Red team operations follow a structured attack lifecycle aligned to the cyber kill chain and MITRE ATT&CK tactics.
Initial access
The first challenge: getting into the environment. Primary vectors: phishing (most common), external service exploitation, supply chain, or physical access. Plan multiple initial access scenarios — if phishing is detected early, have an alternative. Configure infrastructure (C2 servers, phishing domains) using operational security practices that survive detection and attribution.
Establish persistence
After initial access, establish a persistent foothold before proceeding to objectives — losing the foothold mid-engagement restarts the initial access phase. Persistence mechanisms: registry run keys, scheduled tasks, WMI event subscriptions, implant in startup items. Use multiple persistence mechanisms in case one is discovered and removed.
Discovery and reconnaissance
Internal reconnaissance: enumerate AD, identify privileged accounts and systems, map network topology, identify high-value targets. Use Living-off-the-Land (LotL) techniques where possible — legitimate system tools (net, nltest, PowerShell, WMI) that blend with normal administrative activity and evade signature-based detection.
Credential access and lateral movement
Obtain credentials to move toward objectives. Techniques: credential dumping from LSASS (Mimikatz), AS-REP roasting, Kerberoasting, NTLM relay attacks, credential reuse from password spraying. Move laterally using obtained credentials via RDP, WMI, PsExec, or SMB. Maintain stealth: avoid noisy techniques that trigger threshold-based alerts.
Objective achievement
Execute the defined objectives: reach the target system, access the target data, demonstrate the capability to deploy ransomware (without deploying it). Document each step of the objective achievement path with timestamps, screenshots, and evidence.
Operational Security for Red Teams
Red team operators must avoid detection and attribution during the engagement. Poor OPSEC burns the engagement and produces less realistic findings about the blue team's actual detection capability.
C2 infrastructure
Use purpose-built C2 infrastructure with categorized, aged domains (registered 60+ days before use), valid TLS certificates, and redirectors to hide the true C2 server IP. Cloud-hosted C2 on major providers (AWS, Azure) blends better than dedicated VPS hosting. Use domain fronting or malleable C2 profiles to make C2 traffic appear as legitimate CDN or SaaS traffic.
Living-off-the-Land techniques
Prioritize techniques that use built-in Windows and Linux tools over custom tools. PowerShell, WMI, certutil, mshta, and native network enumeration tools are less likely to trigger EDR detections than custom binaries. When custom tools are required, use process injection into legitimate processes to avoid standalone malicious executable creation.
Timestomping and log evasion
Minimize forensic artifacts: clear PowerShell event logs after execution, use encoded commands to obscure command line arguments, modify file timestamps on dropped tools. Do not clear Security event logs — this is a high-visibility indicator that triggers immediate investigation.
Detection response planning
Plan what to do when (not if) a detection occurs. IR response to red team activity provides valuable data about detection and response capability. When detection occurs, deconflict with the authorized contact, continue from remaining persistence mechanisms, and document the detection timeline for the report.
Reporting: Producing Findings That Drive Change
Red team reports that catalog techniques without explaining business impact fail to drive remediation. Effective red team reports connect technical findings to business risk.
Executive summary
Non-technical narrative of what the red team accomplished, what business impact was demonstrated, and what it would have meant in a real attack. The executive summary should be comprehensible to the board and drive investment decisions. 'The red team obtained domain admin access in 4 days and demonstrated the ability to deploy ransomware to all 15,000 endpoints without triggering an alert' is more compelling than a list of CVEs.
Attack narrative
Chronological narrative of the attack path from initial access through objective achievement. Each step includes: what was done, what TTPs were used, what evidence was found, and what the detection opportunity was. This section is for the security team and should include enough technical detail to enable replay for detection engineering.
Detection gap analysis
Map each phase of the attack to ATT&CK techniques and document whether each technique was detected, alerted on, or missed. This produces an ATT&CK coverage heatmap showing exactly where the detection program has gaps. This section drives the detection engineering workplan.
Prioritized remediation
Remediation items ranked by risk reduction impact, not technical complexity. The fix that would have stopped the engagement earliest should be the top priority — often this is a relatively simple control (MFA on VPN, network segmentation preventing lateral movement, EDR rule for a specific technique) rather than the most technically impressive finding.
The bottom line
Red team operations are the most realistic test of a security program's detection and response capability — but only if the objectives, scope, and methodology are designed to produce actionable findings rather than demonstrate operator skill. The engagement value is proportional to the quality of the defensive improvement it drives: a red team report that results in 20 new detection rules and three architectural changes produced more security value than one that filled binders and changed nothing.
Frequently asked questions
What is a red team operation?
A red team operation is a long-duration (weeks to months) adversary simulation where a team of offensive security specialists attempts to achieve defined objectives (reach sensitive data, achieve domain compromise, demonstrate ransomware deployment capability) using realistic threat actor TTPs. The security operations team is not notified — detecting and responding to the red team is the test. Unlike penetration testing, the goal is not to find vulnerabilities but to test the full detection and response lifecycle.
What is the difference between a red team and a penetration test?
Penetration testing finds exploitable vulnerabilities in a defined scope within a fixed timeframe. The output is a vulnerability list. Red team operations simulate a realistic threat actor pursuing objectives over weeks or months with the SOC unaware. The output is a detection and response gap analysis. Penetration tests are appropriate for vulnerability management; red team operations are appropriate for mature programs testing whether defenders can actually detect and stop sophisticated attacks.
What are rules of engagement (ROE) in a red team?
Rules of engagement define the legal and operational boundaries of the red team engagement: what systems are in scope, what attack types are permitted, what is explicitly out of scope, deconfliction procedures, permitted testing hours, and notification lists. The ROE must be signed by an authorized executive before engagement begins. Without signed ROE, red team activity is indistinguishable from unauthorized access — operators need documented authorization to perform offensive activities.
What is deconfliction in a red team engagement?
Deconfliction is the process of verifying whether suspected malicious activity is the authorized red team or a real threat actor. A small group (CISO, security director) knows the engagement is occurring and can be contacted 24/7 to verify whether a specific IP, domain, or technique is red team activity. Deconfliction is critical — a real incident that triggers an IR response that disrupts the red team engagement wastes both the engagement investment and IR resources.
What is Living-off-the-Land (LotL) in red teaming?
Living-off-the-Land techniques use built-in operating system tools and legitimate software rather than custom malware or attack tools. Examples: using PowerShell, WMI, certutil, mshta, and net commands for reconnaissance, lateral movement, and persistence. LotL techniques are harder to detect because the tools themselves are legitimate — defenders must detect the context and behavior pattern rather than a specific malicious executable. Most sophisticated threat actors and red teams heavily favor LotL to evade EDR signature detection.
How long should a red team engagement last?
A realistic full-scope red team engagement runs 3-6 months. Initial access planning and infrastructure setup take 2-4 weeks before active testing begins. Achieving objectives through realistic, stealthy TTPs takes weeks rather than days — rushing produces a test of whether controls can be bypassed, not whether defenders can detect persistent adversary activity. Shorter engagements (4-6 weeks) are appropriate for narrow-scope objectives or more permissive testing windows. Anything under 2 weeks is effectively an accelerated penetration test rather than a realistic adversary simulation.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.