Red Team Tutorial: Design and setup of C2 traffic redirectors
Control of compromised machines within the target network happens through specifically designed Command & Control (C&C, C2) infrastructure. This article describes the rationale behind C2 design decisions and provides a step-by-step setup of the C2 redirector.
The report may be valuable for defensive analysts as insight in operations of adversary groups, as well as provide the necessary information for those willing to simulate adversary C2 channels. We will cover how one can build a HTTPS redirector using basic tools — nginx, minimalistic VPS, free DNS, and PKI certificate services.
C2 infrastructure is built with the intent to pursue several goals:
- hide the true location of the C2 server;
- mimic legitimate communication;
- allow only malware control traffic to reach the real C2 server;
- be reliable — given detection the part of C2 infrastructure, still, maintain C2 channel to the target.
Simple port forwarding by tools like socat or SSH can solve bullet #1 and partly #4. However, to address bullets #2 and #3 we need to introduce more sophisticated redirectors — hosts, which act as reverse proxies to forward only specific traffic to the real C2 server, whilst serving counterfeit content for the arbitrary visitor. In this article, we will focus on HTTPS as a protocol for external C2 communication. A high-level overview of such design is visualized in Figure 1 below:
The most valuable resource for any redirector is a public IP address, whilst it does not require any somehow powerful CPU or memory resources to achieve its goals. Therefore, minimalistic images from common cloud providers like AWS or Azure are totally fine (e.g. t3a.nano from AWS with 2 vCPUs, 500 MB RAM, and 8 GB disk).
After access to such host, we're ready to build our nginx setup:
sudo yum -y install git nginx vim certbot tmux wget# SELinux configuration for Reverse Proxy functionality
setsebool -P httpd_can_network_connect true