Red Team Infrastructure: Complete Guide to Setup and Best Practices in 2025

---

Red team infrastructure is the backbone of successful adversary simulation exercises. A well-designed infrastructure provides stealth, resilience, and operational security (OPSEC) while simulating real-world attacker tactics, techniques, and procedures (TTPs). In 2025, building modern red team infrastructure requires balancing automation, security, and adaptability.

This comprehensive guide covers everything from fundamental concepts to advanced implementation strategies, including infrastructure design patterns, automation with Terraform, OPSEC considerations, and real-world deployment examples.

---

What is Red Team Infrastructure?

Red team infrastructure is the collection of systems, servers, domains, and network components used to conduct adversary simulation exercises. It includes everything from command and control (C2) servers and redirectors to phishing platforms and data exfiltration endpoints.

Core Purpose

Red team infrastructure serves to:

• Maintain OPSEC – Hide true attack origins and protect operational assets
• Enable Persistence – Provide reliable, long-term access to target networks
• Support Operations – Facilitate all phases of red team engagements
• Ensure Resilience – Survive detection and defensive responses
• Provide Deniability – Use legitimate services to blend with normal traffic

Why Proper Infrastructure Matters

Without proper infrastructure:

• ❌ Single point of failure compromises entire operation
• ❌ Detection leads to immediate engagement termination
• ❌ Attribution reveals red team assets
• ❌ Lack of redundancy prevents continued operations
• ❌ Poor OPSEC exposes team members and methods

With proper infrastructure:

• ✅ Segmented assets allow continued operations after detection
• ✅ Layered defenses protect true infrastructure location
• ✅ Redundant channels ensure persistent access
• ✅ Professional appearance increases success rates
• ✅ Automated deployment enables rapid adaptation

---

Fundamental Infrastructure Design Principles

1. Segmentation by Function

Critical Concept: Separate infrastructure by purpose to limit blast radius when assets are discovered.

Infrastructure Stages:

Stage 0: Staging/Initial Access

• Purpose: Phishing campaigns, initial payload delivery
• Lifespan: Hours to days
• Expendability: Highly expendable
• Components: Email servers, payload hosting, landing pages

Stage 1: Long-Haul/Persistence

• Purpose: Maintain long-term access
• Lifespan: Weeks to months
• Expendability: Crown jewels – protect at all costs
• Components: Persistence beacons, dormant implants

Stage 2: Interactive/Post-Exploitation

• Purpose: Active exploitation, enumeration, lateral movement
• Lifespan: Days to weeks
• Expendability: Moderately expendable
• Components: Interactive C2 servers, tools distribution

Stage 3: Exfiltration

• Purpose: Data extraction, impact operations
• Lifespan: Hours to days
• Expendability: Expendable after data extraction
• Components: File transfer servers, data staging

2. Defense in Depth with Redirectors

Never expose backend infrastructure directly. Always place redirectors between targets and team servers.

Redirector Benefits:

• Hide true infrastructure IP addresses
• Provide disposable front-end assets
• Enable domain fronting and categorization evasion
• Allow quick infrastructure rotation
• Minimize exposure of critical assets

3. Use of Legitimate Services

Leverage trusted platforms to blend with normal traffic:

• Cloud providers (AWS, Azure, GCP, DigitalOcean)
• CDNs (Cloudflare, AWS CloudFront, Akamai)
• Communication platforms (Slack APIs, Discord webhooks)
• File hosting (AWS S3, Azure Blob, Google Storage)
• Serverless functions (AWS Lambda, Azure Functions)

---

Core Infrastructure Components

1. Team Servers (Command & Control)

Purpose: Central control point for managing compromised assets

Requirements:

• Never directly accessible from internet
• Behind multiple layers of redirectors
• Secure authentication (SSH keys + 2FA)
• Encrypted communications
• Regular backups
• Hardened configuration

Best Practices:

• Use separate team servers for each stage
• Implement strict firewall rules (whitelist only)
• Change default ports and services
• Disable unnecessary services
• Regular security updates
• Log all activities

Popular C2 Frameworks:

• Cobalt Strike
• Mythic
• Sliver
• Havoc
• Empire
• Metasploit

---

2. Redirectors

Purpose: Intermediate servers that forward traffic while hiding backend infrastructure

Types of Redirectors:

HTTP/HTTPS Redirectors:

• Apache mod_rewrite
• Nginx reverse proxy
• Caddy web server
• Traefik proxy

DNS Redirectors:

• Authoritative DNS servers
• DNS-over-HTTPS (DoH) proxies
• DNS tunneling endpoints

Email Redirectors:

• SMTP relays
• Email forwarding services
• API-based email services

Redirector Configuration Principles:

• Filter traffic based on JA3/JA4 fingerprints
• Check User-Agent strings
• Validate request patterns
• Block security scanners
• Implement rate limiting
• Log suspicious activity

---

3. Domain Infrastructure

Purpose: Provide legitimate-appearing domains for operations

Domain Categories:

Short-Term Domains (Staging/Phishing):

• Recently registered acceptable
• Categorized appropriately
• Disposable after campaign
• Examples: phishing landing pages

Long-Term Domains (Persistence):

• Aged domains (1+ years old)
• Good reputation history
• Appropriate categorization
• SSL/TLS certificates
• Examples: long-haul C2 callbacks

Domain Selection Criteria:

• Match target’s technology stack
• Blend with expected traffic patterns
• Pass reputation checks (VirusTotal, URLVoid)
• Appropriate TLD for region/industry
• Not on blocklists

Domain Categorization:

• Submit to categorization services early
• Use keywords matching desired category
• Host legitimate content initially
• Build reputation before operations

---

4. SSL/TLS Certificates

Critical for OPSEC: Modern networks expect HTTPS everywhere

Certificate Options:

Let’s Encrypt:

• Free, automated certificates
• Trusted by all browsers
• 90-day validity
• Perfect for short-term operations

Commercial Certificates:

• Extended validation (EV) possible
• Longer validity periods
• Better for long-term infrastructure

Self-Signed Certificates:

• Only for internal testing
• Will be blocked by most organizations
• No OPSEC value

Certificate Best Practices:

• Always use valid certificates
• Match domain names exactly
• Implement proper certificate chains
• Enable HSTS where appropriate
• Monitor certificate transparency logs

---

Infrastructure Architecture Patterns

Pattern 1: Basic Red Team Setup

Target → Redirector → Team Server

When to Use: Small engagements, limited scope

Components:

• 1 Team Server (C2)
• 1-2 Redirectors (HTTP/HTTPS)
• 1-2 Domains

Cost: $20-50/month

---

Pattern 2: Segmented Operations

Target → [Stage 0 Redirector] → Staging Server (Phishing/Initial)
      → [Stage 1 Redirector] → Long-Haul Server (Persistence)
      → [Stage 2 Redirector] → Interactive Server (Post-Exploit)
      → [Stage 3 Redirector] → Exfiltration Server

When to Use: Standard red team engagements

Components:

• 4 Team Servers (segmented by stage)
• 8-12 Redirectors (2-3 per server)
• 6-10 Domains
• Multiple protocols (HTTP, HTTPS, DNS)

Cost: $100-300/month

---

Pattern 3: Enterprise Red Team Infrastructure

Target → CDN (Cloudflare/CloudFront)
      → Geographic Redirectors (Multiple Regions)
      → Protocol-Specific Redirectors (HTTP/DNS/Email)
      → Backend Team Servers (Segmented by Function)
      → Isolated Management Network

When to Use: Long-term engagements, mature red teams

Components:

• 6-10 Team Servers
• 20+ Redirectors across regions
• 15-25 Domains
• CDN integration
• Backup infrastructure
• Automated deployment

Cost: $500-2000+/month

---

Infrastructure Setup: Step-by-Step Guide

Phase 1: Planning and Design

1. Define Engagement Scope

• Duration (days/weeks/months)
• Target environment characteristics
• Allowed/disallowed techniques
• Budget constraints
• Legal and authorization requirements

2. Design Architecture

• How many stages needed?
• Protocols required (HTTP, HTTPS, DNS, SMB, etc.)?
• Geographic distribution needs?
• Redundancy requirements?
• Automation vs. manual deployment?

3. Select Providers

• Cloud providers (AWS, Azure, GCP, DigitalOcean, Vultr, Linode)
• Domain registrars (Namecheap, GoDaddy, Porkbun)
• CDN services (Cloudflare, AWS CloudFront)
• Certificate authorities (Let’s Encrypt)

---

Phase 2: Infrastructure Provisioning

1. Acquire Domains

# Purchase domains matching engagement requirements
# - Age: Older domains for persistence, new for phishing
# - TLD: Match target's region/industry
# - Keywords: Match categorization goals

# Example domain purposes:
# - updates-microsoft-services.com (phishing)
# - analytics-tracking-cdn.net (C2 beacon)
# - cloud-backup-services.io (exfiltration)

2. Deploy Team Servers

Using DigitalOcean (Example):

# Create droplet for team server
doctl compute droplet create red-team-server \
  --image ubuntu-22-04-x64 \
  --size s-2vcpu-4gb \
  --region nyc3 \
  --ssh-keys YOUR_SSH_KEY_ID

# Harden the server
ssh root@DROPLET_IP
apt update && apt upgrade -y
ufw default deny incoming
ufw default allow outgoing
ufw allow from YOUR_IP to any port 22
ufw allow from REDIRECTOR_IP to any port 50050  # C2 port
ufw enable

# Disable password auth
sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

# Install C2 framework (example: Sliver)
curl https://sliver.sh/install | sudo bash

3. Deploy Redirectors

Apache mod_rewrite Redirector:

# Install Apache
apt install apache2 -y

# Enable required modules
a2enmod rewrite proxy proxy_http ssl headers

# Configure redirector
cat > /etc/apache2/sites-available/redirector.conf << 'EOF'
<VirtualHost *:443>
    ServerName your-domain.com
    
    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/your-domain.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/your-domain.com/privkey.pem
    
    # Enable rewrite engine
    RewriteEngine On
    
    # Block common security scanners
    RewriteCond %{HTTP_USER_AGENT} "(?i)(nmap|nikto|wikto|sf|sqlmap|bsqlbf|w3af|acunetix|havij|appscan)" [NC]
    RewriteRule .* - [F,L]
    
    # Only allow specific User-Agents (example)
    RewriteCond %{HTTP_USER_AGENT} "!^Mozilla" [NC]
    RewriteRule .* - [F,L]
    
    # Proxy legitimate traffic to team server
    ProxyPreserveHost On
    ProxyPass / https://TEAM_SERVER_IP:50050/
    ProxyPassReverse / https://TEAM_SERVER_IP:50050/
    
    # Security headers
    Header always set Strict-Transport-Security "max-age=31536000"
    Header always set X-Content-Type-Options "nosniff"
</VirtualHost>
EOF

# Enable site and restart
a2ensite redirector.conf
systemctl restart apache2

4. Configure DNS

# Point domains to redirectors
# A records → Redirector IPs
# CNAME records → CDNs if using domain fronting

# Example DNS configuration:
# A     @                    1.2.3.4 (redirector)
# A     www                  1.2.3.4 (redirector)
# A     cdn                  5.6.7.8 (CDN IP)
# TXT   @                    "v=spf1 include:_spf.google.com ~all"

5. Obtain SSL Certificates

# Install certbot
apt install certbot python3-certbot-apache -y

# Get certificate
certbot --apache -d your-domain.com -d www.your-domain.com

# Auto-renewal is configured automatically
certbot renew --dry-run

---

Phase 3: OPSEC Hardening

1. Server Hardening

# Disable unnecessary services
systemctl disable bluetooth
systemctl disable cups
systemctl disable avahi-daemon

# Install fail2ban
apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

# Configure automatic security updates
apt install unattended-upgrades -y
dpkg-reconfigure -plow unattended-upgrades

# Implement SSH key-only auth
# (Already done in team server setup)

# Set up monitoring
apt install aide -y
aideinit
mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

2. Network Segmentation

# Implement strict firewall rules
# Only allow:
# - SSH from operator IPs
# - C2 traffic from redirectors
# - Outbound connections as needed

# Example iptables rules
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp -s OPERATOR_IP --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -s REDIRECTOR_IP --dport 50050 -j ACCEPT
iptables -A INPUT -j DROP

3. Traffic Obfuscation

• Use domain fronting via CDNs
• Implement malleable C2 profiles
• Randomize beacon callbacks
• Use legitimate services (Slack, Discord) for C2
• Encrypt all communications

---

Automation with Infrastructure as Code

Why Automate?

Benefits:

• Deploy infrastructure in minutes
• Reproducible configurations
• Version-controlled infrastructure
• Quick teardown after engagements
• Reduced human error
• Consistent security practices

Terraform for Red Team Infrastructure

Example: Basic Red Team Setup

# providers.tf
terraform {
  required_providers {
    digitalocean = {
      source = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

# variables.tf
variable "do_token" {
  description = "DigitalOcean API token"
  type        = string
  sensitive   = true
}

variable "ssh_key_id" {
  description = "SSH key ID"
  type        = string
}

# team-server.tf
resource "digitalocean_droplet" "team_server" {
  image  = "ubuntu-22-04-x64"
  name   = "red-team-server"
  region = "nyc3"
  size   = "s-2vcpu-4gb"
  ssh_keys = [var.ssh_key_id]
  
  user_data = file("./scripts/team-server-setup.sh")
  
  tags = ["red-team", "team-server"]
}

# redirector.tf
resource "digitalocean_droplet" "redirector" {
  count  = 2
  image  = "ubuntu-22-04-x64"
  name   = "redirector-${count.index + 1}"
  region = count.index == 0 ? "nyc3" : "sfo3"
  size   = "s-1vcpu-1gb"
  ssh_keys = [var.ssh_key_id]
  
  user_data = templatefile("./scripts/redirector-setup.sh", {
    team_server_ip = digitalocean_droplet.team_server.ipv4_address
  })
  
  tags = ["red-team", "redirector"]
}

# firewall.tf
resource "digitalocean_firewall" "team_server_fw" {
  name = "team-server-firewall"
  
  droplet_ids = [digitalocean_droplet.team_server.id]
  
  inbound_rule {
    protocol         = "tcp"
    port_range       = "22"
    source_addresses = [var.operator_ip]
  }
  
  inbound_rule {
    protocol         = "tcp"
    port_range       = "50050"
    source_addresses = digitalocean_droplet.redirector[*].ipv4_address
  }
  
  outbound_rule {
    protocol              = "tcp"
    port_range            = "1-65535"
    destination_addresses = ["0.0.0.0/0", "::/0"]
  }
}

# outputs.tf
output "team_server_ip" {
  value     = digitalocean_droplet.team_server.ipv4_address
  sensitive = true
}

output "redirector_ips" {
  value = digitalocean_droplet.redirector[*].ipv4_address
}

Deployment:

# Initialize Terraform
terraform init

# Plan deployment
terraform plan

# Deploy infrastructure
terraform apply -auto-approve

# After engagement, destroy everything
terraform destroy -auto-approve

---

OPSEC Considerations and Best Practices

Critical OPSEC Rules

1. Never Expose Backend Infrastructure

• Always use redirectors
• Never connect directly to team servers from targets
• Maintain strict firewall rules

2. Assume Detection is Inevitable

• Design for resilience, not invisibility
• Segment by function for limited blast radius
• Maintain backup infrastructure

3. Use Disposable Assets

• Treat Stage 0 infrastructure as single-use
• Rotate domains and IPs regularly
• Never reuse burned infrastructure

4. Blend with Legitimate Traffic

• Use appropriate User-Agents
• Match target’s technology stack
• Leverage trusted platforms
• Implement proper SSL/TLS

5. Protect Long-Haul Infrastructure

• High callback times (12-24 hours)
• Multiple redundant channels
• Minimal interaction
• Strong authentication

Common OPSEC Failures

❌ Reusing Infrastructure Across Engagements

• Risk: Attribution, burning entire toolset
• Solution: Fresh infrastructure per engagement

❌ Exposing Team Server IPs

• Risk: Immediate blocking, engagement failure
• Solution: Always use redirectors

❌ Using Default C2 Profiles

• Risk: Signature detection
• Solution: Customize malleable profiles

❌ Poor Certificate Hygiene

• Risk: SSL inspection flags, attribution
• Solution: Valid certificates, proper chains

❌ Inadequate Logging and Monitoring

• Risk: Miss detection, can’t debug issues
• Solution: Comprehensive logging on all systems

---

Advanced Techniques

1. Domain Fronting

Concept: Use CDNs to hide true destination

Target → CDN (legitimate.cloudfront.net)
      → Via Host header, route to evil.com
      → Backend Team Server

CDN Options:

• Cloudflare (limited effectiveness in 2025)
• AWS CloudFront
• Azure CDN
• Google Cloud CDN

Implementation:

# Configure C2 to use domain fronting
# Set Host header to your domain
# SNI to CDN's domain
# CDN routes based on Host header

Note: Many CDNs have restricted domain fronting. Research current effectiveness.

---

2. DNS Tunneling

Use Case: Bypass restrictive firewalls allowing only DNS

Setup:

# Set up authoritative DNS server
# Configure C2 to use DNS protocol
# Encode data in DNS queries/responses
# Subdomains = data channels

Tools:

• dnscat2
• iodine
• dns2tcp

---

3. Living Off the Land (LOL) Binaries

Concept: Use built-in tools for C2 communication

Examples:

• PowerShell web requests
• curl/wget for beacon callbacks
• certutil for file downloads
• bitsadmin for persistence

Benefit: Reduces detection by endpoint security

---

4. Covert Channels

Alternative C2 Communication Methods:

• Social Media APIs – Twitter, Slack, Discord
• Cloud Storage – Dropbox, Google Drive, OneDrive
• Email – Gmail, Outlook APIs
• Gaming Platforms – Steam, Discord
• Pastebin Services – GitHub Gists, Pastebin

Example: Slack C2

# Beacon checks Slack channel for commands
# Posts results back to Slack
# Appears as legitimate business communication

---

Infrastructure Monitoring and Maintenance

What to Monitor

1. Infrastructure Health

• Server uptime and availability
• Resource usage (CPU, RAM, disk)
• Network connectivity
• Certificate expiration dates

2. Security Events

• Failed authentication attempts
• Unauthorized access attempts
• Unusual traffic patterns
• Redirector blocks and filters

3. Operational Metrics

• Beacon callback success rates
• Data exfiltration speeds
• Infrastructure latency
• Detection events

Monitoring Tools

Open Source:

• Prometheus + Grafana
• ELK Stack (Elasticsearch, Logstash, Kibana)
• Zabbix
• Nagios

Cloud Native:

• AWS CloudWatch
• Azure Monitor
• GCP Cloud Monitoring
• DigitalOcean Monitoring

---

Cost Considerations

Budget Breakdown

Small Engagement (1-2 weeks):

• Domains: $20-30
• VPS (3-4 servers): $40-80
• Certificates: $0 (Let’s Encrypt)
• Total: ~$60-110

Standard Engagement (1 month):

• Domains: $50-100
• VPS (8-10 servers): $150-250
• CDN services: $20-50
• Backup infrastructure: $50-100
• Total: ~$270-500

Enterprise Setup (3+ months):

• Domains: $200-300
• VPS (15-20 servers): $400-800
• CDN and premium services: $100-200
• Automation tools: $50-100
• Backup and redundancy: $200-400
• Total: ~$950-1800/month

Cost Optimization

✅ Use spot instances for temporary redirectors
✅ Destroy infrastructure immediately after engagements
✅ Leverage free tiers (AWS, Azure, GCP)
✅ Automate with Terraform to prevent waste
✅ Share infrastructure across team members (with proper isolation)
✅ Use cheaper providers for redirectors (DigitalOcean, Vultr)

---

Legal and Ethical Considerations

Critical Requirements

1. Authorization

• Written authorization from client
• Clear scope definition
• Rules of engagement documented
• Emergency contacts established

2. Data Handling

• Encrypt all exfiltrated data
• Minimize data collection
• Secure deletion after engagement
• Compliance with data protection laws

3. Third-Party Services

• Review cloud provider terms of service
• Understand acceptable use policies
• Consider jurisdiction issues
• Maintain attribution controls

4. Post-Engagement Cleanup

• Delete all infrastructure
• Remove persistence mechanisms
• Wipe team servers
• Archive logs securely

---

Red Team Infrastructure with Parrot CTFs

Professional Red Team Services

Parrot CTFs offers comprehensive red team services including infrastructure setup, adversary simulation, and security validation:

Services Include:

• Custom Red Team Exercises – Full adversary simulation
• Infrastructure Setup Consulting – Design and implementation guidance
• Advanced Persistent Threat (APT) Simulation – Long-term engagement support
• Purple Team Collaboration – Offensive + defensive coordination
• Custom C2 Development – Tailored command and control solutions
• Security Training – Red team techniques and infrastructure management

Why Choose Parrot CTFs for Red Team Operations:

• Experienced offensive security professionals
• Modern infrastructure design patterns
• Automation expertise (Terraform, Ansible)
• OPSEC-focused methodologies
• Comprehensive reporting and debrief
• Post-engagement knowledge transfer

Whether you need a full red team engagement or consulting on building internal red team capabilities, Parrot CTFs provides expert guidance and execution.

Explore Red Team Services

---

Conclusion

Building effective red team infrastructure in 2025 requires balancing automation, security, and operational flexibility. The key principles remain constant:

✅ Segment by function to limit blast radius
✅ Always use redirectors to protect backend infrastructure
✅ Leverage legitimate services for stealth
✅ Automate deployment with Infrastructure as Code
✅ Maintain strict OPSEC throughout operations
✅ Design for resilience, not perfection
✅ Document and improve after each engagement

Modern red team infrastructure is:

• Automated – Deploy in minutes with Terraform
• Segmented – Staged infrastructure by function
• Resilient – Redundant channels and backup infrastructure
• Stealthy – Blend with legitimate traffic
• Ephemeral – Destroyed immediately after engagements

Remember: The goal isn’t to build infrastructure that’s impossible to detect—it’s to build infrastructure that maintains operational capabilities even after partial detection, provides multiple avenues for persistence, and accurately simulates real adversary behavior.

Start simple, iterate often, and always prioritize OPSEC over convenience.

---

Ready to build professional red team infrastructure?

• Need red team services? Contact Parrot CTFs
• Want to learn? Practice in home labs before production
• Automate everything: Master Terraform for infrastructure as code
• Stay updated: Red team tactics evolve—continuous learning is essential

---

Have experience building red team infrastructure or questions about implementation? Share your insights in the comments to help others build effective adversary simulation capabilities.