If you’ve ever run a red team engagement off a single VPS with everything crammed onto one box, you already know why infrastructure planning matters. I learned this the hard way early in my career — one flagged domain and an entire two-week engagement’s command-and-control channel was burned by lunchtime. Red team infrastructure isn’t a nice-to-have. It’s the backbone that decides whether your operation looks like a real adversary or gets caught by a $50 threat-intel feed on day one.
In this guide, I’ll walk through how I think about building red team infrastructure from the ground up — the components, the architecture patterns, the operational security (OPSEC) considerations, and the mistakes that trip up beginners. Everything here assumes you’re operating inside an authorized engagement with a signed scope and rules of engagement (RoE). Building or renting infrastructure to attack systems you don’t have permission to test is illegal.
What Is Red Team Infrastructure?
Red team infrastructure is the collection of servers, domains, and services a red team uses to simulate an adversary’s operational footprint during an engagement. It typically includes:
- Command-and-control (C2) servers that manage implants on compromised hosts
- Redirectors that sit between the target and the real C2 server
- Phishing infrastructure — mail servers, landing pages, and payload hosting
- Domain infrastructure with appropriate categorization and aged registration
- Logging and OPSEC monitoring to track what the blue team sees
Unlike a penetration test, where you’re often testing from a single IP with full transparency, red team engagements are designed to emulate real threat actors. That means your infrastructure has to survive scrutiny from EDR, SOC analysts, and network defenders for weeks or months at a time.
Why Infrastructure Planning Matters
A red team’s goal is to measure detection and response capability, not just find vulnerabilities. If your infrastructure gets burned in the first hour because you used a default Cobalt Strike profile or a domain registered five minutes ago, you haven’t tested anything meaningful — you’ve just confirmed that basic threat intel feeds work.
Good infrastructure also protects the client. If a red team server gets compromised by an actual attacker (yes, this happens), it can become a real backdoor into the client’s network. Segmentation and hardening aren’t optional.
Core Components of Red Team Infrastructure
1. Team Servers (C2 Frameworks)
The team server is where operators manage implants, tasking, and loot. Common frameworks include Cobalt Strike, Sliver, Mythic, Havoc, and Brute Ratel. Each has its own traffic profile, malleable C2 configuration options, and detection signatures — so the choice often comes down to what the engagement’s threat model calls for.
2. Redirectors
Redirectors sit in front of your team server and forward traffic, so the target network never talks directly to your real C2 infrastructure. A simple example using a categorized VPS running a reverse proxy:
# Example: socat-based TCP redirector (lab use only)
socat TCP4-LISTEN:443,fork TCP4:teamserver_ip:443
Purpose of this command: socat listens on port 443 of the redirector and forwards every connection to the real team server, so incident responders investigating the traffic only ever see the redirector’s IP, not your actual infrastructure.
A more production-grade approach uses Apache or Nginx with mod_rewrite rules that inspect the User-Agent, URI, and headers, and only forward traffic that matches your malleable C2 profile — everything else gets redirected to a decoy site (a technique often called “domain fronting” fallback or a “dead drop resolver” pattern).
3. Phishing Infrastructure
For engagements that include social engineering, you’ll typically stand up:
- A sending domain with SPF, DKIM, and DMARC configured to maximize deliverability
- A landing page server, often behind its own redirector
- A mailer (Gophish is a popular open-source option for tracking opens/clicks in a lab)
4. Domain and DNS Infrastructure
Domains need to be aged and categorized before use. Freshly registered domains are one of the biggest red flags for automated detection. Many red teams buy “aged” domains months in advance and let them sit with benign content, or purchase expired domains with existing category reputation (verify legally that you’re not infringing on trademarks or prior ownership rights).
5. Logging and OPSEC Monitoring
Every red team infrastructure build should include centralized logging — most operators forward redirector and team server logs to something like an ELK stack or Splunk instance so the whole team can review command history and catch OPSEC violations before the client’s SOC does.
Step-by-Step Methodology for Building a Basic Infrastructure
Here’s a simplified methodology I follow when standing up infrastructure for a lab engagement or CTF-style red team exercise:
- Define the threat model. Decide which actor or TTP set you’re emulating (see our MITRE ATT&CK guide for how to map this properly).
- Register and age domains. Buy domains at least a few weeks before the engagement starts, and put up a plausible, category-appropriate website.
- Provision cloud infrastructure. Spin up VPS instances (different providers for redirectors vs. team servers reduces correlation risk).
- Harden every server. Disable password authentication over SSH, restrict management ports to your VPN or bastion host, and enable firewall rules that only allow expected ports.
- Configure the C2 team server. Install your chosen framework, apply a malleable profile that mimics normal traffic (e.g., mimicking a CDN or common SaaS API).
- Deploy redirectors. Point your C2 domain’s DNS at the redirector, not the team server.
- Set up phishing infrastructure (if in scope). Configure your mail-sending domain’s authentication records and test deliverability against a lab mailbox.
- Centralize logging. Forward logs from every host to a system the whole team can query.
- Test end-to-end. Run a full beacon check-in from a lab victim machine through the redirector to confirm the chain works and traffic looks legitimate.
- Document everything. Keep an infrastructure map for deconfliction with the client’s security team — this is critical so a real incident doesn’t get confused with your simulated one.
Useful Tools and Technologies
| Category | Tools |
|---|---|
| C2 Frameworks | Cobalt Strike, Sliver, Mythic, Havoc, Brute Ratel |
| Redirectors | Nginx, Apache mod_rewrite, socat, Caddy |
| Phishing | Gophish, Evilginx (lab/authorized use only) |
| Domain categorization | Manual submission to vendor category databases |
| Infrastructure automation | Terraform, Ansible |
| Logging | ELK Stack, Splunk, Graylog |
Common Mistakes and Troubleshooting Tips
- Reusing infrastructure across engagements. If a domain or IP was burned on a previous job, threat intel platforms will have it flagged. Always start clean.
- Skipping domain aging. A domain registered yesterday with no content is an instant giveaway to any EDR vendor checking WHOIS age.
- Default C2 profiles. Out-of-the-box Cobalt Strike Malleable C2 profiles are heavily fingerprinted by defenders. Customize your JA3/JA3S hashes and HTTP headers.
- No redirector layer. Pointing the phishing domain directly at your team server means one blocked IP kills the whole operation.
- Poor logging discipline. If you can’t answer “what commands did we run against host X at time Y,” you can’t write a credible report — and you can’t prove you didn’t accidentally cross scope boundaries.
- Ignoring cleanup. At the end of an engagement, tear down infrastructure and revoke credentials; leaving it running is both a security risk and a scope violation.
Security Risks and Defensive Recommendations
From the defender’s side, red team infrastructure techniques map directly to real threat actor behavior, so understanding them helps blue teams build better detections:
- Monitor for beaconing patterns — regular check-in intervals with jitter are a classic C2 signature.
- Inspect TLS certificates for newly issued, oddly named, or self-signed certs on outbound connections.
- Track domain age and reputation using threat intel feeds; flag connections to domains registered in the last 30–90 days.
- Deploy DNS monitoring to catch DNS-based C2 and tunneling.
- Use egress filtering so only approved destinations and ports are reachable from internal hosts.
Frequently Asked Questions
Q1: Do I need Cobalt Strike to build red team infrastructure? No. Open-source frameworks like Sliver and Mythic are fully capable for lab and authorized engagement use, and they’re a great way to learn the concepts without a commercial license.
Q2: How long should a domain be aged before use? There’s no fixed rule, but many practitioners aim for at least 30–90 days with real content and DNS history before using a domain operationally.
Q3: What’s the difference between a redirector and a C2 server? The redirector is the public-facing relay that forwards legitimate-looking traffic; the C2 server is the actual management console operators use. Separating them protects your real infrastructure from discovery.
Q4: Can I practice this without a cloud budget? Yes — a local lab using virtualization (VMware, VirtualBox, or Proxmox) with isolated networks lets you practice the full C2-to-redirector-to-implant chain without spending on cloud infrastructure.
Q5: Is domain fronting still viable? Many major CDN providers have restricted domain fronting in recent years, so it’s less reliable than it used to be. It’s still worth understanding conceptually, but modern red teams lean more on legitimate-looking traffic profiles and categorized domains.
Q6: How do I avoid burning infrastructure mid-engagement? Rotate redirectors if you suspect detection, monitor for blocked connections, and keep a “hot spare” domain and server ready to swap in without disrupting the operation.
Q7: Should the client’s SOC know about the infrastructure in advance? Typically, only a small trusted group (white cell) has visibility, to preserve the integrity of the detection test — but a deconfliction channel must always exist for safety.
Conclusion
Solid red team infrastructure is what separates a realistic adversary emulation from a glorified vulnerability scan. Getting the architecture right — redirectors, aged domains, hardened servers, and disciplined logging — takes real planning, but it’s what lets your team measure detection and response capability instead of just testing whether a single IP gets blocked. Start small in a lab, get comfortable with the C2-to-redirector chain, and build the habit of documenting and tearing down infrastructure properly. That discipline is what makes the difference between a hobbyist setup and infrastructure that can support a genuine red team engagement.
References: MITRE ATT&CK (attack.mitre.org), Cobalt Strike documentation, SANS red team infrastructure whitepapers, vendor documentation for Sliver and Mythic C2 frameworks.
