The Red Team Infrastructure Wiki: A Blueprint for Resilient Offensive Operations

Hook

When your $50,000 red team engagement gets burned in 48 hours because a single phishing server IP was blacklisted, you realize infrastructure design matters as much as exploit development.

Context

Red team operations historically treated infrastructure as an afterthought—spin up a VPS, install Metasploit, start phishing. This approach created single points of failure where one detected component burned entire operations. Blue teams got smarter about tracking command-and-control (C2) traffic patterns, correlating phishing infrastructure with payload delivery, and building threat intelligence databases that connected disparate indicators.

The Red Team Infrastructure Wiki emerged from this operational reality. Created by Jeff Dimmock (bluscreenofjeff) and the offensive security community, it codified hard-learned lessons about infrastructure compartmentalization, redirector architectures, and operational security. Rather than providing turnkey tools, it documents architectural patterns that separate phishing infrastructure from payload hosting from C2 servers—ensuring that when blue teams burn one component, your active C2 sessions remain intact. Think of it as the infrastructure equivalent of security through obscurity done right: not hiding weak defenses, but making your attack surface so distributed and layered that attribution and takedown become resource-prohibitive for defenders.

Technical Insight

The wiki's core contribution is its emphasis on functional segregation through redirector architectures. Instead of directly exposing your Cobalt Strike or Empire team server, you place multiple layers of redirectors between operators and targets. The simplest implementation uses socat for blind TCP forwarding:

# On your redirector VPS (203.0.113.50)
socat TCP4-LISTEN:443,fork TCP4:10.0.0.5:443

# This forwards all HTTPS traffic to your team server at 10.0.0.5
# When burned, you spin up a new redirector and update DNS
# Your team server IP never touches threat intelligence feeds

This approach is protocol-agnostic but offers no traffic filtering. More sophisticated implementations use Apache mod_rewrite for HTTP/S traffic, enabling conditional forwarding based on user agents, request headers, or URI patterns. The wiki provides extensive mod_rewrite rulesets that filter legitimate C2 callbacks from security scanners:

# Allow only specific user agents (your implant's)
RewriteCond %{HTTP_USER_AGENT} !^Mozilla/5\.0\ \(Windows\ NT\ 10\.0.*AppleWebKit.*Chrome
# Block common security vendors
RewriteCond %{HTTP_USER_AGENT} (bot|crawler|scanner|curl|wget) [NC]
RewriteRule ^.*$ https://legitimate-site.com? [L,R=302]

# Forward valid traffic to team server
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(Windows\ NT\ 10\.0.*AppleWebKit.*Chrome
RewriteRule ^.*$ https://10.0.0.5%{REQUEST_URI} [P]

The architectural principle extends beyond simple forwarding. The wiki details multi-tier redirector stacks: short-haul redirectors for phishing that you expect to burn within hours, long-haul redirectors for C2 that remain stable for weeks, and payload redirectors on CDNs or legitimate cloud services for malware delivery. Each tier serves different operational tempos.

Domain acquisition strategies receive particular attention. Rather than registering fresh domains that scream "newly created infrastructure," the wiki documents techniques for identifying expired domains with established reputations using services like ExpiredDomains.net. The goal is finding domains with clean historical records, existing web categorization (Finance, Healthcare, Technology), and aged WHOIS data:

# Example search criteria for expired domain hunting
# - Registered 5+ years ago
# - Previously categorized as Business/Finance
# - Clean Google Safe Browsing history
# - No existing blacklist entries on Spamhaus/SURBL
# - Existing Archive.org snapshots showing legitimate previous use

This matters because corporate SSL inspection often whitelists Finance/Healthcare categories, and domain reputation services like Cisco Umbrella weight domain age heavily in risk scoring. A 10-year-old expired domain starting clean gives you operational headroom that newdomain2024.com never will.

The wiki also addresses C2 traffic modification—the art of making implant traffic blend with normal web browsing. For Cobalt Strike, this means customizing Malleable C2 profiles to match legitimate services:

http-get {
    set uri "/api/v2/user/profile /api/v2/feed/updates";
    client {
        header "Accept" "application/json, text/javascript";
        header "Referer" "https://legitimate-saas-app.com/dashboard";
        metadata {
            netbiosu;
            prepend "session=";
            header "Cookie";
        }
    }
    server {
        header "Content-Type" "application/json; charset=utf-8";
        output {
            print;
        }
    }
}

This profile makes C2 check-ins look like JSON API calls to a legitimate SaaS application, complete with appropriate headers and cookie-based metadata encoding. Network defenders see what appears to be normal application traffic rather than obvious beaconing patterns.

Gotcha

The wiki's biggest limitation is temporal—much of the content dates from 2016-2017, when the red team landscape looked dramatically different. Domain fronting, presented as a viable C2 channel, was largely killed by AWS and Google in 2018 after abuse reports. The Empire framework, featured prominently throughout, was deprecated in 2019 (though recently revived as BC-Security's fork). Techniques like long-haul domain aging may matter less against modern ML-based traffic analysis that focuses on behavior rather than reputation.

As a documentation resource rather than automation tooling, the wiki requires significant manual implementation effort. You're reading architectural principles and example configurations, not running Terraform scripts that deploy tested infrastructure. This means translating concepts into working code, adapting examples to your specific C2 framework, and handling all the operational details (certificate management, DNS propagation, firewall rules) yourself. For teams expecting Infrastructure-as-Code solutions, the gap between "here's how mod_rewrite filtering works" and "here's a production-ready redirector deployment" is substantial. You'll need existing sysadmin competency to operationalize the guidance—this isn't a tutorial for infrastructure beginners.

Verdict

Use if: You're designing red team infrastructure from first principles and need to understand the 'why' behind architectural decisions like redirector layering and functional segregation. It's invaluable for mid-level offensive practitioners who understand basic operations but lack infrastructure maturity, or for security leaders building defensive detections who need to understand modern offensive infrastructure patterns. The conceptual frameworks around blast radius limitation and operational security through compartmentalization remain relevant regardless of specific tool evolution. Skip if: You need current, ready-to-deploy automation rather than historical reference material, you're operating against cutting-edge EDR/XDR that renders 2017-era techniques obsolete, or you're looking for infrastructure guidance for modern frameworks like Mythic, Havoc, or Sliver rather than Cobalt Strike/Empire. For production deployments, pair this with actively maintained resources like Red Baron or Terraform-based red team infrastructure repos that provide tested automation code.