Understanding C2 infrastructure - Part 3

Exploring C2 infrastructure architecture, from straightforward setups to sophisticated deployments.

In this post, I have listed down seven different architectures for C2 infrastructure. I start from a simple architecture and move on to complex ones. Each subsequent architecture introduces a new element that increases the operational security of the setup, makes it harder to detect and more resilient.

One thing I’d like to mention, before delving into the topic, is that most of what I am about to describe was conceptualized by other members of the community. They were nice enough to make their work available to the community. So thank you. I have listed links to their work in the references section towards the end of this post. Through this post, I am just compiling my understanding of C2 infrastructure architecture in one place. The architecture diagrams below have been created by me to provide a comparable visual through a common design language.

Note: If you find your work quoted in this post but not mentioned in the references section, please let me know by leaving a comment.

If you haven’t gone through my previous posts on Command and Control (C2) basics and it’s core components, please take a moment to go through them. It will help in understanding the content below.

Let the games begin.

Most architectures described below assume the following:

There is only one C2 server, hosting multiple types of listeners. There are two redirectors, one for each listener type, that sit in front of the C2 server. The C2 server and redirectors are connected via SSH tunnels originating from the C2 server. Each SSH tunnel forwards a port on the C2 server that listens for the incoming traffic from redirectors. The C2 server then forwards this traffic to the appropriate listener and vice-versa.

1. All Cloud-based

   

   In this architecture, the C2 server and redirectors are hosted in the same cloud host. It is relatively straightforward and easy to automate and deploy. However, some organizations may not prefer hosting the C2 server in the cloud.

2. On-premise C2 Server and Cloud-based Redirectors

   

   In this architecture, the C2 server is hosted locally within the premises (i.e. on-premise) of the organization and redirectors are hosted in the same cloud host. Organizations which do not want to send their data to the cloud (usually for legal and regulatory reasons), would prefer a locally hosted C2 server.

3. On-premise C2 Server and Cloud-based Redirectors with Domain Fronting

   

   This is same as architecture number 2, just with a layer of CDN added in front of the HTTPS redirector. This architecture leverages Domain Fronting to provide additional operational security.

4. On-premise C2 Server and Multi-Cloud based Redirectors

   

   In this architecture, the C2 server is hosted on-premise and redirectors are hosted in different cloud hosts. Separating redirectors in this manner increases the operational security of the setup. For example, the above architecture leverages one cloud host for HTTPS traffic and the other cloud host for DNS traffic. This way if traffic to one redirector gets detected and blocked, the other will keep working. Domain fronting can also be added for even more operational security.

5. On-premise C2 Server and Multi-Cloud Multi-Region based Redirectors with IP Laundering

   

   In this architecture, the C2 server is hosted on-premise and redirectors are hosted in different cloud hosts and different regions. There is an additional layer of cloud-based hosts that act as plain relay nodes. It sits in between the C2 server and redirectors. This chaining of multiple cloud hosts together is referred to as IP Laundering. Domain fronting can also be added for even more operational security.

6. Multiple On-premise C2 Servers and Multi-Cloud based Redirectors

   

   In this architecture, multiple C2 servers are deployed on-premise. Each C2 server is assigned a specific role and has a corresponding redirector in front of it. Redirectors are deployed across multiple cloud hosts. Using multiple C2 servers and designating a specific role to each, helps in streamlining the engagement and ensures that if one C2 server gets detected, others are not impacted. This can further be combined with Domain fronting and IP Laundering for increased resiliency of the setup.

7. Distributed C2 Architecture

   

   In this architecture, components of C2 infrastructure are spread across multiple cloud hosts, multiple locations and multiple on-premise regions. Each component is placed according to its role. For example, while in architecture 6, all C2 servers were hosted at a single on-premise location, in this, the payload delivery and staging C2 servers are hosted in cloud and post-exploitation C2 server, where most of the exfiltrated data will reside, is hosted on-premise.

Red Team Notes
- The architecture of C2 infrastructure can range from simple to highly complex. The exact architecture will depend on the needs of the engagement. 
- Factors to consider while creating C2 architecture include:
  - Operational Security
  - Resiliency
  - Ease of automation and deployment
  - Organizational constraints (regulatory, legal etc.)
  - Support by the selected C2 software

Follow my journey of 100 Days of Red Team on WhatsApp or Discord.

As can be seen above, when it comes to C2 infrastructure there is no one-size-fits-all architecture that could address all needs. The architecture of the C2 infrastructure will largely depend on the requirements of the engagement, and it can range from being simple to highly complex. For example, architecture 7 can further be expanded by adding domain fronting and IP laundering.

Similarly, elements from above mentioned architectures can be mixed and matched to create even more variants. They can even be replaced with other similar or more secure elements. For example, in each of the above architectures we can replace SSH tunnels with VPN technologies such as Wireguard or Tailscale.

References

• Safe Red Team Infrastructure by Tim MalcomVetter

• Infrastructure for Ongoing Red Team Operations by Raphael Mudge

• A Vision for Distributed Red Team Operations by Raphael Mudge

• Testing your RedTeam Infrastructure by Adam Chester

• Doomsday Preppers: Fortifying your red team Infrastructure by Steve Borosh and Jeff Dimmock

• Red Team Infrastructure Wiki by Jeff Dimmock

• Red Team Tutorial: Design and setup of C2 traffic redirectors by Dmitrijs Trizna

• Taking the pain out of C2 infrastructure (Part 2) by Marcello

• Red Team Infrastructure Done Right by Matt Kiely

• Modern Red Team Infrastructure by Brady Bloxham

• Designing Effective Covert Red Team Attack Infrastructure by Jeff Dimmock

• Cloud-based Redirectors for Distributed Hacking by Raphael Mudge

• Designing a C2 Infrastructure by Steven Patterson