Red Team Confluence Wiki

Core Concept

Red Team

A Red Team is a group of security professionals that simulate real-world adversaries to test an organization’s security posture. Unlike traditional security testing, Red Teaming is goal-oriented, often aiming to achieve objectives such as data exfiltration, domain dominance, or persistent access while avoiding detection.

Key Characteristics:

• Adversary Emulation: Mimics specific threat actors, their tactics, techniques, and procedures (TTPs).

• Full-Scope Testing: Includes social engineering, physical security, network exploitation, and more.

• Focus on Evasion: Red Teams attempt to bypass security controls and operate undetected.

• Real-World Attack Scenarios: Unlike vulnerability assessments or penetration tests, Red Teaming tests detection and response capabilities.

Red Team vs Penetration Test vs Vulnerability Assessment

Red Team Assessment: A goal-based adversarial simulation that emulates a real-world attack using the full spectrum of TTPs against all organizational attack surfaces (technical, physical, social) to test detection and response capabilities. It focuses on achieving specific objectives while avoiding detection.

Penetration Test: A focused technical assessment that identifies and exploits vulnerabilities in specific systems, networks, or applications to determine their exploitability and potential impact. It aims to find and validate as many vulnerabilities as possible within a defined scope.

Vulnerability Assessment: A systematic review to identify, classify, and prioritize vulnerabilities in systems, applications, and network infrastructure. It focuses on discovery and documentation without actually exploiting the vulnerabilities.

Feature	Red Teaming	Penetration Testing	Vulnerability Assessment
Objective	Simulate a real-world adversary attack	Identify and exploit security weaknesses	Identify vulnerabilities and misconfigurations
Scope	Broad, covers multiple attack vectors	Focused on specific systems/applications	Comprehensive review of vulnerabilities
Methodology	Adversary tactics, stealth, long-term persistence	Exploit known vulnerabilities to gain access	Identify and report vulnerabilities without exploitation
Testing Approach	Full-scope (physical, cyber, social engineering)	Controlled environment, usually black/gray box	Automated and manual scanning
Timeframe	Weeks to months	Days to weeks	Typically a short-term engagement
Stealth Required?	Yes, must avoid detection	No, detection not a primary concern	No, focuses on identification
Security Team Involvement	Tests Blue Team’s response & SOC capabilities	Security team may or may not be aware	Security team involved in patching
Deliverables	Executive report, technical findings, MITRE ATT&CK mapping	List of exploitable vulnerabilities, risk ratings	List of vulnerabilities, risk scores, recommendations
Best For	Testing an organization's full security maturity	Assessing security posture of specific assets	Continuous vulnerability management

OPSEC

OPSEC is a process that identifies critical information to determine if actions can be observed by adversaries, determines if information obtained by adversaries could be harmful, and then executes measures to eliminate or reduce vulnerabilities.

In red teaming, OPSEC refers to the practices and procedures used by the red team to protect their activities from detection by the blue team or other security monitoring systems. This includes:

• Infrastructure compartmentalization: Separating attack infrastructure to minimize correlation and attribution
• Communication security: Using encrypted and out-of-band channels for team communications
• Attribution obfuscation: Masking the true source of attacks
• Traffic patterns management: Ensuring red team activities mimic expected patterns or blend with normal traffic
• Tool selection and modification: Using custom tools or modifying existing ones to avoid signature detection
• Operational tradecraft: Methodologies to minimize digital footprints and artifacts
• Data sanitization: Removing identifying metadata from files and communications

Proper OPSEC is crucial for red teams as premature detection can invalidate assessment results and fail to accurately test the organization's true detection capabilities.

Attack Life Cycle

The attack lifecycle refers to the phases an adversary follows to achieve their objective, such as initial access, privilege escalation, lateral movement, and exfiltration. Various cybersecurity frameworks outline these steps:

1. Cyber Kill Chain (Lockheed Martin)

Attack life cycles are models that describe the sequence of steps attackers typically follow when compromising an organization.

Cyber Kill Chain (Lockheed Martin)

A 7-stage model describing the structure of an attack:

1. Reconnaissance: Gathering information about the target
2. Weaponization: Coupling exploits with backdoors into deliverable payloads
3. Delivery: Transmitting the weapon to the target environment
4. Exploitation: Triggering the attacker's code in the target environment
5. Installation: Installing malware or backdoor on the asset
6. Command & Control (C2): Establishing persistent remote control over the victim
7. Actions on Objectives: Executing the intended goals of the intrusion

Mandiant's Attack Lifecycle (now expanded to 8 phases)

Describes how targeted attacks unfold:

1. Initial Reconnaissance: Identifying targets and gathering intelligence
2. Initial Compromise: First breach of the target environment
3. Establish Foothold: Setting up persistent access
4. Escalate Privileges: Obtaining higher-level permissions
5. Internal Reconnaissance: Mapping the internal environment
6. Lateral Movement: Moving through the network to reach objectives
7. Maintain Presence: Ensuring continued access
8. Complete Mission: Achieving the attack objective (data exfiltration, destruction, etc.)

Red teams use these models to structure their activities and ensure their simulations accurately reflect real-world attack methodologies. They also provide a framework for organizations to understand where they need to implement defensive controls.

Engagement Planning

Engagement Planning forms the critical foundation of any successful red team operation. This comprehensive preparation phase ensures the exercise delivers meaningful security insights while managing risks effectively.

The scope definition establishes clear boundaries for the assessment. Rather than simply listing systems as "in-scope" or "out-of-scope," proper scoping involves detailed discussions with stakeholders to understand business-critical assets, system interdependencies, and potential impact concerns. Technical boundaries must account for network segments, cloud environments, third-party integrations, and data flows. Physical location scoping requires consideration of access controls, sensitive areas, and safety concerns. The scope should also clearly articulate whether social engineering is permitted and which personnel groups may be targeted.

Threat modeling transforms the exercise from generic testing into a realistic simulation of relevant adversaries. Security teams analyze their organization's threat landscape to identify the most likely threat actors based on industry, geography, and data types. This involves researching actual TTPs employed by these adversaries, often leveraging intelligence reports and frameworks like MITRE ATT&CK. The red team can then map these capabilities against the organization's attack surface, prioritizing likely vectors and creating a campaign that mirrors real-world attacks the organization might face.

The breach model determines how the red team will establish initial access. This could range from a purely external assessment (starting with no access) to an assumed breach scenario (where some level of access is granted at the start). Organizations often select breach models that align with their most concerning threat scenarios. For example, a financial institution might focus on external breach scenarios, while a defense contractor might prioritize insider threat models. The breach model significantly impacts the engagement's timeline, required resources, and potential findings.

Notification and announcement strategies require careful balancing of operational realism against organizational risk. Full knowledge tests (where defenders know an exercise is occurring) sacrifice some realism but reduce business disruption risk. Limited knowledge tests restrict awareness to key personnel, while no-knowledge tests maximize realism but require robust emergency procedures. Most organizations implement a tiered notification approach with executives and key stakeholders aware of the general timeframe, while specific defensive teams remain uninformed. This approach requires developing communication plans for different scenarios, including potential business disruption events.

Rules of Engagement (ROE) serve as the authoritative governance document for the entire exercise. Beyond simply listing permitted techniques, comprehensive ROE define operational parameters including hours of operation, blackout periods (such as financial close periods or major business events), approval chains for high-risk activities, data handling protocols, and detailed escalation procedures. The ROE document should be treated as a legally binding agreement, signed by executive stakeholders, red team leadership, and legal representatives. It establishes liability boundaries and protections for both the organization and the red team members.

Record keeping and deconfliction processes prevent red team activities from causing unintended consequences. This includes maintaining detailed logs of all testing activities with timestamps, affected systems, techniques used, and results obtained. These records prove invaluable if an incident occurs or if findings are questioned. Deconfliction mechanisms ensure red team activities don't conflict with legitimate security operations, other planned testing, or critical business functions. This typically involves establishing secure communication channels with a limited set of organizational contacts who can verify if observed anomalies are exercise-related.

Data handling frameworks address the potential exposure of sensitive information during testing. Red teams often encounter confidential data, intellectual property, or regulated information. Proper protocols define how such data should be documented (often using representative samples rather than actual data), how findings should be stored (usually encrypted and access-restricted), and how data should be securely destroyed post-engagement. These protocols must align with organizational compliance requirements and regulatory frameworks.

Duration planning extends beyond simply setting start and end dates. Effective timeline development involves mapping distinct phases (reconnaissance, initial access, privilege escalation, etc.) with realistic timeframes for each, incorporating buffer periods for unexpected challenges, and establishing clear milestones with stakeholder checkpoints. The duration should reflect the complexity of the environment and the sophistication of the simulated adversary, with advanced persistent threat simulations often spanning weeks or months to properly emulate realistic dwell times.

Resource allocation encompasses the people, technology, and infrastructure needed for success. Team composition should align with the required skill sets for the selected threat model, potentially including specialists in network penetration, social engineering, physical security, or specialized technologies. Technical resources include not only testing tools and software licenses but also infrastructure such as command and control servers, VPS hosting, domain registrations, and secure communication channels. Proper resource planning also addresses training needs if specialized skills are required for the engagement.

Post-Engagement and Reporting

Post-Engagement and Reporting transforms raw technical findings into meaningful security improvements. This phase elevates the exercise from a point-in-time test to a catalyst for organizational security maturation.

Evidence collection involves systematically gathering, organizing, and preserving all artifacts from the engagement. This includes not only screenshots of compromised systems but also tool outputs, network captures, command logs, system artifacts, and defensive alerts triggered. The evidence must maintain a clear chain of custody and be collected in a forensically sound manner. This comprehensive collection allows for detailed reconstruction of events and provides verification of findings if questions arise later.

Attack narratives translate technical details into compelling stories that illustrate security weaknesses. These narratives chronologically document the red team's journey, from initial access attempts through persistence, privilege escalation, lateral movement, data discovery, and objective achievement. Effective narratives highlight not only successful techniques but also failed attempts and the process of discovery that led to success, providing defenders with insight into attacker methodology. By structuring these narratives around the ATT&CK framework, security teams gain context about how the observed behaviors relate to real-world threats and can better prioritize defensive improvements.

For example, rather than simply stating "The team exploited a vulnerable web application," a proper attack narrative would explain: "After discovering an outdated instance of Application X through passive reconnaissance, the team exploited CVE-2023-12345 to establish a foothold with limited user privileges. The team then identified misconfigured service accounts through local enumeration, leveraging these to escalate privileges and deploy a persistent backdoor that communicated through encrypted channels mimicking normal HTTPS traffic. This access enabled lateral movement to the financial database server through pass-the-hash techniques, ultimately extracting 250MB of simulated customer financial records over a three-day period without triggering existing monitoring systems."

Recommendations transcend simplistic vulnerability remediation to address systemic security gaps. Strategic recommendations focus on architectural improvements, security program enhancements, and long-term capability development. Tactical recommendations address specific vulnerabilities, misconfigurations, and technical controls. Procedural recommendations enhance detection capabilities, incident response workflows, and security operations. Effective recommendations provide clear implementation guidance with specific technologies, configuration changes, or process improvements rather than vague directives. Each recommendation includes a priority rating based on exploitation difficulty and potential impact, along with implementation complexity estimates and validation methods to confirm successful remediation.

Indicators of Compromise (IoCs) document the technical fingerprints left by the red team that mimic actual attacker artifacts. These include file hashes of tools and payloads, network indicators such as IP addresses and domain names used in command and control, host-based artifacts including registry modifications and file system changes, and process indicators such as command line parameters and service creations. These IoCs serve dual purposes: they allow the organization to verify if similar activities have occurred previously (indicating potential real compromises) and provide valuable detection content for security tools. Advanced red teams often develop custom YARA or Sigma rules alongside IoCs to enhance detection capabilities.

The reporting structure typically includes multiple documents tailored to different audiences. The executive summary translates technical findings into business risk terms, focusing on critical exposure areas, potential business impacts, and strategic recommendations. This document avoids technical jargon and focuses on governance, investment, and security program maturity. The technical report provides comprehensive details for security practitioners, including methodologies, tools, techniques, evidence, and detailed remediation steps. Many organizations also benefit from a remediation roadmap that sequences fixes based on risk, complexity, and dependencies, providing a practical implementation plan for addressing findings.

Debrief sessions facilitate knowledge transfer beyond written reports. Executive briefings focus on business risk and strategic improvements. Technical debriefs walk security teams through attack methodologies and defensive failures, often including demonstrations of key techniques. Purple team sessions bring red and blue teams together to review detection gaps and improve monitoring capabilities. These interactive sessions allow defenders to ask questions, understand nuances, and develop deeper insight than reports alone can provide.

Remediation support extends the engagement's value through the improvement cycle. Rather than simply delivering findings and departing, effective red teams remain available during the remediation phase to clarify techniques, validate fixes, and provide technical guidance. Some organizations implement a phased verification approach where the red team retests specific findings after remediation to confirm effectiveness. This ongoing partnership ensures that security improvements actually address the underlying issues rather than implementing superficial fixes that attentive attackers could easily bypass.

TTP

TTPs are the patterns of activities and methods associated with specific threat actors or groups of threat actors. They represent how attackers operate and provide a framework for understanding, documenting, and communicating about attacker methodologies.

• Tactics: The high-level description of an attacker's objective or goal. Tactics represent the "why" of an attack technique (e.g., initial access, privilege escalation, lateral movement).
• Techniques: The specific methods used by adversaries to achieve tactical goals. Techniques represent the "how" of an attack (e.g., spear phishing, pass-the-hash, living off the land).
• Procedures: The detailed implementation of techniques. Procedures represent the exact steps, tools, and operational practices that adversaries use when executing techniques (e.g., specific malware variants, particular command sequences, custom scripts).

TTPs are important in red teaming for several reasons:

• They enable realistic emulation of specific threat actors relevant to the organization
• They provide a common language for describing attack methodologies
• They help organizations prioritize defenses based on actual attack patterns
• They allow for mapping of defensive controls to specific adversary behaviors

Red teams select and implement TTPs based on threat intelligence about adversaries targeting the organization's industry or geographic region, creating more realistic and valuable security assessments.

ATT&CK

MITRE ATT&CK is a globally-accessible knowledge base and framework that catalogs adversary tactics and techniques based on real-world observations. It serves as a comprehensive, structured representation of attacker behaviors, spanning the entire attack lifecycle.

Key characteristics of the ATT&CK framework:

• Structure: Organized hierarchically into Tactics (categories of technical objectives), Techniques (methods to achieve tactical goals), and Sub-techniques (specific implementations of techniques)
• Matrices: Different matrices for various environments:
  • Enterprise (Windows, macOS, Linux)
  • Mobile (iOS, Android)
  • ICS (Industrial Control Systems)
  • Cloud (AWS, Azure, GCP, SaaS)
• Additional Components:
  • Groups: Known threat actors and their associated TTPs
  • Software: Tools, malware, and utilities used by threat actors
  • Mitigations: Defensive measures mapped to specific techniques
  • Data Sources: Telemetry types useful for detecting techniques
• Use in Red Teaming:
  • Provides a common vocabulary for describing attack behaviors
  • Enables creation of threat-informed scenarios based on real adversaries
  • Facilitates documentation of testing coverage and gaps
  • Allows mapping of defensive capabilities to specific attack techniques
  • Supports reporting that connects findings to real-world threat behaviors

ATT&CK has become the de facto standard for describing adversary behavior in the security industry. Red teams use it to plan, execute, and document their operations, ensuring assessments are grounded in real-world attack methodologies and providing organizations with actionable intelligence about their security posture relative to actual threats.

External Reconnaissance

External reconnaissance represents the critical intelligence-gathering phase where threat actors (and red teams emulating them) collect information about target organizations without directly engaging their systems. This phase establishes the foundation for subsequent attack stages by mapping the attack surface, identifying potential vulnerabilities, and gathering intelligence on organizational structure and personnel. 

It is typically divided into two categories:

1. Passive Reconnaissance (OSINT)

2. Active Reconnaissance

OSINT

DNS

whois

Social Media

Official Website

Passive Subdomain Enumeration

Dorking

Active Reconnaissance

Port Scan

Directory Bruteforce

Initial Access

Password-based Attack

Phishing

Exploit Public-facing Service

Valid Account

Supply Chain Pollution