Command and Control Infrastructure Setup

In red team operations, establishing a robust command and control (C2) infrastructure is the backbone of simulating real-world adversaries. Without it, you cannot maintain persistent access, execute objectives, or evade detection effectively. Mastering C2 setup allows you to test an organization's defenses from an attacker's perspective, revealing critical security gaps that might otherwise go unnoticed.

Understanding Modern C2 Frameworks

Your first step is selecting the right tool for the job. Cobalt Strike is a commercial, feature-rich framework widely used for adversary simulation and red teaming. It offers a graphical user interface, extensive scripting capabilities, and built-in techniques for post-exploitation. In contrast, Sliver is an open-source alternative known for its cross-platform compatibility and simplicity, making it ideal for operators who prefer command-line efficiency. Another notable option is Covenant, a .NET-based framework that emphasizes collaboration through a web interface, allowing multiple operators to manage implants simultaneously. Each framework has its strengths: Cobalt Strike excels in maturity and integration, Sliver in agility and cost, and Covenant in customizability for .NET environments. As a red teamer, you should choose based on operational requirements, such as target environment, team size, and desired stealth level.

These frameworks operate on a client-server model where the C2 server listens for connections from implants, called beacons, deployed on compromised systems. Beacons periodically call back to the server to receive commands and exfiltrate data. Understanding this architecture is crucial because it dictates how you design communication channels. For instance, Cobalt Strike uses malleable C2 profiles to customize beacon behavior, while Sliver employs implant profiles to define communication protocols. By grasping these fundamentals, you can better configure your infrastructure to mimic advanced persistent threats, thereby providing a realistic assessment of defensive capabilities.

Deploying Your C2 Server and Beacons

Deployment begins with setting up your C2 server, typically on a cloud virtual private server (VPS) or a dedicated machine under your control. For Cobalt Strike, you launch the team server, which handles beacon connections, and connect to it via the client. Sliver involves running the server binary and using the client console to generate implants. Covenant requires deploying its web application on a server with .NET Core. In all cases, you must configure listener settings—such as IP addresses, ports, and communication protocols—to define how beacons will reach your server. This step is where operational security (OPSEC) starts; using default ports or predictable configurations can lead to immediate detection by security tools.

Generating beacons is the next critical phase. A beacon is the payload executed on a target system to establish a connection back to your C2. You customize beacons based on the target operating system, desired persistence, and evasion techniques. For example, in Cobalt Strike, you might create a Windows executable that uses HTTP for communication, while in Sliver, you could generate a shellcode payload for injection into a legitimate process. Always consider the target environment: if endpoints use strict egress filtering, you might need to configure beacons to communicate over common ports like 443 (HTTPS) to blend with normal traffic. This deployment phase sets the stage for all subsequent operations, so meticulous planning here prevents failures later.

Enhancing Stealth with Redirectors and Domain Fronting

To protect your C2 server from exposure, you implement redirectors—proxies that forward traffic between beacons and the actual C2 server. Redirectors mask the server's true IP address, making it harder for defenders to block or take down your infrastructure. A common setup involves using a VPS as a redirector with tools like Apache mod_rewrite or SOCKS proxies to filter and forward only legitimate beacon traffic. For instance, you might configure a redirector to only pass requests containing specific HTTP headers or URI patterns, dropping everything else. This layer of indirection not only obscures your server but also allows you to quickly switch backend servers if one is compromised.

Taking stealth further, domain fronting leverages content delivery networks (CDNs) like CloudFront or Azure to hide C2 traffic within legitimate-looking web requests. In this technique, beacons send requests to a front domain (e.g., a popular CDN endpoint), which then forwards them to your hidden C2 server based on hidden HTTP headers. To defenders, traffic appears to go to a trusted service, not your malicious infrastructure. However, note that many CDNs have tightened policies against domain fronting, so alternatives like domain hiding—using decoy domains that resolve to your redirectors—are increasingly important. From a defensive perspective, network monitors might detect anomalies in TLS handshakes or CDN usage, so you should pair domain fronting with other OPSEC measures to avoid raising flags.

Encrypting C2 Traffic

Encryption is non-negotiable for securing data in transit between beacons and your C2 server. Most frameworks use Transport Layer Security (TLS) by default for HTTPS listeners, ensuring that communications are encrypted and authenticated. You must properly configure SSL/TLS certificates—either using self-signed certificates or, for better stealth, obtaining certificates from trusted authorities for your decoy domains. In Cobalt Strike, you can apply malleable C2 profiles to customize encryption parameters, such as cipher suites, to mimic legitimate software. Sliver allows you to define encryption keys in implant profiles, enabling end-to-end encryption even over custom protocols.

Beyond TLS, consider additional layers of encryption for sensitive data. For example, you might encrypt exfiltrated files with AES-256 before transmission, adding a barrier even if TLS is compromised. Traffic encryption also involves obfuscating patterns to avoid signature-based detection. Tools like Cobalt Strike's Artifact Kit can help generate encoded payloads that evade antivirus software. Remember, weak encryption or default settings are low-hanging fruit for blue teams; always use strong, up-to-date cryptographic standards and rotate keys periodically. This not only protects your data but also aligns with real-world adversary tactics, making your red team exercises more authentic.

Operational Security and Infrastructure Resilience

Operational security (OPSEC) measures are what separate successful operations from detected ones. Start by hardening your C2 server: disable unnecessary services, use firewall rules to restrict access, and monitor logs for unauthorized attempts. Implement resilient communication channels by using multiple redundant redirectors and fallback mechanisms, such as DNS-based failover, to maintain connectivity if one path is blocked. For instance, configure beacons to try several domains or IPs in sequence, ensuring persistence even under active defense.

Rotating infrastructure is key to avoiding detection. Regularly change domains, IP addresses, and SSL certificates to disrupt defender fingerprinting. In practice, this means provisioning new redirectors and updating beacon configurations before indicators of compromise (IOCs) are widely shared. Additionally, managing multiple beacon connections requires careful coordination to prevent operational noise. Use your framework's features to group beacons, schedule tasks during low-activity periods, and avoid simultaneous loud actions that might trigger alerts. For example, in Covenant, you can use the Grunt management system to stagger command execution across implants. By maintaining a low profile and adapting to the target environment, you extend your operational lifespan and gather more meaningful intelligence for the assessment.

Common Pitfalls

1. Exposing the C2 Server Directly: Without redirectors, your server's IP is visible in network logs, leading to quick blacklisting. Correction: Always deploy at least one layer of redirectors and use DNS names instead of IPs in beacon configurations.

1. Neglecting Traffic Obfuscation: Relying on plain HTTP or default TLS settings makes traffic easy to fingerprint. Correction: Encrypt all communications with TLS and customize profiles to mimic benign applications, such as web browsers or cloud services.

1. Failing to Rotate Infrastructure: Using the same domains or certificates for too long allows defenders to build durable detections. Correction: Establish a rotation schedule—e.g., weekly changes—and automate where possible using scripting tools integrated with your C2 framework.

1. Poor Beacon Management: Overloading beacons with simultaneous tasks or noisy commands can cause performance issues and alert security teams. Correction: Use throttling features, schedule tasks during off-hours, and prioritize stealthy actions like memory-only operations to minimize footprint.

Summary

• Select frameworks wisely: Cobalt Strike, Sliver, and Covenant each offer unique advantages for red teaming; choose based on operational needs like stealth, cost, and team collaboration.
• Layer your infrastructure: Deploy redirectors and leverage techniques like domain fronting to hide your C2 server, protecting it from direct exposure and takedowns.
• Encrypt comprehensively: Use TLS for all C2 traffic and consider additional encryption for data exfiltration to evade detection and ensure confidentiality.
• Prioritize OPSEC: Harden servers, rotate infrastructure regularly, and manage beacons carefully to maintain resilience and avoid alerting defenders.
• Simulate real adversaries: By implementing resilient communication channels and operational security measures, you provide realistic assessments that help organizations improve their defenses.