Cobalt Strike 4.13 is now available. This release brings C scripting directly into Cobalt Strike via the new Beacon Interpreter, solves some long-standing issues with BOFs by adding BOF-PE support, and adds a new LLVM Beacon. It also enables centralised management and version control of all exported payloads through the Payload Store, resolves the need to restart the Teamserver to change Malleable C2 settings via Malleable Profile Overrides, and adds support for full streaming via WebSockets and gRPC.

Additionally, we have added support for modern docking and customisable tables in the Cobalt Strike UI, overhauled credential management, and made numerous UX and QoL improvements to significantly enhance existing Red Team workflows.

4.13 Release Comic
Click to expand

Do the Post-Ex Evolution

Beacon Object Files (BOFs) have been a hugely important development in Beacon’s Post-Ex capabilities. They have proven to be extremely popular and a very powerful way to expand Beacon’s functionality.

BOFs were originally designed by Cobalt Strike founder Raphael Mudge as an abstraction over writing position independent code (PIC) with some of the conveniences restored (e.g. dynamic function resolution etc.). Hence, BOFs were  intended to be lightweight and have minimal overhead when executing in memory by design.

Over time, operators have pushed this design to its limit. Many users have wanted to write more complex tradecraft (i.e. ‘abstract up’) and have got frustrated with the lack of support for higher-level language abstractions (e.g. exception handlers).

Additionally, there are also times when the workflow of BOFs feels clunky due to the requirement of needing to allocate memory. For example, if you write a BOF to simply free memory, Beacon still needs to allocate (and free) memory in order to execute it.

In Cobalt Strike 4.13, we are introducing the Beacon Interpreter and BOF-PE support to solve these problems.

The Beacon Interpreter

The Beacon Interpreter enables Cobalt Strike users to write scriptable C code which can be directly executed by Beacon. When you run a Beacon Interpreter script (e.g. helloworld.c), the Teamserver will compile it to intermediate byte code and then send it to Beacon to be executed in a virtual machine, as shown in the diagram below:

Fig 1:A high-level diagram showing how the Beacon Interpreter works under the hood.

As the VM is native to Beacon, it does not need to allocate any additional memory (or fluctuate the memory permissions of previously allocated memory). Furthermore, because the compilation is handled by the Teamserver, users do not need to compile their C scripts ala BOFs. The Beacon Interpreter was initially based off the open-source picoc project, however we have significantly re-architected / expanded upon it to suit Beacon’s requirements.

Users can interact with the Beacon Interpreter via the beacon-interpreter command, the aggressor function bbeacon_interpreter, and via the REST API. However, we have also added a Script Editor view (i.e. IDE) directly into the Cobalt Strike GUI. This idea came from dogfooding the Beacon Interpreter and from some frustrations with the slow feedback loop associated with BOF development (write BOF, compile it, re-run it, check Beacon Console, repeat etc.). With the Script Editor you can rapidly develop capabilities from within the Cobalt Strike client and get near instantaneous feedback.

It is very easy to write or port existing C code to the Beacon Interpreter and it attempts to align closely to the C standard between C89/C99. However, there are some subtleties when interacting with the Windows API. For the Beacon Interpreter to know how to call a given Windows API, it needs a BOF style DFR function definition as shown below for LoadLibraryA:

KERNEL32$LoadLibraryA: ptr (ptr);

A full explanation of the syntax above is out of scope for the release blog, but see the documentation here and here for more information. However, once declared, LoadLibrary can be used as per standard Windows development.

To make life as easy as possible, the Teamserver comes bundled with a number of headers for common Windows functionality. These can be accessed via standard C includes, e g. #include <msvcrt.h> to access the Microsoft C runtime. Beacon Interpreter scripts also have full access to the BOF API via the #include <beacon.h> header. Additionally, if you need to debug scripts via tools such as DebugView, we have included a DbgPrintf function available in internal.h.

As a word of caution, these headers are not a 1:1 mapping with their respective Windows headers and there will be gaps, but you can add your own headers to the Teamserver via the server/interpreter/includes/user folder which will be picked up immediately.

The video below goes through all these steps and gives a feel for the Beacon Interpreter in action:

Video 1: A demo showing how to get up and running with the Beacon Interpreter.

We have been experimenting with the Beacon Interpreter throughout development and have endeavoured to make it as robust as possible but there still may be edge cases in the compiler that need to be resolved. If you do find an issue, please let us know via our feedback form (Support -> Cobalt Strike Feedback Form) and if possible, a copy of a test script to reproduce the issue.

Lastly, to help script development we have open sourced a Beacon Interpreter repository on our public Github which contains a copy of the headers Cobalt Strike ships with, a skills.md to aid AI agents, and an example Beacon Interpreter script.

BOF-PE

In Cobalt Strike 4.13, we have added support for BOF-PEs. This new format was originally proposed by @CCob and was designed to solve some of the limitations of BOFs previously raised.

This means operators can now develop tradecraft in DLL/EXE format that supports error handling, advanced C++ features, external libs, and the BOF API, without needing to employ work arounds that BOF writers frequently employed. The beauty of BOF-PEs is that you can decide on how small or feature rich the tradecraft you employ is. It also opens the door to writing post-ex tooling in other languages (i.e. Rust).

You can run BOF-PEs via the new inline-execute-pe command (or via aggressor binline _execute _pe), as shown below:

Fig 2: A screenshot showing the new inline-execute-pe command in the Beacon console.

We are planning to release our own BOF-PE template but for now we recommend using CCob’s, which can be found here.

Additionally, we have also added BOF-PE support to UDC2. Hence, if you want to write a more complex C2 channel that requires 3rd part libs etc., BOF-PE makes it easier to incorporate these requirements into your custom tooling.

Transforming Beacon

Beacon has historically relied upon the Microsoft Visual C++ (MSVC) compiler. However, a long-term ambition for the Cobalt Strike team has been to migrate Beacon to use the LLVM compiler toolchain due to its novel capabilities. We have previously demonstrated some of our research into these capabilities via our release of the Mutator Kit and Austin Hudson’s booth presentation at Black Hat 2025.

In this release, we have taken a huge step forward in our research and are introducing a new LLVM Beacon. This is a Beacon built using the LLVM toolchain which contains a custom C runtime and has a much smaller payload size.

You can choose which Beacon you would like to use (MSVC or LLVM) when creating a listener, as shown in the screenshot below:

Fig 3: A screenshot of the Listener Creation dialogue with the new ‘Template’ option highlighted.

This is just the start of our LLVM journey (watch this space) and we intend to deprecate the MSVC Beacon in the next release.

Payload Management: Malleable Profile Overrides and Payload Store

One common challenge when working with Cobalt Strike’s customisation features, such as UDRLs/Sleepmasks, is version control of specific payloads. This process often entails multiple iterations of payload creation and the sharing of specific payload versions across a wider team which can get unwieldy.

To overcome these issues, we have added the Payload store, which adds centralised storage and versioning of Beacon payloads (h/t to Cody Thomas for his work on Mythic which inspired some of these changes).

Now every running Beacon can be traced back to its specific version in the payload store (and hence the configuration it was exported with), and all exported Beacon payloads are now automatically tracked by Cobalt Strike. Additionally, the inject/spawn commands now support being passed a specific payload name from the payload store, which greatly simplifies workflows.

Furthermore, for those customers that have subscribed to Cobalt Strike Research Labs (CS:RL) the payload store provides a seamless integration with CS:RL and Beacon Booster. As an example, you can export a “boosted” Beacon from CS:RL, add it to the payload store, and incorporate it throughout your operations.

Additionally, we have introduced Malleable Profile Overrides to solve the longstanding problem of needing to restart the Teamserver in order to modify a specific Malleable C2 setting.

You can now modify your Malleable Profile to enable / disable specific settings when exporting a payload. For example, if you’re experimenting with UDRL development, you can create/save a Malleable C2 override (.mpo) to disable the Sleepmask and apply this setting to specific payloads. This metadata is also captured in the payload store.

note
Malleable Profile Overrides only apply to payload specific settings. If you want to modify options which impact a listener, you will still need to restart the Teamserver.

The demo below shows the payload management features (as well as the LLVM Beacon) in action:

Video 2: A demo showing the new payload management features in Cobalt Strike 4.13.

UX

We have continued to build upon the GUI updates made in 4.12 by adding:

  • Support for docking in the UI.
  • New fonts and improved copy and paste behaviour. As an example, you can now copy by value/row for any table/tree view.
  • Ctrl-left/right now jumps words in the Beacon console.
  • Customisable tables via Aggressor. The idea behind this was to provide a more user-friendly way of rendering information which may be dumped to the Beacon console (e.g. the results of an LDAP query). Furthermore, these tables support custom actions (i.e. you can right click on a field within the table and use it to trigger a specific action).

The demo below shows these features being combined to dump the results of an LDAP query into a custom table and then fire off further actions (‘Query CN’) based on the results:

Video 3: A demo showing the new customisable tables in action in combination with Trusted Sec’s ldapsearch BOF.

Credential Management

We have refreshed the credential store to support modern credentials and provide a better user experience by:

  • Adding support for highlighting text in the Beacon console and adding it to the credential store via a right-click. This means it is much simpler to parse and manage Kerberos tickets from the Beacon console.
  • Adding support for custom right-click actions in the credential store (this works the same way as for user customisable tables).
  • Decluttered the credential tab and updated the credential data model.

The demo below shows an internal experiment in chaining these features together, via an Aggressor script for Rubeus that we will open source soon, to create much smoother workflows for handling Kerberos tickets:

Video 4: A demo showing a reimagined red team workflow for handling Rubeus tickets within Cobalt Strike.

note
This demo uses a custom Aggressor script for Rubeus to automatically parse Kerberos tickets and add them to the credential store via the Aggressor function credential_add.

Automation

We also wanted to build on the REST API which was released in Cobalt Strike 4.12:

  • We have now added support for full streaming via WebSockets and gRPC. This avoids a need for ‘status polling’ and thus provides better integration with other tooling in the Cobalt Strike ecosystem.
  • One issue in the initial release of the REST API was that not all tasks were automatically marked as completed. This was due to constraints in Beacon’s C2 communications which have now been fixed. Hence, all tasks are now marked as completed (or cancelled).

The video below shows WebSockets and gRPC in action:

Video 5: A demo showing the new WebSockets and gRPC streaming in action.

Additional Updates

This release also contains a number of additional QoL updates, including:

  • Beacon now supports the checkin_delay Malleable C2 option. This will delay Beacon’s initial check-in to break event correlation detection heuristics on reflective loading and the immediate metadata exchange.
  • There is now no size limit on either Sleepmask BOFs or UDC2 BOFs/BOF-PEs.
  • To speed up the feedback loop for Aggressor Scripting, we have added a brk() function. When this function is hit, Aggressor will break script execution and display the script engine state, local variables, stack etc.
  • The default Cobalt Strike Sleepmask now performs return address spoofing for all proxied BeaconGate calls.
  • We have added a new (opt in) payload export type for Cobalt Strike Research Labs – CS:RL. This will export Beacon in a format which can easily be ingested by the Beacon Booster to apply bespoke tradecraft. For more information on CS:RL see this blog post.
  • As per Rastamouse’s BOF Cocktails blog, there is a new Aggressor hook, BEACON_INLINE EXECUTE, which allows users to hook all BOFs pre-execution. This enables users to use tools such as Crystal Palace to merge in tradecraft on the fly to all BOFs.
  • We have updated the process explorer view so that it gathers additional context such as the integrity level, command line arguments etc. This is shown in the screenshot below:
New Process Listing in Cobalt Strike
Click to expand
Fig 4: A screenshot showing the updated process listing for Cobalt Strike 4.13, which now contains additional fields such as the integrity level, command line arguments etc.

To see a full list of what’s new in Cobalt Strike 4.13, please check out the release notes.

To purchase Cobalt Strike or learn more, please contact us.

Lastly, if you have ideas/feedback on the current state of Cobalt Strike, or thoughts on the next release, please:

  • Fill in our customer survey
  • A large part of the Cobalt Strike R&D team will be at Blackhat USA 2026 – drop by the Fortra booth if you would like to chat!
  • Send us your thoughts via the Cobalt Strike feedback form (Support -> Cobalt Strike Feedback Form)

William Burgess

Principal Research Lead
View Profile
RELATED PRODUCTS
TOPICS