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 isforms the systematiccritical processfoundation of preparingany for asuccessful red team operation. ItThis createscomprehensive preparation phase ensures the foundationexercise delivers meaningful security insights while managing risks effectively.

The scope definition establishes clear boundaries for the engagement'sassessment. successRather 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 ensurespotential alignmentimpact withconcerns. organizational objectives. Key components include:

• Scope Definition:
  • Clearly defining technicalTechnical boundaries (networks,must systems,account applications)
  for
  • Identifyingnetwork physicalsegments, locationscloud includedenvironments, inthird-party testing
  integrations,
  • Determiningand ifdata 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
  • Establishingand excludedwhich systemspersonnel (e.g.,groups production-criticalmay infrastructure)
  be
  targeted.

• Threat Modeling:modeling

  transforms
  • Identifyingthe 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
  types.
  • ResearchingThis involves researching actual TTPs ofemployed selectedby adversaries
  these
  • Mappingadversaries, potentialoften leveraging intelligence reports and frameworks like MITRE ATT&CK. The red team can then map these capabilities against the organization's attack surfacessurface, 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 threat capabilities

  • Prioritizing likely attack vectors
• Breach Model:
  • Determining the initial access scenario (e.g., external attacker, malicious insider)
  • Definingan assumed breach parametersscenario if(where applicable
  some
  • Establishinglevel initialof access limitationsis orgranted advantages
  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:announcement

  strategies
  • Determiningrequire whocareful willbalancing beof 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 exercisegeneral (fulltimeframe, knowledge,while limitedspecific knowledge,defensive noteams knowledge)
  remain
  • Creatinguninformed. This approach requires developing communication templatesplans for stakeholders
  different
  • Establishingscenarios, emergency notification procedures
  • Planning forincluding potential business disruption communications
  events.

• Rules of Engagement (ROE):

  serve
  • Documentingas the authoritative governance document for the entire exercise. Beyond simply listing permitted andtechniques, prohibitedcomprehensive techniques
  ROE
  • Definingdefine operational parameters including hours andof operation, blackout periods
  • Establishing(such as financial close periods or major business events), approval processeschains for high-risk activities
  activities,
  • Creatingdata handling protocols, and detailed escalation proceduresprocedures. 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 securityboth incidents
  the
  • Identifyingorganization pointsand ofthe contactred forteam variousmembers.
    scenarios

• Record Keepingkeeping &and Deconfliction:deconfliction

  processes
  • Establishingprevent logging requirements for allred team activities
  • Creatingfrom protocolscausing tounintended avoidconsequences. conflictsThis includes maintaining detailed logs of all testing activities with othertimestamps, 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 testing
  operations,
  • Implementingother changeplanned managementtesting, procedures
  or
  • Settingcritical upbusiness functions. This typically involves establishing secure communication channels with securitya operations
  limited
  set
of
• organizational contacts who can verify if observed anomalies are exercise-related.

  Data Handling:handling

  frameworks
  • Definingaddress the potential exposure of sensitive information during testing. Red teams often encounter confidential data, intellectual property, or regulated information. Proper protocols fordefine sensitivehow such data discoveryshould be documented (often using representative samples rather than actual data), how findings should be stored (usually encrypted and handling
  access-restricted),
  • Establishingand secure storage for engagement artifacts
  • Creatinghow data destructionshould proceduresbe securely destroyed post-engagement
  engagement.
  • ImplementingThese encryptionprotocols must align with organizational compliance requirements forand teamregulatory communications
  frameworks.

  Duration

planning
• Duration:extends
  beyond
  • Settingsimply setting start and end dates. Effective timeline development involves mapping distinct phases (reconnaissance, initial access, privilege escalation, etc.) with realistic timeframes for differenteach, phasesincorporating (planning,buffer execution,periods reporting)
  for
  • Establishingunexpected challenges, and establishing clear milestones andwith checkpoints
  stakeholder
  • Planningcheckpoints. forThe potentialduration extensionsshould basedreflect onthe findings
  complexity
  of
the
• Resource Costs:
  • Team compositionenvironment and personnelthe requirements
  sophistication
  • Hardwareof 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 needs

  needed
  • Softwarefor licensingsuccess. andTeam toolingcomposition costs
  should
  • Externalalign servicewith requirementsthe (VPS,required domains,skill etc.)
  sets
  • Trainingfor the selected threat model, potentially including specialists in network penetration, social engineering, physical security, or specialized skilltechnologies. acquisition
  Technical
  resources
include

not

Effectiveonly engagementtesting tools and software licenses but also infrastructure such as command and control servers, VPS hosting, domain registrations, and secure communication channels. Proper resource planning ensuresalso addresses training needs if specialized skills are required for the red team assessment delivers maximum value while minimizing operational risks and unintended consequences.engagement.

Post-Engagement and Reporting

Post-Engagement and Reporting referstransforms to the activities following the active testing phase of a red team engagement. This phase is critical for translating theraw technical findings into actionable intelligence and value for the organization. Key components include:

• Evidence Collection and Preservation: Compiling and organizing all data, screenshots, logs, and artifacts gathered during the engagement
• Attack Path Reconstruction: Documenting the complete attack chains from initial access to objective completion
• Attack Narratives:
  • Chronological storytelling of the attack progression
  • Detailed walkthroughs of successful attack paths
  • Description of attempted but unsuccessful approaches
  • Mapping of techniques to the ATT&CK framework
  • Explanation of how defenses were bypassed or triggered
• Finding Classification: Categorizing issues by severity, exploitability, and potential business impact
• Root Cause Analysis: Identifying underlyingmeaningful security weaknessesimprovements. beyondThis individualphase vulnerabilities
• Recommendations:
  • Strategic improvements to security architecture
  • Tactical changes to configurations and controls
  • Procedural enhancements for detection and response
  • Prioritized remediation guidance based on risk
  • Implementation difficulty ratings for suggested fixes
  • Validation methods to confirm successful remediation
• Indicators of Compromise (IoCs):
  • File hashes for tools and payloads used
  • Network indicators (IPs, domains, URLs)
  • Host-based artifacts and forensic evidence
  • Registry keys and configuration changes
  • Command line parameters and scripts
  • YARA or Sigma rules for detection
• Report Development:
  • Executive Summary: High-level overview of findings and implications for leadership
  • Technical Report: Detailed documentation of methodologies, findings, and technical details
  • Metrics and Scorecards: Quantitative measures of security posture
• Debrief Sessions: Presenting findings to different stakeholders:
  • Executive briefing for leadership
  • Technical debrief for security teams
  • Purple team sessions with defenders to review detection gaps
• Remediation Support: Providing guidance duringelevates the fixing of identified issues

Effective post-engagement activities and reporting transform the red team exercise from a point-in-time assessmenttest to a catalyst for lastingorganizational 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

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