User Guide - Part 1

system · February 7, 2022, 1:52pm

Welcome to Cobalt Strike

Cobalt Strike is a platform for adversary simulations and red team operations. The product is designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors. This section describes the attack process supported by Cobalt Strike’s feature set. The rest of this manual discusses these features in detail.

Overview Cobalt Strike

A thought-out targeted attack begins with reconnaissance . Cobalt Strike’s system profiler is a web application that maps your target’s client-side attack surface. The insights gleaned from reconnaissance will help you understand which options have the best chance of success on your target.

Weaponization is pairing a post-exploitation payload with a document or exploit that will execute it on target. Cobalt Strike has options to turn common documents into weaponized artifacts. Cobalt Strike also has options to export its post-exploitation payload, Beacon, in a variety of formats for pairing with artifacts outside of this toolset.

Use Cobalt Strike’s spear phishing tool to deliver your weaponized document to one or more people in your target’s network. Cobalt Strike’s phishing tool repurposes saved emails into pixel- perfect phishes.

Control your target’s network with Cobalt Strike’s Beacon. This post-exploitation payload uses an asynchronous “ low and slow ” communication pattern that’s common with advanced threat malware. Beacon will phone home over DNS, HTTP, or HTTPS. Beacon walks through common proxy configurations and calls home to multiple hosts to resist blocking.

Exercise your target’s attack attribution and analysis capability with Beacon’s Malleable Command and Control language. Reprogram Beacon to use network indicators that look like known malware or blend in with existing traffic.

Pivot into the compromised network, discover hosts, and move laterally with Beacon’s helpful automation and peer-to-peer communication over named pipes and TCP sockets. Cobalt Strike is optimized to capture trust relationships and enable lateral movement with captured credentials, password hashes, access tokens, and Kerberos tickets.

Demonstrate meaningful business risk with Cobalt Strike’s user-exploitation tools. Cobalt Strike’s workflows make it easy to deploy keystroke loggers and screenshot capture tools on compromised systems. Use browser pivoting to gain access to websites that your compromised target is logged onto with Internet Explorer. This Cobalt Strike-only technique works with most sites and bypasses two-factor authentication.

Cobalt Strike’s reporting features reconstruct the engagement for your client. Provide the network administrators an activity timeline so they may find attack indicators in their sensors. Cobalt Strike generates high quality reports that you may present to your clients as stand-alone products or use as appendices to your written narrative.

Throughout each of the above steps, you will need to understand the target environment, its defenses, and reason about the best way to meet your objectives with what is available to you. This is evasion. It is not Cobalt Strike’s goal to provide evasion out-of-the-box. Instead, the product provides flexibility, both in its potential configurations and options to execute offense actions, to allow you to adapt the product to your circumstance and objectives.

Installation and Updates

Cobalt Strike packages as native archives for Windows, Linux, and MacOS X.

Cobalt Strike uses a client / server model where each component can be installed on the same system, but is often deployed separately. The Cobalt Strike GUI is referred to as ‘Cobalt Strike’, the ‘Cobalt Strike GUI’ , or the command used to start the client ‘cobaltstrike’. The Cobalt Strike server is referred to as ‘Team Server’ or the command used to start the server ‘teamserver’.

The basic process to install Cobalt Strike involves downloading and extracting a distribution package onto your operating system and running an update process to download the product.

Before You Begin

Read this section before you install Cobalt Strike.

System Requirements

The following items are required for any system hosting the Cobalt Strike client and/or server components.

Java

Cobalt Strike’s GUI client and team server require one of the following Java environments:

Oracle Java 1.8
Oracle Java 11
OpenJDK 11. (see Installing OpenJDK for instructions)

NOTE:
If your organization does not have a license that allows commercial use of Oracle’s Java, we encourage you to use OpenJDK 11.

Supported Operating Systems

Cobalt Strike Team Server is supported on a Linux system that meets the Java requirements and has been tested on the following Debian based Linux distributions (other versions may work but have not been tested):

Debian
Ubuntu
Kali Linux

Cobalt Strike Client runs on the following systems:

Windows 7 and above
MacOS X 10.13 and above
GUI based Linux, such as: Debian, Ubuntu and Kali Linux (other versions may work but have not been tested)

Hardware

In addition to an accepted operating system, the below minimum requirements should be met:

2 GHz+ processor
2 GB RAM
500MB+ available disk space

On Amazon’s EC2, use at least a High-CPU Medium (c1.medium, 1.7 GB) instance.

Installing OpenJDK

Cobalt Strike is tested with OpenJDK 11 and its launchers are compatible with a properly installed OpenJDK 11 environment.

Linux (Kali 2018.4, Ubuntu 18.04)

Update APT:sudo apt-get update
Install OpenJDK 11 with APT:sudo apt-get install openjdk-11-jdk
Make OpenJDK 11 the default:sudo update-java-alternatives -s java-1.11.0-openjdk-amd64

Linux (Other)

Uninstall the current OpenJDK package(s).
Download OpenJDK for Linux/x64 at: https://jdk.java.net/archive/.
Extract the OpenJDK binary:tar zxvf openjdk-11.0.1_linux-x64_bin.tar.gz
Move the OpenJDK folder to /usr/local:mv jdk-11.0.1 /usr/local
Add the following to ~/.bashrc:JAVA_HOME="/usr/local/jdk-11.0.1"PATH=$PATH:$JAVA_HOME/bin
Refresh your ~/.bashrc to make the new environment variables take effect:source ~/.bashrc

MacOS X

Download OpenJDK for macOS/x64 at: https://jdk.java.net/archive/.
Open a Terminal and navigate to the Downloads/ folder.
Extract the archive:tar zxvf openjdk-11.0.1_osx-x64_bin.tar.gz
Move the extracted archive to /Library/Java/JavaVirtualMachines/:sudo mv jdk-11.0.1.jdk/ /Library/Java/JavaVirtualMachines/

The java command on MacOS X will use the highest Java version in /Library/Java as the default.

TIP:
If you are seeing a JRELoadError message this is because the JavaAppLauncher stub included with Cobalt Strike loads a library from a set path to run the JVM within the stub process. Issue the following command to fix this error:

sudo ln -fs /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin

Replace jdk-11.0.2.jdk with your Java path. The next Cobalt Strike release will use a Java Application Stub for MacOS X that is more flexible.

Windows

Download OpenJDK for Windows/x64 at: https://jdk.java.net/archive/.
Extract the archive to c:\program files\jdk-11.0.1.
Add c:\program files\jdk-11.0.\bin to your user’s PATH environment variable:
Go to Control Panel-> System-> Change Settings-> Advanced-> Environment Variables…
Highlight Path in User variables for user.
Press Edit .
Press New .
Type: c:\program files\jdk-11.0.1\bin.
Press OK on all dialogs.

Wayland Desktop - Not Supported

Wayland is a modern replacement for the X Windows System. Wayland has made great strides, as a project, and some desktop environments use it as their default window system. Don’t let the adoption fool you though. Not all applications or application environments work 100% perfectly on Wayland. There are still bugs and issues to address.

There are bugs in Java (or Wayland) that may cause a graphical Java application to crash, during normal use, when run in a Wayland desktop. These bugs affect Cobalt Strike users.

Am I using Wayland?

Type echo $XDG_SESSION_TYPE to find out if you’re on wayland or x11.

How to disable Wayland on Kali Linux

The latest version of Kali Linux 2017 Rolling uses a Wayland desktop by default. To change this back to X11:

Open /etc/gdm3/daemon.conf with your favorite text editor.
Find the [daemon] section.
Add WaylandEnable=false and reboot your system.

Installing Cobalt Strike

Follow these instructions to install Cobalt Strike.

NOTE:

The Cobalt Strike Distribution Package (steps 1 and 3) contains the OS-specific Cobalt Strike launcher(s), supporting files, and the updater program. It does not contain the Cobalt Strike program itself. Running the Update Program (step 4) downloads the Cobalt Strike product and performs the final installation steps.

Download a Cobalt Strike distribution package for a supported operating system. (an email is provided with a link to the download)
Setup a recommended Java environment. (see Installing OpenJDK for instructions)
Extract, mount or unzip the distribution package. Based on the operating system perform one of the following.

For Linux:
1. Extract the cobaltstrike-dist.tgz:tar zxvf cobaltstrike-dist.tgz
For MacOS X:
1. Double-click the cobaltstrike-dist.dmg file to mount it.
2. Drag the Cobalt Strike folder to the Applications folder.
For Windows:
1. Disable anti-virus before you install Cobalt Strike.
2. Use your preferred zip tool to extract the cobaltstike.zip file to an install location.
Run the update program to finish the install. Based on the operating system perform one of the following.
For Linux:
1. Enter the following commands:cd /path/to/cobaltstrike./update
For MacOS X:
1. Navigate to the Cobalt Strike folder.
2. Double-click Update Cobalt Strike.command.
For Windows:
1. Navigate to the Cobalt Strike folder.
2. Double-click update.bat.

Make sure you update both your team server and client software with your license key. Cobalt Strike is generally licensed on a per user basis. The team server does not require a separate license.

License Authorization Files

The licensed version of Cobalt Strike requires a valid authorization file to start. An authorization file is an encrypted blob that provides information about your license to the Cobalt Strike product. This information includes: your license key, your license expiration date, and an ID number that is tied to your license key.

How do I get an authorization file?

The built-in update program requests an authorization file from Cobalt Strike’s update server when it’s run. The update program downloads a new authorization file, even if your Cobalt Strike version is up to date.

What happens when my license expires?

Cobalt Strike will refuse to start when its authorization file expires. There is no impact if an authorization file expires while Cobalt Strike is running. The licensed Cobalt Strike product only checks authorization files when it starts.

When does my authorization file expire?

Your authorization file expires when your Cobalt Strike license expires. If you renew your Cobalt Strike license, run the built-in update program to refresh the authorization file with the latest information.

Go to Help → System Information to find out when your authorization file expires. Look for the “valid to” value under the Other section. Remember, the Client Information and Team Server Information may have different values (depending on which license key was used and when the authorization file was last refreshed).

Cobalt Strike will also warn you when its authorization file is within 30 days of its valid to date.

How do I bring an authorization file into a closed environment?

The authorization file is cobaltstrike.auth . The update program always co-locates this file with cobaltstrike.jar. To use Cobalt Strike in a closed environment:

Download the Cobalt Strike trial package.
Update the Cobalt Strike trial package from an internet connected system
Copy the contents of the updated cobaltstrike/ folder into your environment. The most important files are cobaltstrike.jar and cobaltstrike.auth.

How do I use an older version of Cobalt Strike with a refreshed authorization file?

Cobalt Strike 3.8 and below do not check for or require an authorization file.

Cobalt Strike 3.9 and later check for a cobaltstrike.auth file co-located with the cobaltstrike.jar file. Update Cobalt Strike from another folder and copy the new cobaltstrike.auth file to the folder that contains your old-version of Cobalt Strike. The authorization file is not tied to a specific version of the product.

What is the Customer ID value?

The Customer ID is a 4-byte number associated with a Cobalt Strike license key. Cobalt Strike 3.9 and later embed this information into the payload stagers and stages generated by Cobalt Strike.

How do I find the Customer ID value in a Cobalt Strike artifact?

The Customer ID value is the last 4-bytes of a Cobalt Strike payload stager in Cobalt Strike 3.9 and later.

This screenshot is the HTTP stager from the trial. The trial has a Customer ID value of 0. The last 4-bytes of this stager (0x0, 0x0, 0x0, 0x0) reflect

The Customer ID value also exists in the payload stage, but it’s more steps to recover. Cobalt Strike does not use the Customer ID value in its network traffic or other parts of the tool.

How do I protect disparate red team infrastructure from cross-identification with this ID?

If you have a unique authorization file on each team server, then each team server and the artifacts that originate from it will have a different ID.

Cobalt Strike’s update server generates a new authorization file each time the update program is run. Each authorization file has a unique ID. Cobalt Strike only propagates the team server’s ID. It does not propagate the ID from the GUI or headless client’s authorization file.

After You are Done

Congratulations! Cobalt Strike is now installed. Read the following for additional information and your next steps.

Next Steps

Starting the Team Server

Starting a Cobalt Strike Client

Starting the Team Server

Cobalt Strike is split into client and a server components. The server, referred to as the team server, is the controller for the Beacon payload and the host for Cobalt Strike’s social engineering features. The team server also stores data collected by Cobalt Strike and it manages logging.

The Cobalt Strike team server must run on a supported Linux system. To start a Cobalt Strike team server, issue the following command to run the team server script included with the Cobalt Strike Linux package:

./teamserver <ip_address> [ <kill_date>]

The team server script uses the following two mandatory and two optional parameters:

IP Address - (mandatory) Enter the externally reachable IP address of the team server. Cobalt Strike uses this value as a default host for its features.

Password - (mandatory) Enter a password that your team members will use to connect the Cobalt Strike client to the team server.

Malleable C2 Profile - (optional) Specify a valid Malleable C2 Profile. See Malleable Command and Control for more information on this feature.

Kill Date - (optional) Enter a date value in YYYY-MM-DD format. The team server will embed this kill date into each Beacon stage it generates. The Beacon payload will refuse to run on or after this date and will also exit if it wakes up on or after this date.

When the team server starts, it will publish the SHA256 hash of the team server’s SSL certificate. Distribute this hash to your team members. When your team members connect, their Cobalt Strike client will ask if they recognize this hash before it authenticates to the team server. This is an important protection against man-in-the-middle attacks.

Starting a Cobalt Strike Client

Follow the steps below to connect the Cobalt Strike client to the team server.

Steps

To start the Cobalt Strike client, use the launcher included with your platform’s package.
For Linux:
1. Enter the following commands:./cobaltstrike
For MacOS X:
1. Navigate to the Cobalt Strike folder.
2. Double-click cobaltstrike.
For Windows:
1. Navigate to the Cobalt Strike folder.
2. Double-click cobaltstrike.exe.The Connect Dialog screen displays.

start-client_startup-panel

Cobalt Strike keeps track of the team servers you connect to and remembers your information. Select one of these team server profiles from the left-hand-side of the connect dialog to populate the connect dialog with its information. Use the Alias Names and Host Names buttons to toggle how the list of hosts are displayed. Active connections will be displayed in blue text. You may control how the host list is initially displayed, active connection text color, and prune the list through Cobalt Strike → Preferences → Team Servers .

Parameters:

Alias - Enter an alias for the host or use the default. The alias name can not be empty, start with an ‘*’, or use the same alias name of an active connection.

Host - Specify your team server’s address in the Host field. The host name can not be empty.

Port - Displays the default Port for the team server (50050). This is rarely change. The port can not be empty and must be a numeric number.

User - The User field is your nickname on the team server. Change this to your call sign, handle, or made-up hacker fantasy name. The user name can not be empty.

Password - Enter the shared password for the team server.
2. Press Connect to connect to the Cobalt Strike team server.If this is your first connection to this team server, Cobalt Strike will ask if you recognize the SHA256 hash of this team server.

If you do, press Yes , and the Cobalt Strike client will connect to the server and open the client user interface.

NOTE:

Cobalt Strike will also remember this SHA256 hash for future connections. You may manage these hashes through Cobalt Strike → Preferences → Fingerprints .

Distributed and Team Operations

Use Cobalt Strike to coordinate a distributed red team effort. Stage Cobalt Strike on one or more remote hosts. Start your team servers and have your team connect.

Once connected to a team server, your team will:

Use the same sessions
Share hosts, captured data, and downloaded files
Communicate through a shared event log.

The Cobalt Strike client may connect to multiple team servers. Go to Cobalt Strike → New Connection to initiate a new connection. When connected to multiple servers, a switchbar will show up at the bottom of your Cobalt Strike window.

This switchbar allows you to switch between active Cobalt Strike server instances. Each server has its own button. Right-click a button and select Rename to make the button’s text reflect the role of the server during your engagement. The server button will display the active button in bold text and color based on color preference found in Preferences → TeamServers to better indicate which button is active. This button name will also identify the server in the Cobalt Strike Activity Report.

When connected to multiple servers, Cobalt Strike aggregates listeners from all of the servers it’s connected to. This aggregation allows you to send a phishing email from one server that references a malicious website hosted on another server. At the end of your engagement, Cobalt Strike’s reporting feature will query all of the servers you’re connected to and merge the data to tell one story.

Reconnecting the Client

When the client disconnection is user-initiated with the Menu, Toolbar or Switchbar Server button, a red banner displays with a Reconnect and Close button.

Press Close to close the window. Press Reconnect to reconnect to the TeamServer.

If the TeamServer is not available a dialog displays asking if you want to retry (Yes/No). If Yes then connection is attempted again (repeats if needed). If No , the dialog closes.

When disconnection is initiated by the TeamServer or other network interruption the red banner will display a message with a countdown for connection retry. This will repeat until a connection is made with the TeamServer or the user clicks on Close . In this case the user can interact with other parts of the UI.

When the client reconnects, the red reconnect bar disappears.

Scripting Cobalt Strike

Cobalt Strike is scriptable through its Aggressor Script language. Aggressor Script allows you to modify and extend the Cobalt Strike client.

History

Aggressor Script is the spiritual successor to Cortana, the open source scripting engine in Armitage. Cortana was made possible by a contract through DARPA’s Cyber Fast Track program. Cortana allows its users to extend Armitage and control the Metasploit® Framework and its features through Armitage’s team server. Cobalt Strike 3.0 is a ground-up rewrite of Cobalt Strike without Armitage as a foundation. This change afforded an opportunity to revisit Cobalt Strike’s scripting and build something around Cobalt Strike’s features. The result of this work is Aggressor Script.

Aggressor Script is a scripting language for red team operations and adversary simulations inspired by scriptable IRC clients and bots. Its purpose is two-fold. You may create long running bots that simulate virtual red team members, hacking side-by-side with you. You may also use it to extend and modify the Cobalt Strike client to your needs.

Loading Scripts

Aggressor Script is built into the Cobalt Strike client. To manage scripts, go to Cobalt Strike → Script Manager and press Load .

A default script inside of Cobalt Strike defines all of Cobalt Strike’s popup menus and formats information displayed in Cobalt Strike’s consoles. Through the Aggressor Script engine, you may override these defaults and customize Cobalt Strike to your preferences.

You may also use Aggressor Script to add new features to Cobalt Strike’s Beacon and to automate certain tasks.

To learn more about Aggressor Script, see Aggressor Script .

Running the Client on MacOS X

The Cobalt Strike client may not be able to show contents of the Documents, Desktop, and Downloads folders in the file browser initially. (e.g. loading scripts, uploading files, generating payloads, etc…)

By default, OSX limits what access applications have to the Documents, Desktop, and Download folders. These applications need to explicitly be granted access to these folders.

Since Cobalt Strike is a third party application, it isn’t as straight forward as granting the app “Cobalt Strike” access. You may need to give the JRE running Cobalt Strike client access to the file system. You can give access to the specific Files and Folders or Full Disk Access.

You may be prompted for the access:

client_on-macos

Or, if the access has been previously denied, you may need to edit the access in the OSX System Preferences / Security & Privacy / Privacy dialog:

Please be advised that other applications that use the JRE will also have this access.

NOTE:

The same steps may also need to be taken for ‘/bin/bash’.

User Interface

Overview User Interface

The Cobalt Strike user interface is split into two parts. The top of the interface shows a visualization of sessions or targets. The bottom of the interface displays tabs for each Cobalt Strike feature or session you interact with. You may click the area between these two parts and resize them to your liking

Toolbar

The toolbar at the top of Cobalt Strike offers quick access to common Cobalt Strike functions. Knowing the toolbar buttons will speed up your use of Cobalt Strike considerably.

– Need to continue later.

Session and Target Visualizations

Cobalt Strike has several visualizations each designed to aid a different part of your engagement. You may switch between visualizations through buttons on the toolbar or the Cobalt Strike → Visualization menu.

Pivot Graph

Cobalt Strike has the ability to link multiple Beacons into a chain. These linked Beacons receive their commands and send their output through the parent Beacon in their chain. This type of chaining is useful to control which sessions egress a network and to emulate a disciplined actor who restricts their communication paths inside of a network to something plausible. This chaining of Beacons is one of the most powerful features in Cobalt Strike.

Cobalt Strike’s workflows make this chaining very easy. It’s not uncommon for Cobalt Strike operators to chain Beacons four or five levels deep on a regular basis. Without a visual aid it’s very difficult to keep track of and understand these chains. This is where the Pivot Graph comes in.

The Pivot Graph shows your Beacon chains in a natural way. Each Beacon session has an icon. As with the sessions table: the icon for each host indicates its operating system. If the icon is red with lightning bolts, the Beacon is running in a process with administrator privileges. A darker icon indicates that the Beacon session was asked to exit and it acknowledged this command.

The firewall icon represents the egress point of your Beacon payload. A dashed green line indicates the use of beaconing HTTP or HTTPS connections to leave the network. A yellow dashed line indicates the use of DNS to leave the network.

An arrow connecting one Beacon session to another represents a link between two Beacons. Cobalt Strike’s Beacon uses Windows named pipes and TCP sockets to control Beacons in this peer-to-peer fashion. An orange arrow is a named pipe channel. SSH sessions use an orange arrow as well. A blue arrow is a TCP socket channel. A red (named pipe) or purple (TCP) arrow indicates that a Beacon link is broken.

Click a Beacon to select it. You may select multiple Beacons by clicking and dragging a box over the desired hosts. Press Ctrl and Shift and click to select or unselect an individual Beacon.

Right-click a Beacon to bring up a menu with available post-exploitation options.

Several keyboard shortcuts are available in the Pivot Graph.

Ctrl+Plus — zoom in
Ctrl+Minus — zoom out
Ctrl+0 — reset the zoom level
Ctrl+A — select all hosts
Escape — clear selection
Ctrl+C — arrange hosts into a circle
Ctrl+S — arrange hosts into a stack
Ctrl+H — arrange hosts into a hierarchy.

Right-click the Pivot Graph with no selected Beacons to configure the layout of this graph. This menu also has an Unlinked menu. Select Hide to hide unlinked sessions in the pivot graph. Select Show to show unlinked sessions again.

Sessions Table

The sessions table shows which Beacons are calling home to this Cobalt Strike instance. Beacon is Cobalt Strike’s payload to emulate advanced threat actors. Here, you will see the external IP address of each Beacon, the internal IP address, the egress listener for that Beacon, when the Beacon last called home, and other information. Next to each row is an icon indicating the operating system of the compromised target. If the icon is red with lightning bolts, the Beacon is running in a process with administrator privileges. A faded icon indicates that the Beacon session was asked to exit and it acknowledged this command.

If you use a DNS Beacon listener, be aware that Cobalt Strike will not know anything about a host until it checks in for the first time. If you see an entry with a last call time and that’s it, you will need to give that Beacon its first task to see more information.

Right-click one or more Beacon’s to see your post-exploitation options.

Targets Table

The Targets Table shows the targets in Cobalt Strike’s data model. The targets table displays the IP address of each target, its NetBIOS name, and a note that you or one of your team members assigned to the target. The icon to the left of a target indicates its operating system. A red icon with lightning bolts indicates that the target has a Cobalt Strike Beacon session associated with it.

Click any of the table headers to sort the hosts. Highlight a row and right-click it to bring up a menu with options for that host. Press Ctrl and Alt and click to select and deselect individual hosts.

The target’s table is a useful for lateral movement and to understand your target’s network.

Tabs

Cobalt Strike opens each dialog, console, and table in a tab. Click the X button to close a tab. Use Ctrl+D to close the active tab. Ctrl+Shift+D will close all tabs except the active on.

You may right-click the X button to open a tab in a window, take a screenshot of a tab, or close all tabs with the same name.

Keyboard shortcuts exist for these functions too. Use Ctrl+W to open the active tab in its own window. Use Ctrl+T to quickly save a screenshot of the active tab.

Ctrl+B will send the current tab to the bottom of the Cobalt Strike window. This is useful for tabs that you need to constantly watch. Ctrl+E will undo this action and remove the tab at the bottom of the Cobalt Strike window.

Hold shift and click X to close all tabs with the same name. Hold shift + control and click X to open the tab in its own window.

Use Ctrl+Left and Ctrl+Right to quickly switch tabs. You may drag and drop tabs to change their order.

Consoles

Cobalt Strike provides a console to interact with Beacon sessions, scripts, and chat with your teammates.

The consoles track your command history. Use the up arrow to cycle through previously typed commands. The down arrow moves back to the last command you typed. The history command lists previously typed commands. The ! command allows previously typed commands to be ran again.

NOTE:

The list of previously typed commands is not maintained between sessions. Closing a console window and then reopening it will start with no previously typed commands.

Use the Tab key to complete commands and parameters.

Use Ctrl+Plus to make the console font size larger, Ctrl+Minus to make it smaller, and Ctrl+0 to reset it. This change is local to the current console only. Visit Cobalt Strike → Preferences to permanently change the font.

Press Ctrl+F to show a panel that will let you search for text within the console. Use Ctrl+A to select all text in the console’s buffer.

Tables

Cobalt Strike uses tables to display sessions, credentials, targets, and other engagement information.

Most tables in Cobalt Strike have an option to assign a color highlight to the highlighted rows. These highlights are visible to other Cobalt Strike clients. Right-click and look for the Color menu.

Press Ctrl+F within a table to show the table search panel. This feature lets you filter the current table.

The text field is where you type your filter criteria. The format of the criteria depends on the column you choose to apply the filter to. Use CIDR notation (e.g., 192.168.1.0/24) and host ranges (192.168.1-192.169.200) to filter columns that contain addresses. Use numbers or ranges of numbers for columns that contain numbers. Use wildcard characters (*, ?) to filter columns that contain strings.

The ! button negates the current criteria. Press enter to apply the specified criteria to the current table. You may stack as many criteria together as you like. The Reset button will remove the filters applied to the current table.

Data Management

Overview

Cobalt Strike’s team server is a broker for information collected by Cobalt Strike during your engagement. Cobalt Strike parses output from its Beacon payload to extract targets, services, and credentials.

If you’d like to export Cobalt Strike’s data, you may do so through Reporting → Export Data . Cobalt Strike provides options to export its data as TSV and XML files. The Cobalt Strike client’s export data feature merges data from all of the team servers you’re currently connected to and export TSV and XML files with data in Cobalt Strike’s data model…

Targets

You may interact with Cobalt Strike’s target information through View → Targets . This tab displays the same information as the Targets Visualization.

Press Import to import a file with target information. Cobalt Strike accepts flat text files with one host per line. It also accepts XML files generated by Nmap (the –oX option).

Press Add to add new targets to Cobalt Strike’s data model.

targets_add

This dialog allows you to add multiple hosts to Cobalt Strike’s database. Specify a range of IP addresses or use CIDR notation in the Address field to add multiple hosts at one time. Hold down shift when you click Save to add hosts to the data model and keep this dialog open.

Select one or more hosts and right-click to bring up the hosts menu. This menu is where you change the note on the hosts, set their operating system information, or remove the hosts from the data model.

Services

From a targets display, right-click a host, and select Services . This will open Cobalt Strike’s services browser. Here you may browse services, assign notes to different services, and remove service entries as well.

Credentials

Go to View → Credentials to interact with Cobalt Strike’s credential model.

Press Add to add an entry to the credential model. Again, you may hold shift and press Save to keep the dialog open and make it easier to add new credentials to the model.

Press Copy to copy the highlighted entries to your clipboard.

Use Export to export credentials in PWDump format.

Maintenance

Cobalt Strike’s data model keeps all of its state and state metadata in the data/ folder. This folder exists in the folder you ran the Cobalt Strike team server from.

To clear Cobalt Strike’s data model: stop the team server, delete the data/ folder, and its contents. Cobalt Strike will recreate the data/ folder when you start the team server next.

If you’d like to archive the data model, stop the team server, and use your favorite program to store the data/ folder and its files elsewhere. To restore the data model, stop the team server, and restore the old content to the data/ folder.

Reporting → Reset Data resets Cobalt Strike’s Data Model without a team server restart.

Listener and Infrastructure Management

Overview Listener and Infrastructure Management

The first step of any engagement is to setup infrastructure. In Cobalt Strike’s case, infrastructure consists of one or more team servers, redirectors, and DNS records that point to your team servers and redirectors. Once you have a team server up and running, you will want to connect to it, and configure it to receive connections from compromised systems. Listeners are Cobalt Strike’s mechanism to do this.

A listener is simultaneously configuration information for a payload and a directive for Cobalt Strike to stand up a server to receive connections from that payload. A listener consists of a user- defined name, the type of payload, and several payload-specific options.

Listener Management

To manage Cobalt Strike listeners, go to Cobalt Strike → Listeners . This will open a tab listing all of your configured payloads and listeners.

Press Add to create a new listener. The New Listener panel displays.

Use the Payload drop-down to select one of the available payload/listener types you wish to configure. Each has different parameters and are described in the following sections:

DNS Beacon

HTTP Beacon and HTTPS Beacon

To edit a listener, highlight a listener and press Edit . To remove a listener, highlight the listener and press Remove .

Cobalt Strike’s Beacon Payload

Most commonly, you will configure listeners for Cobalt Strike’s Beacon payload. Beacon is Cobalt Strike’s payload to model advanced attackers. Use Beacon to egress a network over HTTP, HTTPS, or DNS. You may also limit which hosts egress a network by controlling peer- to-peer Beacons over Windows named pipes and TCP sockets.

Beacon is flexible and supports asynchronous and interactive communication. Asynchronous communication is low and slow. Beacon will phone home, download its tasks, and go to sleep. Interactive communication happens in real-time.

Beacon’s network indicators are malleable. Redefine Beacon’s communication with Cobalt Strike’s malleable C2 language. This allows you to cloak Beacon activity to look like other malware or blend-in as legitimate traffic. See Malleable Command and Control for more information.

Payload Staging

One topic that deserves mention, as background information, is payloading staging. Many attack frameworks decouple the attack from the stuff that the attack executes. This stuff that an attack executes is known as a payload. Payloads are often divided into two parts: the payload stage and the payload stager. A stager is a small program, usually hand-optimized assembly, that downloads a payload stage, injects it into memory, and passes execution to it. This process is known as staging.

The staging process is necessary in some offense actions. Many attacks have hard limits on how much data they can load into memory and execute after successful exploitation. This greatly limits your post-exploitation options, unless you deliver your post-exploitation payload in stages.

Cobalt Strike does use staging in its user-driven attacks. These are most of the items under Attacks → Packages and Attack s → Web Drive-by . The stagers used in these places depend on the payload paired with the attack. For example, the HTTP Beacon has an HTTP stager. The DNS Beacon has a DNS TXT record stager. Not all payloads have stager options. Payloads with no stager cannot be delivered with these attack options.

If you don’t need payload staging, you can turn it off. Set the host_stage option in your Malleable C2 profile to false. This will prevent Cobalt Strike from hosting payload stages on its web and DNS servers. There is a big OPSEC benefit to doing this. With staging on, anyone can connect to your server, request a payload, and analyze its contents to find information from your payload configuration.

In Cobalt Strike 4.0 and later, post-exploitation and lateral movement actions eschew stagers and opt to deliver a full payload where possible. If you disable payload staging, you shouldn’t notice it once you’re ready to do post-exploitation.

DNS Beacon

The DNS Beacon is a favorite Cobalt Strike feature. This payload uses DNS requests to beacon back to you. These DNS requests are lookups against domains that your Cobalt Strike team server is authoritative for. The DNS response tells Beacon to go to sleep or to connect to you to download tasks. The DNS response will also tell the Beacon how to download tasks from your team server.

dns-beacon_example

Cobalt Strike 4.0 and later, the DNS Beacon is a DNS-only payload. There is no HTTP communication mode in this payload. This is a change from prior versions of the product.

Data Channels

Today, the DNS Beacon can download tasks over DNS TXT records, DNS AAAA records, or DNS A records. This payload has the flexibility to change between these data channels while its on target. Use Beacon’s mode command to change the current Beacon’s data channel. mode dns is the DNS A record data channel. mode dns6 is the DNS AAAA record channel. And, mode dns-txt is the DNS TXT record data channel. The default is the DNS TXT record data channel.

Be aware that DNS Beacon does not check in until there’s a task available. Use the checkin command to request that the DNS Beacon check in next time it calls home.

DNS Listener Setup

To create a DNS Beacon listener select Cobalt Strike → Listeners on the main menu and press the Add button at the bottom of the Listeners tab display.

The New Listener panel displays.

Select Beacon DNS as the Payload type and give the listener a Name . Make sure to give the new listener a memorable name as this name is how you will refer to this listener through Cobalt Strike’s commands and workflows.

Parameters

DNS Hosts - Press [+] to add one or more domains to beacon to. Your Cobalt Strike team server system must be authoritative for the domains you specify. Create a DNS A record and point it to your Cobalt Strike team server. Use DNS NS records to delegate several domains or sub-domains to your Cobalt Strike team server’s A record.

The length of the beacon host list in beacon payload is limited to 255 characters. This includes a randomly assigned URI for each host and delimiters between each item in the list. If the length is exceeded, hosts will be dropped from the end of the list until it fits in the space. There will be messages in the team server log for dropped hosts.

Host Rotation Strategy - This value configures the beacons behavior for choosing which host(s) from the list to use for egress. Select one of the following:

round-robin : Select to loop through the list of host names in the order they are provided. Each host is used for one connection.

random : Select to randomly select a host name from the list each time a connection is attempted.

failover-xx : Select to use a working host as long as possible. Use each host in the list until they reach a consecutive failover count (x) or duration time period (m,h,d), then use the next host.

rotate-xx : Select to use each host for a period of time. Use each host in the list for the specified duration (m,h,d), then use the next host.

Max Retry Stategy - This configures the beacons behavior for exiting after a number of consecutive failed connection attempts to the Team Server. There are several default options to choose from or you can create your own list with the LISTENER_MAX_RETRY_STRATEGIES hook. See LISTENER_MAX_RETRY_STRATEGIES .

none : Select to ensure beacon will not exit because of failed connection attempts.

exit-xxx : These settings use the syntax of exit-[max_attempts]-[increase_attempts]-[duration][m,h,d]. The max_attempt value is the number of consecutive failed attempts before beacon will exit. The increase_attempts is the number of consecutive failed attempts before increasing the sleep time. The duration value is the number of minutes, hours, or days to set the new sleep time.

The sleep time will not be updated if the current sleep time is greater than the newly specified duration value. The sleep time will be affected by the current jitter value. On any successful connection the failed attempts count will be reset to zero and the sleep time will be reset to the prior value.

DNS Host (Stager) - This configures the DNS Beacon’s TXT record stager. This stager is only used with Cobalt Strike features that require an explicit stager. Your Cobalt Strike team server system must be authoritative for this domain as well.

Profile - Allows a beacon to be configured with a selected Malleable C2 profile variant.

DNS Port (Bind) - This field specifies the port your DNS Beacon payload server will bind to. This option is useful if you want to set up port bending redirector such as a redirector that accepts connections on port 53 but routes the connection to your team server on another port.

DNS Resolver - Allows a DNS Beacon to egress using a specific DNS resolver, rather than using the default DNS resolver for the target server. Specify the IP Address of the desired resolver. This DNS Resolver is not used by the stager of the DNS Beacon.

Testing

To test your DNS configuration, open a terminal and type nslookup jibberish.beacon domain . If you get an A record reply of 0.0.0.0—then your DNS is correctly setup. If you do not get a reply, then your DNS configuration is not correct and the DNS Beacon will not communicate with you.

Notes

Make sure your DNS records reference the primary address on your network interface. Cobalt Strike’s DNS server will always send responses from your network interface’s primary address. DNS resolvers tend to drop replies when they request information from one server, but receive a reply from another.
If you are behind a NAT device, make sure that you use your public IP address for the NS record and set your firewall to forward UDP traffic on port 53 to your system. Cobalt Strike includes a DNS server to control Beacon.
To customize the network traffic indicators for your DNS beacons, see DNS Beacons in the Malleable C2 hel

HTTP Beacon and HTTPS Beacon

The HTTP and HTTPS beacons download tasks with an HTTP GET request. These beacons send data back with an HTTP POST request. This is the default. You have incredible control over the behavior and indicators in this payload via Malleable C2.

HTTP(S) Listener Setup

To create a HTTP or HTTPS Beacon listener select Cobalt Strike → Listeners on the main menu and press the Add button at the bottom of the Listeners tab display.

The New Listener panel displays.

Select Beacon HTTP or Beacon HTTPS as the Payload type and give the listener a Name . Make sure to give the new listener a memorable name as this name is how you will refer to this listener through Cobalt Strike’s commands and workflows.

Parameters

HTTP(S) Hosts - Press [+] to add one or more hosts for the HTTP Beacon to call home to. Press [-] to remove one or more hosts. Press [X] to clear the current hosts. If you have multiple hosts, you can still paste a comma-separated list of callback hosts into this dialog.