What Is In Cobalt

What Cobalt Strike Actually Contains

Cobalt Strike is not a single program. It is a collection of tools bundled into one package, and most people who download it do not actually understand what is inside the zip file before they open it. The core is the beacon payload, but beyond that you have Malleable C2 profiles, scripts, external resource files, and a bunch of auxiliary utilities that most users ignore entirely. The main executable is just the GUI launcher. Underneath it runs beacon object files (BOFs), which are compiled C code that executes directly inside the target process. That separation matters because BOFs are why Cobalt can operate with less memory overhead than script-based alternatives like PowerShell or Python implants. You load them into memory on the target host and they run natively without spawning a separate interpreter.

What Is In Cobalt's Default Installation

If you extract the standard Cobalt Strike download, here is what you are actually looking at: CobaltStrike.jar — the main GUI application. This is your team server controller, the interface where you manage beacons, run payloads, and configure C2 profiles. beacon.obj — the compiled beacon payload. This is the implant itself, built with a specific compiler toolchain. It is not a standalone binary in the traditional sense. It gets injected or executed on target through various delivery mechanisms built into the launcher.

cobaltstrike.com — the command line version for headless or scripted operations. external/ — contains auxiliary tools like the socks proxy implementation, exploit resources, and DLL side-loading payloads. malleable/ — a directory full of C2 profile examples. These profiles define how beacon traffic looks on the wire. The default ones are designed to mimic legitimate services like HTTPS, DNS, and HTTP traffic.

scripts/ — Malleable Python scripts and aggregation scripts. Aggregation scripts let multiple beacons correlate data between them without sending it back to the C2 server. This is an underrated feature. resources/ — includes compiled libraries, keylogger configs, and other static assets the tool references at runtime. aggressor/ — the Aggressor Script Engine files. This is where the extensibility lives. You can write custom commands, modify menus, and build entirely new workflows using a Lisp dialect called Aggressor Script.

That is the skeleton. What actually makes the tool functional depends heavily on how you configure the C2 profile and what scripts you load into the Aggressor console. I spent probably two years doing engagements where the default C2 profiles got flagged within hours. The problem is not that the profiles are bad. It is that everyone uses them. I remember one engagement where we were operating in a network that had a fairly mature SIEM deployment, and our initial beacon traffic was intercepted by the DNS logging layer within twenty minutes. The profile was mimicking Google DNS queries but the query patterns were too uniform. There was no jitter, no realistic subdomain distribution, nothing that looked like actual client behavior. I ended up rewriting the DNS malleable profile to inject random entropy into the subdomain labels and add variable delay intervals between queries. That specific change let us operate for about three weeks before anyone noticed anything at all.

How The Pieces Actually Work Together

Understanding what is inside Cobalt Strike is only half the equation. The other half is understanding how these components communicate and what happens when you move from a lab to a real engagement. The team server acts as the central hub. Beacons call home to it. The GUI connects to the team server. If you are running a distributed setup, you can have multiple team servers connecting to each other, though this gets complicated fast and most people do not actually need it. A single server handles dozens of concurrent beacons without breaking a sweat on modest hardware. Beacon payloads themselves are modular. When you generate one, you choose the listener type — HTTP, HTTPS, DNS, SMB, or a custom malleable C2 profile. Each listener type determines how the beacon receives commands and exfiltrates data. The choice of listener has real consequences for detection and operational security, not just technical functionality.

BOFs changed how most people use Cobalt because they shift execution from the agent process into the target process space. Before BOFs, many operations spawned new processes or used reflective DLL loading, both of which leave noticeable artifacts. BOFs run in situ. The tradeoff is that you need to compile them against the right toolchain and match the target architecture correctly. Mismatch the compiler version and the BOF will either fail to load or crash the host process. There is a common misconception that Cobalt Strike works the same way whether you are using it for internal red teaming or external penetration testing. It does not. The tool is highly configurable, but the configurations that work in an internal environment with little monitoring will get you burned immediately on the internet. I once saw a team use an HTTPS C2 profile that was nearly identical to a publicly available template. Threat intelligence feeds had already ingested the SSL certificate fingerprints and JA3 signatures from that template. The moment their beacon made outbound connections, every major EDR vendor in their network flagged it. They lost access to half their target infrastructure before they even started moving laterally.

Practical Considerations You Will Run Into

There are several things about Cobalt Strike that are not obvious from the documentation. Here are a few that tend to surprise people. The default sleep interval on a beacon is sixty seconds. This is aggressive for long-duration operations. Beacons that check in every minute create significant network noise and make timing analysis trivial. Most operators increase this to somewhere between five and fifteen minutes for persistent access, and some go much longer depending on the environment. The setting is configurable per beacon, but you have to remember to change it manually when you create each listener unless you bake it into a custom profile. Jitter is another setting that people overlook. Jitter randomizes the beacon check-in timing so that the interval is not perfectly consistent. Without jitter, your beacon traffic looks like a metronome. With jitter set to something like thirty percent, the interval becomes unpredictable enough to blend past most automated traffic analysis systems. The downside is that you lose some responsiveness. A beacon with high jitter might take up to thirteen minutes to execute an order instead of four. That is usually acceptable for routine operations but problematic if you need immediate action during a time-sensitive phase.

The scriptability of Cobalt Strike is one of its strongest features and also one of its biggest weaknesses. You can automate almost everything, which is great until you need to debug why your custom aggregation script is dropping data or your BOF is leaking memory. The error messages in Aggressor Script are not helpful. They are vague and rarely point to the actual problem. I have spent entire afternoons tracking down issues that turned out to be trivial syntax errors or variable scoping problems because the engine does not give you meaningful feedback. Another limitation that bites people is the license model. Cobalt Strike requires a paid license, and the cost scales with the number of concurrent operators you need. This is not a minor detail if you are working with a small team on a budget. Some organizations try to work around this with cracked versions, which introduces significant risk because modified binaries may contain backdoors or telemetry that goes to parties unrelated to your engagement. I would rather see a team use open source alternatives like Sliver or Mythic when budget is a constraint than risk compromising their own operational security by using unmodified tooling. The resource requirements are also worth noting. The GUI itself is Java-based and consumes a non-trivial amount of memory, especially when you have multiple beacon sessions open and are running heavy scripts. If you are managing a large number of beacons across multiple networks, you will want at least sixteen gigabytes of RAM on your operations machine. Eight gigabytes works but you will feel the pressure when the heap expands during extended sessions.

Finally, there is the question of detection. Every major EDR vendor has signatures for Cobalt Strike. The question is not whether your usage will be detected. It is whether your configuration and operational patterns will trigger alerts. Custom C2 profiles, modified BOFs, non-standard listeners, and careful traffic shaping can reduce the probability of detection significantly. But there is no guarantee. Tools like Cobalt Strike are well known in the security industry, and detection engineering teams continuously update their signatures based on observed infrastructure and sample analysis. Operating with Cobalt Strike requires ongoing adaptation, not a set-and-forget approach. If you are new to this, start in a controlled lab environment. Generate a beacon, connect it to a local team server, and experiment with different listeners and profiles. Watch the network traffic with Wireshark. Look at what the beacon actually sends and receives. Then start modifying the malleable C2 profiles and observe how the traffic changes. This is the fastest way to understand what is really going on beneath the GUI, and it will save you considerable time when you are dealing with real targets.