Cobalt Strike for Red Team Operations

What is Cobalt Strike? Cobalt Strike is a commercially available adversary simulation tool that can emulate tactics, techniques, and procedures (TTPs) of a long-term embedded threat actor in networks. This helps red teams (offensive security teams) and ethical hackers simulate advanced persistent threats (APTs) and test an organizations security posture, incident response, and provides value to relevant stakeholders for improving upon the latter.

Malicious hackers also take advantage of these tools as well, so understanding their use and Indicators of Compromise (IoC) delivers dividends to blue teams (cybersecurity teams).

Definitions:

  • C2 - Command and Control

  • Team Server - Cobalt Strike’s server component where listeners for beacons are configured and running.

  • Listener - Service running on the attacker C2 server that is waiting for a beacon callback.

  • Beacon - Malicious agent on the victim’s system that calls back to the attacker C2 server and checks for any new commands that should be executed on the victim’s system.

Starting the Cobalt Strike Server:

In order to start the server we will have to do so from a Linux machine. This can be done by starting the team server script in the cobalt strike directory. Be advised, due to the commercial nature of the tool this is not a free tool. Obtaining this requires a license, a free alternative is PowerShell Empire or StarKiller.

Connecting to the Cobalt Strike Server from the Client:

In order to connect to the server from a client you will run the cobaltsrike script which starts the Cobalt graphical client. This requires the server address and port, your username (nickname), and team server password field to be populated- then you can connect (you can also use a client from a Windows machine):

3 Things to Know About Being on a Team Server (collaboration features):

  1. Session sharing: Both clients have access to any sessions on the team server and will see the same team sessions, beacons, and can interact with them as they wish.

  2. Data Sharing: Both clients have access to the data model for this server. They can see applications, credentials, downloads, event logs, keystrokes, proxy pivots, screenshots, a script console, targets, and a web log.

  3. Real-Time Communication: The event log works similar to IRC (Internet Relay chat), where operators can communicate. You can see who is in your channel (event log), display actions, or direct message specific colleagues.

Distributed Operations (more collaboration and redundancy):

You can connect to multiple team servers, where there are different communication channels. Why connect to multiple servers? You are easy to mitigate if your only method of access is limited to one method. Multiple servers with different contexts surrounding how they’re maintained may save your access and provide the redundancy that is ideal to have when maintaining persistence.

You can start a new connection by going to cobalt strike -> New Connection:

You can switch between active team server clients at a whim. You can also rename these buttons that appear on the lower aspect of your window in order to better track your workflow.

Model for Multiple Servers in a C2 Framework:

  1. Server for Initial Access: This is a server for your initial callbacks and used to spread laterally to another system. Your first server is at very high-risk of being found and remediated. This is where you first install persistent services to retain your access by creating the second type of server.

  2. Long-Haul server: Ideally, you should set up a fallback lifeline on the system you compromise. It should perform very low/slow persistent callbacks, maintain persistence in a different way from the first server, and serve you in-case your initial access server is remediated. Operational Security should be a concern here, evade making decisions that will be caught by a blue team or A/V, EDR, SIEMs, or other security solutions.

  3. Post-Exploitation Server: This is where you operate from when meeting post-exploitation objectives and additional lateral movement. You request a new session from post-exploitation server from one of your long-haul access servers.

If your separation is good enough, your long-haul access should survive, and you will have the option to continue the engagement and objectives at a later time.

Scaling Red Team Operations and Team Roles:

Target Cells - Responsible for objectives in their specific target networks. They gain access, post-exploitation, and spread laterally. They also maintain local infrastructure tasks.

Access Management Cells - Pass access back to target cells when they lose access. It is important for this team to maintain adequate separation to maintain the latter model. Access management is important enough to devote a red team resource to, and the responsibility scales very well.

It is important to separate team resources toward meeting certain objectives of the assessment requirements.

  • Access: Team dedicated to obtaining initial footholds and expanding upon this achievement, including weaponization (creating custom payloads / post-compromise activities) and lateral movement.

  • Post-Exploitation: Team focused on objectives to meet in target network. Exploring the file system, monitoring keystrokes / users, data mining, and identifying any high-value targets and opportunities.

  • Local Access Manager (LAM): Individual focused on managing callbacks, setting up infrastructure, persistence, and passing sessions amongst other LAMs.

Logging and Reporting with Cobalt Strike:

Cobalt Strike logs everything that happens on team servers inside of the folder you’ve started the server from /logs/ with files prepended with a period:

  • Beacon activity: Transcript of what occurred (all commands and outputs received from payloads, easily greppable outputs).

  • Other: Keystrokes, Screenshots, and Team Server communications.

There is a reporting menu specifically for generating reports that aid the customer and relevant stakeholders in their identifying lessons learned and how they can improve their incident response times, readiness, and security posture as needed or post-assessment.

Features:

  • You’re able to output the data as PDF and MS word documents.

  • Generate custom reports and change logos.

  • Merge data from multiple Team Servers.

Value Included in Reports:

  • Indicators of Compromise: Domains and IP addresses, file hashes, samples of proof-of-concept (PoC), and other relevant threat intelligence narrative info.

  • Activity Report: A timeline of all the actions taken with the Cobalt Strike product on Team Servers (when/where/why).

  • Sessions Report: Host-by-Host operations notes that breaks up activity by session and target, where you can see an individual activity summary, communication path, and information about each session.

  • Tactics, Techniques, and Procedures (TTPs): In the context of the MITRE ATT&CK Framework, includes summary of tactics, mitigations, detection methods, and references to professional sources for what is exploited.

Thank you for taking the time to read about how Cobalt Strike fulfills the objectives of Red Team Operators, for more information see the source below for a lecture:

Mudge, R. (2022). Red Team Ops with Cobalt Strike - Operations (1 of 9). YouTube. https://www.youtube.com/watch?v=q7VQeK533zI

Previous
Previous

Golang for Offensive Security

Next
Next

PowerShell Empire for Red Team Operations