C2 Infrastructure

We all understand the importance of building a resilient Red Team infrastructure that can support long-term operations lasting weeks or even months. Achieving this requires an advanced design based on functional separation, where key components such as the C2 server, phishing infrastructure, payload delivery mechanisms, data exfiltration channels, and backup access points are isolated from one another. This separation ensures that if one part of the infrastructure is detected or compromised, the rest remains unaffected and fully operational, allowing the engagement to continue without disruption.

Redirectors add a protective layer by hiding core systems, while protocol diversity — using HTTPS, DNS, or TCP — adds redundancy and helps avoid detection, increasing the chances of maintaining access throughout the engagement.

In essence, Red Team infrastructure must be designed with the assumption that it will be scanned, investigated, and possibly partially compromised.

One of the most critical components of a Red Team infrastructure is the Command and Control (C2) server. A C2 server is an attacker-controlled system used to communicate with implants (compromised hosts) within a target environment. It functions as the central hub of the operation, sending tasks to the implants and receiving their responses. Modern C2 frameworks typically use asynchronous communication, where implants check in periodically rather than maintaining a constant connection. This approach reduces the network footprint and helps avoid detection by security monitoring tools.

However, discussing C2 would be incomplete without addressing the communication channels — the paths implants use to talk to the C2 server. These channels play a vital role in maintaining stealth and reliability throughout the engagement.

HTTP Channel

The most commonly used control channel is HTTP, primarily because it is ubiquitous across corporate networks. Outbound HTTP traffic is typically allowed by default and rarely raises suspicion, making it an ideal choice for blending into normal network activity within the target environment.

In general, an HTTP/S GET request is used by the implant to check in with the C2 server and retrieve any pending tasks, while an HTTP/S POST request is used to send the results or other data back to the C2 server.

DNS Channel

DNS is commonly allowed for outbound traffic and, more importantly may not be restricted, monitored, or logged making it an attractive communication channel for Red Teams. Since DNS is essential for normal device operation, blocking it is rarely an option in enterprise environments. However, it's important to note that excessive or abnormal DNS traffic can raise red flags for a vigilant SOC analyst.

One advantage of using DNS for Command and Control is its flexibility: the resolved IP address can be easily changed, making it harder for defenders to track infrastructure based on static IPs.

That said, using DNS as a covert communication channel has limitations — each request has a small payload, and transferring data often requires thousands of queries. Despite this, DNS remains a stealthy and effective option for low-bandwidth communication when used carefully.

Typically, data is encoded into subdomain names within DNS queries sent by the implant to a domain controlled by the attacker, allowing covert data exchange through standard DNS traffic.

C2 Tiers

A key aspect of building a robust C2 infrastructure is designing overlapping layers, or tiers, to ensure resiliency. Each tier has its own strengths and weaknesses, but together they work to maintain persistent access to the target network. Typically, these tiers are categorized as:

• Tier 3: Interactive (post-exploitation) — real-time control for active operations.
• Tier 2: Short Haul (short-term) — temporary, fast communication channels.
• Tier 1: Long Haul (long-term) — stealthy, persistent channels designed for extended access.
• Tier 0: Initial - used to deploy tiered C2 infrastructure.

Each C2 tier should be used strictly for its intended purpose to maintain operational security and control. It's important to assign unique communication profiles to each tier, incorporating a variety of protocols and callback intervals to avoid detection. When implants are idle, increasing their sleep timers reduces network noise and exposure. Long-haul tiers should be used to instruct implants to call back to short-haul tiers — never the other way around — to preserve the stealth of persistent access points. Generally, the higher the tier, the faster the callback cycle, but also the greater the risk of detection and compromise.

In this example, the red team operator is communicating with three distinct notional servers, each representing a tier within the C2 infrastructure. These servers are differentiated by their assigned tier roles. The communication between the operator and the C2 servers occurs over persistent SSH connections as the middle ground is attacker-controlled space.

Communication between the target and the C2 infrastructure is represented by dotted arrows. The density of these dots indicates the beaconing frequency of implants in the target environment. Implants communicating with Tier 3 servers beacon at the shortest intervals, as they are used for active post-exploitation tasks. As we move to lower tiers, the beaconing frequency decreases, resulting in longer sleep cycles between callbacks.

This model incorporates diverse communication channels, with each tier geographically and logically separated and using distinct C2 profiles. This separation ensures resilience — losing a single tier does not terminate the engagement, as the red team maintains control within the target environment and can restore or rebuild the lost tier. Implants beaconing to the long-haul (Tier 1) infrastructure can be tasked with spawning new implants that beacon to higher tiers. The blue arrows represent the direction of this spawning process, which should always occur from lower to higher tiers — never in reverse.

Initial - Tier 0

This initial beacon isn't part of a proper tiered setup — it's focused on quickly gaining initial control, then bootstrapping the full C2 infrastructure. Keep in mind:

• The most used protocol with this tier is HTTP/S.
• Uses callbacks at short intervals, typically every 10–30 seconds with jitter.
• Acts as a temporary short-haul channel for initial access.
• Optionally, kill the short-haul beacon if persistence is established
• Inject or spawn a DNS-based long-haul beacon into a low-profile process

Long Haul - Tier 1

The long-haul server is the highest value servers and losing it might end the entire engagement. When working with it, several key precautions should be kept in mind:

• Uses callbacks at intervals over 24 hours with Jitter.
• Designed to be slow and stealthy for regaining lost control, typically using the DNS communication channel.
• Persistence mechanisms typically establish callbacks to long-haul servers to maintain access over time.
• Tier‑1 implants can spawn new implants that beacon to higher tiers.

Short Haul - Tier 2

A fast and direct communication link between a compromised machine (the implant or beacon) and the attacker's server (the C2).

• Often uses HTTP/S.
• More detectable due to predictable and frequent traffic.
• Uses callbacks for communication.
• Commonly 1-24 hour callback cycles.
• Can be used for post-exploitation tasks with sleep cycles of 10-30 seconds.
• Used as a back up to re-establish interactive sessions.

Interactive - Tier 3

Interactive sessions can be established over SMB or HTTP/S, and they typically set the sleep cycle to 0 to allow real-time command execution. For SMB-based sessions, this interactive behavior inherits the short-haul beacon’s sleep configuration, meaning the short-haul enters an active state with no delay between tasks.

In contrast, HTTP/S-based interactive sessions operate independently and do not impact the short-haul beacon’s callback interval. Among the two, HTTP/S interactive sessions are considered more risky, as they generate frequent and observable outbound traffic that can be easily detected by network monitoring tools.

Final word

The previous example assumes a single team server located in one place. However, when building a Command and Control (C2) or Red Team infrastructure, it is common to deploy multiple team servers across different geographic locations. This approach allows greater redundancy, flexibility, and evasion capabilities. In such setups, each tier of the infrastructure can be strategically placed in a different region with diffrent C2 profiles and linked accordingly to distribute risk and improve operational resilience.