Architecting Resilient Red Team Infrastructure: Lessons from 4,400 GitHub Stars
Hook
When your phishing campaign gets burned at 2 AM, can you pivot without losing weeks of C2 access? Most red teams can’t—because they built monolithic infrastructure instead of segregated, resilient systems.
Context
Red team operations have historically suffered from a critical design flaw: coupling all functions into single servers. When blue teams detect one phishing email, they’d discover the entire attack infrastructure—SMTP servers, payload hosts, and command-and-control backends all sharing IP space. This meant burning months of access because of a single detection event.
The Red Team Infrastructure Wiki, created to complement Steve Borosh and Jeff Dimmock’s 2017 BSides NoVa talk “Doomsday Preppers: Fortifying Your Red Team Infrastructure,” emerged as the community’s answer to this problem. Rather than providing tools, it aggregates battle-tested architectural patterns for building compartmentalized infrastructure that can withstand active incident response. With over 4,400 stars, it represents collective wisdom from offensive security practitioners who learned these lessons the hard way.
Technical Insight
The wiki’s core architectural principle is functional segregation: separating phishing SMTP, payload delivery, short-term C2, and long-term C2 onto different assets. This isn’t just organizational hygiene—it’s operational survival. When a phishing email gets flagged, you spin up fresh SMTP and payload infrastructure while preserving your C2 channels.
Every backend asset sits behind redirectors—proxy layers that shield team servers from direct target contact. The wiki documents multiple redirector types (SMTP, Payloads, Web Traffic, C2) with various implementation options. For DNS C2, one approach uses socat for UDP forwarding:
# Forward DNS traffic to your team server
socat udp4-recvfrom:53,reuseaddr,fork udp4-sendto:<TEAM_SERVER_IP>:53For more granular control, iptables provides stateful packet filtering:
# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Forward DNS to team server
iptables -I INPUT -p udp -m udp --dport 53 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination <TEAM_SERVER_IP>:53
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPTThe HTTP/HTTPS redirector discussion reveals deeper architectural nuance. The wiki contrasts socat’s simplicity against Apache mod_rewrite’s intelligence. Socat blindly forwards all traffic, while mod_rewrite enables conditional logic—inspecting User-Agent strings, URIs, and headers to route legitimate C2 traffic to team servers while redirecting security scanners to benign sites. This conditional redirection is critical for operational security.
For C2 traffic modification, the wiki covers Cobalt Strike Malleable C2 profiles and Empire listener customization techniques. These aren’t just cosmetic changes—they’re about making your C2 traffic blend into expected network patterns. The guidance on domain selection emphasizes expired domain hunting with tools like expireddomains.net, CatMyFish, and DomainHunter, recognizing that aged domains with clean histories evade categorization-based blocking better than fresh registrations.
The infrastructure automation section links to Terraform-based deployment guides, acknowledging that manual server provisioning doesn’t scale for operations requiring rapid infrastructure rotation. When blue teams start blocking your infrastructure, you need to redeploy clean assets in minutes, not hours.
Gotcha
The wiki’s primary limitation is temporal drift. Created in 2017, some techniques may require validation against current defensive capabilities. The wiki mentions domain fronting in its third-party C2 channels section, but provides no information about current viability or provider restrictions.
This is purely a reference resource, not a toolkit. While it includes some command examples (like the socat and iptables configurations shown above), it primarily curates links to blog posts, tools, and external techniques rather than providing comprehensive executable code. Implementation is entirely on you, which means this wiki assumes intermediate-to-advanced red team experience. Junior practitioners may struggle to translate concepts into working infrastructure without additional guidance. The reliance on external resources also means no guarantees that linked materials remain accessible or current.
Verdict
Use if you’re planning red team engagements requiring resilient, compartmentalized infrastructure that survives active incident response, or if you need to understand why functional segregation and redirector architecture matter operationally. This wiki excels at teaching architectural thinking—the ‘why’ behind infrastructure decisions—which provides foundational value for infrastructure planning. The coverage spans phishing setup, multiple redirector types, C2 traffic modification, domain selection strategies, third-party C2 channels, infrastructure obscuring and securing, and deployment automation. Skip if you need turnkey deployment solutions with comprehensive ready-to-run code, or if you lack the technical depth to implement concepts from reference materials—this won’t hold your hand through setup. Also be prepared to validate that external resources remain current and accessible. For maximum value, treat this as architectural foundation, then supplement with current research and tooling for modern implementations.
