Home Tutorials Red Team Tactics: Getting started with Cobalt Strike

Tutorials

Red Team Tactics: Getting started with Cobalt Strike [Tutorial]

January 12, 2019 - 2:00 am

24935

14 min read

According to cobaltstrike.com:

“Cobalt Strike is a software for Adversary Simulations and Red Team Operations. Adversary Simulations and Red Team Operations are security assessments that replicate the tactics and techniques of an advanced adversary in a network. While penetration tests focus on unpatched vulnerabilities and misconfigurations, these assessments benefit security operations and incident response.”

This tutorial is an excerpt taken from the book Hands-On Red Team Tactics written by Himanshu Sharma and Harpreet Singh. This book demonstrates advanced methods of post-exploitation using Cobalt Strike and introduces you to Command and Control (C2) servers and redirectors. In this article, you will understand the basics of what Cobalt Strike is, how to set it up, and also about its interface.

Before installing Cobalt Strike, please make sure that you have Oracle Java installed with version 1.7 or above. You can check whether or not you have Java installed by executing the following command:

java -version

If you receive the java command not found error or another related error, then you need to install Java on your system. You can download this here: https://www.java.com/en/.

Cobalt Strike comes in a package that consists of a client and server files. To start with the setup, we need to run the team server. The following are the files that you’ll get once you download the package:

The first thing we need to do is run the team server script located in the same directory.

What is a team server?

This is the main controller for the payloads that are used in Cobalt Strike.
It logs all of the events that occur in Cobalt Strike.
It collects all the credentials that are discovered in the post-exploitation phase or used by the attacker on the target systems to log in.
It is a simple bash script that calls for the Metasploit RPC service (msfrpcd) and starts the server with cobaltstrike.jar. This script can be customized according to the needs.

Cobalt Strike works on a client-server model in which the red-teamer connects to the team server via the Cobalt Strike client. All the connections (bind/reverse) to/from the victims are managed by the team server.

The system requirements for running the team server are as follows:

System requirements:
- 2 GHz+ processor
- 2 GB RAM
- 500MB+ available disk space
Amazon EC2:
- At least a high-CPU medium (c1.medium, 1.7 GB) instance
Supported operating systems:
- Kali Linux 1.0, 2.0 – i386 and AMD64
- Ubuntu Linux 12.04, 14.04 – x86, and x86_64
The Cobalt Strike client supports:
- Windows 7 and above
- macOS X 10.10 and above
- Kali Linux 1.0, 2.0 – i386 and AMD64
- Ubuntu Linux 12.04, 14.04 – x86, and x86_64

As shown in the following screenshot, the team server needs at least two mandatory arguments in order to run. This includes host, which is an IP address that is reachable from the internet. If behind a home router, you can port forward the listener’s port on the router. The second mandatory argument is password, which will be used by the team server for authentication:

The third and fourth arguments specify a Malleable C2 communication profile and a kill date for the payloads (both optional). A Malleable C2 profile is a straightforward program that determines how to change information and store it in an exchange. It’s a really cool feature in Cobalt Strike.

The team server must run with the root privileges so that it can start the listener on system ports (port numbers: 0–1023); otherwise, you will receive a Permission denied error when attempting to start a listener:

The Permission denied error can be seen on the team server console window, as shown in the following screenshot:

Now that the concept of the team server has been explained, we can move on to the next topic. You’ll learn how to set up a team server for accessing it through Cobalt Strike.

Cobalt Strike setup

The team server can be run using the following command:

 sudo ./teamserver 192.168.10.122 harry@123

Here, I am using the IP 192.168.10.122 as my team server and harry@123 as my password for the team server:

If you receive the same output as we can see in the preceding screenshot, then this means that your team server is running successfully. Of course, the SHA256 hash for the SSL certificate used by the team server will be different each time it runs on your system, so don’t worry if the hash changes each time you start the server.

Upon successfully starting the server, we can now get on with the client. To run the client, use the following command:

java -jar cobaltstrike.jar

This command will open up the connect dialog, which is used to connect to the Cobalt Strike team server. At this point, you need to provide the team server IP, the Port number (which is 50050, by default), the User (which can be any random user of your choice), and the Password for the team server. The client will connect with the team server when you press the Connect button.

Upon successful authorization, you will see a team server fingerprint verification window. This window will ask you to show the exact same SHA256 hash for the SSL certificate that was generated by the team server at runtime. This verification only happens once during the initial stages of connection. If you see this window again, your team server is either restarted or you are connected to a new device. This is a precautionary measure for preventing Man-in-the-Middle (MITM) attacks:

Once the connection is established with the team server, the Cobalt Strike client will open:

Let’s look further to understand the Cobalt Strike interface so that you can use it to its full potential in a red-team engagement.

Cobalt Strike interface

The user interface for Cobalt Strike is divided into two horizontal sections, as demonstrated in the preceding screenshot. These sections are the visualization tab and the display tab. The top of the interface shows the visualization tab, which visually displays all the sessions and targets in order to make it possible to better understand the network of the compromised host. The bottom of the interface shows the display tab, which is used to display the Cobalt Strike features and sessions for interaction.

Toolbar

Common features used in Cobalt Strike can be readily accessible at the click of a button.

The toolbar offers you all the common functions to speed up your Cobalt Strike usage:

Each feature in the toolbar is as follows:

Connecting to another team server

In order to connect to another team server, you can click on the + sign, which will open up the connect window:

All of the previous connections will be stored as a profile and can be called for connection again in the connect window:

Disconnecting from the team server

By clicking on the minus (–) sign, you will be disconnected from the current instance of the team server:

You will also see a box just above the server switchbar that says Disconnected from team server. Once you disconnect from the instance, you can close it and continue the operations on the other instance. However, be sure to bear in mind that once you close the tab after disconnection, you will lose all display tabs that were open on that particular instance. What’s wrong with that?

This may cause some issues. This is because in a red-team operation you do not always have the specific script that will execute certain commands and save the information in the database.

In this case, it would be better to execute the command on a shell and then save the output on Notepad or Sublime. However, not many people follow this practice, and hence they lose a lot of valuable information.

You can now imagine how heart-breaking it can be to close the instance in case of disconnection and find that all of your shell output (which was not even copied to Notepad) is gone!

Configure listeners

For a team server to function properly, you need to configure a listener. But before we can do this, we need to know what a listener actually is.

Just like the handler used in Metasploit (that is, exploit/multi/handler), the Cobalt Strike team server also needs a handler for handling the bind/reverse connections to and from the target/victim’s system/server. You can configure a listener by clicking on the headphones-like icon:

After clicking the headphones icon, you’ll open the Listeners tab in the bottom section. Click on the Add button to add a new listener:

You can choose the type of payload you want to listen for with the Host IP address and the port to listen on for the team server or the redirector:

In this case, we have used a beacon payload, which will be communicating over SSL. Beacon payloads are a special kind of payload in Cobalt Strike that may look like a generic meterpreter but actually have much more functionality than that. Beacons will be discussed in more detail in further chapters.

As a beacon uses HTTP/S as the communication channel to check for the tasking allotted to it, you’ll be asked to give the IP address for the team server and domain name in case any redirector is configured (Redirectors will be discussed in more details in further chapters):

Once you’re done with the previous step, you have now successfully configured your listener. Your listener is now ready for the incoming connection:

Session graphs

To see the sessions in a graph view, you can click the button shown in the following screenshot:

Session graphs will show a graphical representation of the systems that have been compromised and injected with the payloads. In the following screenshot, the system displayed on the screen has been compromised. PT is the user, PT-PC is the computer name (hostname), and the numbers just after the @ are the PIDs of the processes that have the payload injected into them:

When you escalate the privileges from a normal user to NT AUTHORITY\SYSTEM (vertical privilege escalation), the session graph will show the system in red and surrounded by lightning bolts. There is also another thing to notice here: the * (asterisk) just after the username. This means that the system with PID 1784 is escalated to NT AUTHORITY\SYSTEM:

Session table

To see the open sessions in a tabular view, click on the button shown in the following screenshot:

All the sessions that are opened in Cobalt Strike will be shown along with the sessions’ details. For example, this may include external IP, internal IP, user, computer name, PID into which the session is injected, or last. Last is an element of Cobalt Strike that is similar to WhatsApp’s Last Seen feature, showing the last time that the compromised system contacted the team server (in seconds). This is generally used to check when the session was last active:

Right-clicking on one of the sessions gives the user multiple options to interact with, as demonstrated in the following screenshot:

These options will be discussed later in the book.

Targets list

To view the targets, click on the button shown in the following screenshot:

Targets will only show the IP address and the computer name, as follows:

For further options, you can right-click on the target:

From here, you can interact with the sessions opened on the target system. As you can see in the preceding screenshot, PT@2908 is the session opened on the given IP and the beacon payload resides in the PID 2908. Consequently, we can interact with this session directly from here:

Credentials

Credentials such as web login passwords, password hashes extracted from the SAM file, plain-text passwords extracted using mimikatz, etc. are retrieved from the compromised system and are saved in the database. They can be displayed by clicking on the icon shown in the following screenshot:

When you perform a hashdump in Metasploit (a post-exploitation module that dumps all NTLM password hashes from the SAM database), the credentials are saved in the database. With this, when you dump hashes in Cobalt Strike or when you use valid credentials to log in, the credentials are saved and can be viewed from here:

Downloaded files

To view all the exfiltrated data from the target system, you can click on the button shown in the following screenshot:

This will show the files (exfiltration) that were downloaded from the target system:

Keystrokes

This option is generally used when you have enabled a keylogger in the beacon. The keylogger will then log the keystrokes and send it to the beacon. To use this option, click the button shown in the following screenshot:

When a user logs into the system, the keylogger will log all the keystrokes of that user (explorer.exe is a good candidate for keylogging). So, before you enable the keylogger from the beacon, migrate or inject a new beacon into the explorer.exe process and then start the keylogger. Once you do this, you can see that there’s a new entry in the Keystrokes tab:

The left side of the tab will show the information related to the beacon. This may include the user, the computer name, the PID in which the keylogger is injected, and the timestamp when the keylogger sends the saved keystrokes to the beacon. In contrast, the right side of the tab will show you the keystrokes that were logged.

Screenshots

To view the screenshots from the target system, click on the button shown in the following screenshot:

This will open up the tab for screenshots. Here, you will get to know what’s happening on the system’s screen at that moment itself. This is quite helpful when a server administrator is logged in to the system and works on Active Directory (AD) and Domain Controller (DC) settings. When monitoring the screen, we can find crucial information that can lead to DC compromise:

To know about Payload generation in stageless Windows executable, Java signed applet, and MS Office macros, head over to the book for a complete overview.

Scripted web delivery

This technique is used to deliver the payload via the web. To continue, click on the button shown in the following screenshot:

A scripted web delivery will deliver the payload to the target system when the generated command/script is executed on the system. A new window will open where you can select the type of script/command that will be used for payload delivery. Here, you also have the option to add the listener accordingly:

File hosting

Files that you want to host on a web server can also be hosted through the Cobalt Strike team server. To host a file through the team server, click on the button shown in the following screenshot:

This will bring up the window where you can set the URI, the file you want to host, the web server’s IP address and port, and the MIME type. Once done, you can download the same file from the Cobalt Strike team server’s web server. You can also provide the IP and port information of your favorite web redirector. This method is generally used for payload delivery:

Managing the web server

The web server running on the team server, which is generally used for file hosting and beacons, can be managed as well. To manage the web server, click on the button shown in the following screenshot:

This will open the Sites tab where you can find all web services, the beacons, and the jobs assigned to those running beacons. You can manage the jobs here:

Server switchbar

The Cobalt Strike client can connect to multiple team servers at the same time and you can manage all the existing connections through the server switchbar. The switchbar allows you to switch between the server instances:

You can also rename the instances according to the role of the server. To do this, simply right-click on the Instance tab and you’ll get two options: Rename and Disconnect:

You need to click on the Rename button to rename the instance of your choice. Once you click this button, you’ll be prompted for the new name that you want to give to your instance:

For now, we have changed this to EspionageServer:

Renaming the switchbar helps a lot when it comes to managing multiple sessions from multiple team servers at the same time.

To know more about how to customize a team server head over to the book.

To summarize, we got to know what a team server is, how to setup Cobalt Strike and about the Cobalt Strike Interface. If you’ve enjoyed reading this, head over to the book, Hands-On Red Team Tactics to know about advanced penetration testing tools, techniques to get reverse shells over encrypted channels, and processes for post-exploitation.