Chapter 1: Designing a C2 Infrastructure

Discussion of C2 infrastructure concepts and design.

Introduction

In this chapter, we'll be going over the foundational concepts of Command & Control (C2) software and best practices for design. Our goal in this section is to understand what a "good" C2 infrastructure looks like and make plans for a solid foundation that can be built upon with more advanced components.

Basic C2 Setup

Let's start by discussing the design for a basic C2 setup. First, we'll want to have a server that will publish our tasks and receive the results of those tasks (also known as a "listening post"). Next, we want to have a program that will run on a target computer and make contact with our server periodically to find out what tasks to perform, execute those tasks, then respond back with the results (also known as an "implant"). Lastly, we'll want to have a client where an operator can easily create, manage and submit tasks. Tasks could include things like returning information about the computer/network the implant is running on, executing OS commands, enumerating processes/threads, injecting into another process, establishing persistence or stealing credentials for lateral movement. The flow of this setup looks like the diagram below:

There's a number of issues with our basic design in the above diagram. For one, it's a straightforward task for defenders to directly identify your listening post and take targeted action to disrupt the C2 channel. Secondly, it's not segmented, you're doing all your offensive activities through a single channel and from a single server. It's easy for defenders to take down your entire C2.

Adding Resiliency

To make our basic setup more resilient, we can include another server that proxies communication from implants and forwards traffic along to the listening post, also known as a "redirector". With the inclusion of redirectors, you never need to expose the address of your listening post to the implant. Thereby denying this information to any defender who happens to capture/analyze your C2 communications. Another benefit is that you can have multiple redirector addresses in your implants and that way, if one of your redirectors gets taken down or blocked, your implant can simply fall back to using one of the others.

To address the issue of segmentation, you can have multiple listening posts responsible for handling different aspects of your operation. For instance, one way to segment the design is to have a server that handles day-to-day C2 communications and is for "hands on keyboard" type activities where you want instant feedback or "short haul" tasks. Then, you can have another server that would be for re-establishing access in the target network or "long haul" tasks. The idea being, you expect your noisier short haul channel to be taken down regularly and you can use your quieter long haul channel to regain access. Ideally, your long haul C2 channel will have different network/host indicators as well. The flow of this more resilient setup looks like the diagram below:

For this book, we're going to be focusing on building a simple setup with just a listening post, implant and an operator client. A section on adding features that turn this project into something more than a basic framework is planned for a Part 2. But, in this primer, we're going to be keeping things simple.

C2 Implant & Listening Post Features

Now that we understand the overall layout of a C2 infrastructure, it's time to go into the details of the listening post and implant features for the basic setup we're starting with. The listening post should allow users to submit tasks and publish them for retrieval by the implant. It should also let users read tasks that have been submitted. Our initial C2 channel will be over HTTP, so the listening post should publish tasks after receiving a GET request from the implant and ingest task results from an implant POST request. We can implement these actions as a REST API to ensure it's easy to integrate with a front-end web framework or CLI client. As for our implant, it should be capable of asynchronous operations so it can continue to communicate with the listening post as it performs tasking. The types of tasks will include the following:

Configure implant options
Ping
Execute system commands
Gather process thread information

Finally, we'll want a nice way for us to interact with our listening post as an operator. So, we'll build an operator CLI client that can speak to the listening post. Our command line client will be basic and let us get started with a simple interface that's quick to build. We want it to be capable of allowing an operator to provide new tasks, view a history of sent tasks and fetch results of tasks that were sent.

Our complete C2 framework will be called Natsumi and involve the following major components:

Skytree: Our HTTP listening post.
RainDoll: Our C2 implant in C++.
Fireworks: Our operator CLI client.

Conclusion

With this chapter, we've got an idea of what capabilities a basic C2 framework should provide. We also laid out our plans for the C2 project we'll be building in this book and the features we want it to have. Hopefully, you're excited to get your feet wet and start building things. In Chapter 2, we'll begin our work with a listening post and see how simple it can be to design a REST API for our implants to use. See you in the next chapter!