Understanding C2 infrastructure - Part 2
Design considerations for setting up a secure and reliable C2 infrastructure.
In previous posts, I covered the basics of Command and Control (C2) and core components that make up C2 Infrastructure. In this post, I’ll list down some design considerations, including OPSEC ones, that red team operators should keep in mind when deploying the C2 infrastructure.
Design considerations for setting up secure C2 Infrastructure:
C2 server should not be directly exposed to the internet. Exposing the C2 server to the internet increases the risk of the server getting detected and being blocked.
Use a reverse proxy to setup secure communication between internet exposed redirectors and the C2 server. Secure communication can be setup via SSH, VPN technologies such as Wireguard, Nebula or Tailscale.
SSH tunnels established between redirector and team server should originate from the team server and not the other way round. The key material must always reside on the C2 server that is not exposed to the internet.
All components of C2 infrastructure can be hosted on cloud. Though, there are multiple schools of thought when it comes to hosting the C2 server in cloud vs on-premise.
Choose domain names with clean history. Read this for more information.
Domain names should be such that they can blend in easily with the target organization’s traffic. So, either choose those that are similar to services being used within the target organization or match closely to domain names used by the target organization.
If using a web server redirector - use ngnix, caddy or apache.
A Linux-based operating system is a good choice for redirectors and C2 server. I have seen Ubuntu being the go to choice across many setups.
C2 Server - C2 Rediretor- C2 Agent should mimic legitimate communication to blend in with other traffic and avoid detection.
C2 Infrastructure must allow only malware control traffic to reach the real C2 server. Unwanted IP addresses or unauthenticated agents or any other type of unwanted traffic must be filtered and restricted at the reverse proxy level.
C2 infrastructure should be reliable such that, components are not detected easily, and if detected, can be replaced easily.
Constantly change or adapt C2 infrastructure across different engagements. Do not re-use same C2 infrastructure across two different engagements.
Setup multiple C2 servers, if feasible, and assign each server a different role. For example, one server for long-haul, another for staging and another for post-exploitation.
Do not pass a session from other C2 servers to long-haul C2 server. Sessions must always be passed from Long-haul to staging to post-exploitation.
Use long callback times for establishing communication with long-haul server.
Take advantage of protocol diversity i.e. use C2 servers communicating with agents over different protocols For example, one C2 server can communicate over DNS and another one can communicate over HTTPS.
Never update existing long-haul servers. Bring up new servers with updated C2 software and configure it. Keep old long-haul server running until 100% sure of new C2 infrastructure.
Do not store sensitive data / material on cloud hosted-servers. Even if rules of engagement allow the C2 server to be hosted on cloud, sensitive data should not be stored on cloud-hosted server without proper legal paper-work.
Red Team Notes
- Keep in mind the above listed design considerations when deploying C2 infrastructure for your next red team engagement.Follow my journey of 100 Days of Red Team on WhatsApp or Discord.
Sources: