New Mouse in the House: Zero-Point Security Training Joins the Fortra Family
For those who don’t know me, my name is Daniel Duggan, known online as RastaMouse. I spent over a decade working as a penetration tester and red teamer across the public and private sector, before founding Zero-Point Security in 2018. My mission was to build the kind of training I wish had existed when I was coming up: practical, accessible, cost-effective, and rooted in real adversary tradecraft.
My Red Team Ops and Red Team Ops II training courses are the fruits of that labour, which are now recognised across multiple industry sectors including financial services, military, manufacturing, and naturally, security consultancies.
In 2025, Fortra and Zero-Point Security collaborated to launch a dedicated Cobalt Strike training course, giving operators a hands-on foundation in red team assessments and adversary simulations, built directly around the tool. The response made it clear there was appetite for a lot more.
Today I’m happy to share that we’re making it official. Fortra has acquired Zero-Point Security, and I’m joining the team to build out the next generation of offensive security training.
Building Training Alongside the Tools
When it comes to offensive security, tooling is only part of the equation – the operators using those tools need training that’s just as sharp. One limitation of building training with commercial tools is that you’re always working slightly in the dark. You can write great content around a tool’s public capabilities, but you don’t have insight into what’s coming next, why certain design decisions were made, or how features could be used at a deeper level.
That changes completely when you’re sitting with the tool developers. Courses can go deeper and stay current for longer as the tool evolves and new versions are released. Feedback from training can even flow back into the product design.
The Cobalt Strike collaboration was a preview of what it looks like to integrate training and development. And now, having joined the team, that will become the default, not the exception.
Why Now?
I’m blessed and honoured to have been able to build a successful business, made possible in no small part by the support of the cybersecurity community. But it’s fair to say that the size and complexity of the business have outgrown what I’m able to handle alone. More of my time is being taken up on platform engineering, compliance, licensing, operations, coordination, and other admin tasks, rather than what I love – which is writing training material and interacting with the students.
Joining Fortra means handing those aspects over to their team of experts, allowing me to get back to grassroots. The strength of my existing working relationship with Fortra and the success of the aforementioned collaboration, made it a no-brainer when the opportunity to join came up.
What I’m Bringing with Me
The entirety of Zero-Point Security’s existing course and certification catalogue are coming to Fortra:
Red Team Ops I: Introduction toadversary simulation and emulation exercises, leading to the “CRTO” certification.
Red Team Ops II: How tooperate against advanced defenses and EDR, leading to the “CRTL” certification.
These courses, labs, and exams will remain as core products of the Zero-Point Security brand.
What’s on the Roadmap
New training courses are already being planned and developed. First, an Advanced Cobalt Strike Certified operator course will go deeper on adversary simulation with Cobalt Strike, building on the foundation we established with the initial collaboration.
From there, we will analyze developments in the offensive industry as well as Fortra’s other offensive tools. The goal is to offer a comprehensive offensive security training portfolio that allows organisations to invest upskilling their security teams on platforms that they’ll use operationally, with hands-on labs and real-world scenarios.
Further details and timelines will follow as I settle into my new role and these programs take shape.
Get in Touch
If you have questions, you can reach me directly at [email protected], X (@_RastaMouse), or BlueSky (rastamouse.me). In the meantime, check out the full press release for the official details.
I’m looking forward to what comes next.
Introducing Cobalt Strike Research Labs
Today, we’re launching Cobalt Strike Research Labs (CS:RL), a new Fortra offering that unites the research expertise of the Cobalt Strike and Outflank teams. CS:RL delivers cutting-edge, ready-to-use research tooling for Cobalt Strike, including custom UDRLs, Sleep Masks, UDC2 channels, and post-exploitation capabilities. Most importantly, it provides the Cobalt Strike team with a platform to deliver experimental beta features, test ideas, and gather feedback before moving proven features into the main product.
CS:RL is available now as part of Fortra’s Red Team Suite and the Offensive Security Suite. We are releasing CS:RL in beta but this is just the beginning; we already have an exciting roadmap of features planned.
In this post, we’ll cover the rationale behind CS:RL, the problems it is designed to solve, and the capabilities it brings to operators.
Why Cobalt Strike Research Labs?
Cobalt Strike and Outflank Security Tooling (OST) have very different product philosophies. Cobalt Strike’s technical strategy is built around two core principles:
Flexibility and Modularity – Cobalt Strike offers limited ‘out-of-the-box’ evasion by design and this is not a goal of the product. Instead, it gives operators the flexibility to rapidly customize and reconfigure Beacon for use across different scenarios, ranging from Purple Teaming to full-scope Red Team operations. Through UDRLs such as CrystalKit, TitanLdr, AceLdr, and Eden, Beacon’s TTPs can be completely changed depending on the operator’s requirements. Furthermore, Cobalt Strike is designed to be highly modular and so supports the integration of tools/PoCs from the wider offensive eco system (i.e. BOFs).
Stable and fully offline framework – Cobalt Strike has a semi-annual release cycle with a strong emphasis on quality assurance and use in offline environments.
By contrast, OST is focused on a different but highly complementary set of priorities:
A broad set of offensive security tooling, ranging from initial access and lateral movement to credential dumping and cloud attacks.
A cloud native offering, which supports rapid updates and bi-weekly releases.
Out-of-the-box EDR evasion capabilities.
Taken together, these differences are exactly why we decided to create Cobalt Strike Research Labs. Cobalt Strike provides a stable, flexible foundation that enables deep operator-driven customization, while OST delivers fast access to new offensive research and implementations. CS:RL brings these strengths together: the research depth of the Outflank and Cobalt Strike teams, delivered in a form that helps operators put new tradecraft into practice faster.
This collaboration gives the Cobalt Strike team a new way to move faster and deliver more value to customers. Through CS:RL, the Cobalt Strike team can:
Experiment with novel research ideas, gather feedback, and iterate with a much shorter path from PoC to prod.
Demonstrate internal tooling and proof-of-concepts built on top of Cobalt Strike.
Deliver off-the-shelf tradecraft that operators can seamlessly integrate into existing Cobalt Strike workflows, reducing the need for internal R&D and customization.
Validate experimental features before integrating them into the core Cobalt Strike product.
The ambition of CS:RL is to support a broad range of use cases, including breach and attack simulation, detection engineering, and purple teaming/EDR evaluation. Additionally, for full-scope red team operations, we also see an opportunity to deliver capabilities that enable bypassing existing defensive controls. Outflank has already taken important steps in this direction with OST’s Beacon Booster functionality. Historically, however, Beacon Booster was built on undocumented interfaces. With deeper integration into Cobalt Strike, that work can become significantly more powerful.
Finally, looking further ahead, we also see an opportunity to move beyond Cobalt Strike’s current download infrastructure and take advantage of the capabilities offered by the OST platform, such as just-in-time compilation. This evolution will help us deliver even more advanced capabilities to Cobalt Strike customers. CS:RL is the first step in what we see as a much broader journey.
A major overhaul of OST’s existing Beacon Booster.
‘Lucky Strike’ 🍀: A custom loader with novel tradecraft developed by the Cobalt Strike team.
An overhaul of OST’s existing Beacon config updater.
A public profile checker which will automatically alert users to default or signatured Malleable C2 profiles.
A custom UDC2 channel that uses the Azure Service Bus to egress Beacon’s C2 traffic.
An experimental new process injection technique (‘Weaver’) to support post-exploitation activities.
We are currently releasing CS:RL in beta but this is just the beginning. We already have a roadmap for various tools and capabilities to be added in the near feature, such as additional Cobalt Strike specific tradecraft and better integration between CS:RL and the stand-alone Cobalt Strike product. Note, CS:RL is, and will remain, opt-in and will not be required to use the core Cobalt Strike product.
The demo below shows the updated Beacon Booster in action:
What Does This Mean for Regular CS Users That Don’t Have Access to CS:RL?
There will be no changes to the product roadmap. Cobalt Strike remains committed to the same product philosophy and vision as pioneered by Raphael Mudge (and outlined above). Cobalt Strike’s ultimate goal is to improve security literacy, help security practitioners understand the value of our defensive ideas, and push meaningful change; we want to make things better and feed the security conversation.
The Cobalt Strike team has grown over the past years and so CS:RL does not affect Cobalt Strike release planning.
We remain committed to the journey of being a highly customisable and modular framework, enabling security researchers to flourish, and continue to support full offline customization and usage. All CSRL features are built with the same tooling we have made publicly available (UDRL-VS, UDC2-VS etc.).
CS:RL users may receive early access to beta Cobalt Strike features. However, once validated through user feedback and experimentation, these will be migrated to the core Cobalt Strike product.
We remain committed to supporting open-source tooling and the security conversation as demonstrated by the release of Eden, ICMP-UDC2 etc.
What Does This Mean for OST Users?
CS:RL does not change the overall OST roadmap. However, the Cobalt Strike team is now actively building on the underlying platform provided by OST, and together we are shaping the future direction.
We are jointly extending and improving Beacon Booster, enabling more advanced and more powerful capabilities to be developed with less effort.
Research collaboration between the Cobalt Strike and Outflank teams has been ongoing for several years (i.e. see our joint AI research here). While each team continues to maintain its own roadmap and trajectory, that close cooperation remains unchanged.
Next Steps
Cobalt Strike Research Labs is just the first step in a broader effort to bring the combined research expertise of the Cobalt Strike and Outflank teams directly to operators. By pairing cutting-edge tradecraft with practical delivery through OST, CS:RL gives users faster access to new capabilities while laying the groundwork for even deeper integration in the future. If you already have access to the Red Team Suite or the Offensive Security Suite, we encourage you to start exploring CS:RL today. If you do not yet have access, you can request a quote or schedule a demo here.
Lastly, we will be hosting a webinar where we will provide a technical overview and demo of CS:RL in action on April 14th. You can register for this Webinar here.
Release Out: Finally, Some REST
The REST API was a major feature of the 4.12 release and forms part of a broader ongoing change in the Cobalt Strike ecosystem. Therefore, we wanted to dedicate a blog post to explain the rationale behind it, discuss the architecture, and provide hands-on examples to get our customers up and running.
In addition to this blog, we have released a blog with more extensive examples that showcase the benefits of the REST API shortly, including an MCP server for integrating Cobalt Strike with the Claude LLM.
Our Motivation
Cobalt Strike was created over 15 years ago and whilst the product has changed a lot over this time, the architecture has remained the same: a fat client and a lightweight team server. This architecture has its benefits, such as the ability to collaborate via a team server whilst customizing and tinkering within the client to suit a specific way of working. However, we are always looking for opportunities to further open up Cobalt Strike to its users, provide new capabilities for offensive security research, and better support Red Team workflows. Therefore, we set out on an engineering journey to revamp the existing architecture and create a REST API.
Our main motivation for embarking on this journey was to bring the following capabilities to our customers:
Language agnostic scripting in Cobalt Strike via REST: Users can customize the product with the tools and programming languages they’re most comfortable with.
Server-side execution of Aggressor scripts: Users can run existing Aggressor/.cna scripts server-side and can call these scripts via the REST API.
Better task tracking: Ability to relate tasks (i.e. commands) and their response, which is valuable for users working with the API and provides needed insights for LLMs.
Server-side artifact storage: A multi-person red team can use one specific artifact (e.g. a BOF, Cobalt Strike payload or .NET assembly) across the full team.
Roles or ‘command restrictions’: A junior operator or LLM can be restricted from running unauthorized functionality.
The Beta and Road Ahead
We decided to provide the Cobalt Strike REST API as a beta release. The community is an essential part of the Cobalt Strike ecosystem and this approach gives our users the chance to tinker with it and provide feedback on the overall design, as well as how it performs in real operations. In parallel, the Cobalt Strike team will continue development and add more features and functionality.
Although it is released as beta, we have a well thought-out set of API routes and the overall API has gone through the regular quality control and testing processes as other Cobalt Strike features. Therefore, we expect only minor changes to the currently exposed functionality, so anything built against this API should not require major changes in future releases.
Please note, the REST service is not yet feature complete, see section Scope and caveats of this beta at the bottom of this blog for more information.
What Has Changed
Cobalt Strike 4.12 introduced the following changes relating to the REST API:
A new REST service that exposes Cobalt Strike functionality via a REST API.
The team server now performs task-tracking and exposes the task/response relationship through the REST API and in the logs.
A central location for artifact management (available via the REST API).
The REST API provides a language agnostic interface which can be used to rapidly develop custom automation flows, integrate Cobalt Strike into the realm of LLMs, and even create custom User interfaces/clients.
The following diagram provides an overview of the REST architecture. The team server and the csrestapi run on the same server, whilst the Cobalt Strike client continues to work in the same fashion.
Fig 1: The diagram above illustrates the overall architecture. The REST service runs on the same host as the team server and the diagram above shows a user accessing the REST API from a different workstation via script.py over port 50443.
Getting Started with REST
The following sections will explain how to start the REST service and provide some simple examples. In addition, we will explain some of the background in terms of API routes and their design. For simplicity, these examples use the Swagger UI and/or Curl. More information on OpenAPI and how to generate an SDK can be found in the section OpenAPI and Development SDK.
Starting the REST Service
The REST API is not started by default. To enable the database that facilitates persistent task tracking you must provide the new --experimental-db flag when starting the team server. Once the team server is up and running, the csrestapi can connect with the specified password and start exposing the REST API on port 50443.
To validate that the REST API runs successfully, a Swagger user interface should be accessible on https://<teamserver>:50443/.
Fig 2: Screenshot of the default API lander page
It is possible to configure different aspects of the REST API (e.g. network port, https certificates, etc) with startup flags and in the ./rest-server/application.properties file. More information can be found in the user guide.
Do not expose the REST API to the Internet. We recommend using network security controls (e.g. vpn), so that the interface is only exposed to authorized users.
Authentication and a First REST Request
To interact with the API, we first need to authenticate and obtain an access token via the /api/auth/login route. This takes a username and the team server password and returns an access token which must be included in each request in the Authorization HTTP header.
In the Swagger UI you can click the ‘authorize’ button and add the access token, so you don’t need to copy/paste this in every request.
Once we have obtained an access token, it is possible to use any of the requests shown in the Swagger UI. For example, we can use /api/v1/beacons to get a listing of currently active Beacons and their associated Beacon IDs. This request is particularly important, as we will need a Beacon ID to interact with a specific Beacon in the rest of the examples in this blog post.
The recording below demonstrates the process of starting the REST service, authenticating and listing running Beacons.
Video 1: Start up the REST service, authenticate and list Beacons via Swagger.
Console Command and Structured Commands
In the REST API we offer two ways of command execution:
A consoleCommand route: This executes any input as if it was entered in the Cobalt Strike console.
A structured command route: Each command/functionality is a separate REST endpoint, similar to individual aggressor functions. The benefit of the structured command routes is that the input and output is much more clearly defined (i.e. named parameters). Secondly, the structured commands will likely serve as a building block for roles and permissions in a future release. Therefore, we recommend using these structured commands over the consoleCommand route.
The following two examples use a directory listing to demonstrate these requests:
consoleCommand The consoleCommand route takes a command as if we typed it into the Cobalt Strike command line:
As the execution of a command relies on the exact moment when the Beacon checks-in, the REST requests cannot provide an immediate response. Consequently, the API creates a task and returns a taskID. This taskID can be used to retrieve the output or status as demonstrated below.
This recording illustrates the steps required for running an ls on a beacon and getting its output.
Video 2: : Run ‘ls’ via the structured route and collect its response via the task mechanism.
It is important to highlight that whilst introducing the structured command routes we deviated from the historical Cobalt Strike command naming and created a more consistent naming convention that more clearly expresses Beacon’s actions:
/spawn/ – indicates that the command uses fork & run.
/inject/ – indicates that the command injects into a specified process.
/execute/ – indicates that the command relies on Windows API calls.
/state/ – indicates a command that modifies Beacon’s configuration.
As an example, the execute-assembly command can be accessed as /spawn/dotnetAssembly, setting a new sleep value is done via /state/sleepTime and running ls is done via /execute/ls.
To help our users in finding the right routes, a mapping of all existing Cobalt Strike commands to their REST route is provided in our documentation. Furthermore, in the Swagger UI routes are grouped by functionality, making it easier to find related commands.
Artifacts and Server-side Storage
Various Cobalt Strike commands take a binary file as input (i.e. an artifact). For example, running a .NET assembly like Rubeus. The API uses the @files operator within various REST calls to indicate that the file itself is provided within the request as a base64 encoded file. In the example below, we request the API to run Rubeus via execute-assembly (REST route spawn/dotnetAssembly).
Server-side artifact storage makes it possible for one user to place artifacts (e.g. .NET assemblies, BOFs or .cna files) on the server and via REST those artifacts can be accessed and used by all users.
The table below lists the default folders and files created by the REST API that are intended for server-side artifact storage. Users are free to structure files according to their preference, with two exceptions. First, the generated folder is intended for any payloads generated by Cobalt Strike. Second, the cna_scripts.config file is used to configure which .cna scripts are loaded by default by the REST API.
Server-side Aggressor scripts that are run by REST are restricted to Sleep/Aggressor and cannot use any Java bindings.
Path
Description
/rest-server/csrestapi
Mandatory/reserved files: the REST service binary itself and further dependencies in the rest-server folder
/rest-server/restapi/cna_scripts.config
Mandatory/reserved file: A text file with the paths to individual .cna files that are loaded globally by the REST service
/rest-server/restapi/artifacts/generated
Mandatory/reserved folder: reserved for payloads generated by the Cobalt Strike REST service
/rest-server/restapi/artifacts/assemblies
A folder intended for .NET assemblies
/rest-server/restapi/artifacts/sleepmasks
Folder intended for scripts and resources for Sleepmasks
/rest-server/restapi/artifacts/udrls
Folder intended for scripts and resources for UDRLs
Since the REST API does not currently allow for file uploads, it is expected that users will place artifacts via SSH or other file copy means.
Running a .NET Assembly as a Server-side Artifact
The API’s server-side storage makes it possible for users to reference an artifact that is already present on the server, instead of sending it in the request.
The /api/v1/artifacts route allows users to list the available server-side artifacts and retrieve their symbolic references. These can then be used as part of any request that expects a binary file. In the example below, Rubeus.exe was previously uploaded to the restapi/artifacts/assemblies/ folder.
This video demonstrates running Rubeus from server-side storage and collecting its output.
Video 3: Running a server-side.net assembly (Rubeus.exe) via REST.
Server-side Aggressor Scripts and Aliases
In addition to PE files and .NET assemblies, the server-side storage also supports Aggressor/.cna scripts. Upon startup of the REST API, any .cna filepath that is included in the cna_scripts.config file will automatically be loaded. To illustrate the value of this, we will deploy the TrustedSec Situational Awareness BOF collection server-side. The result is that all the aliases that are included in Situational Awareness become available via REST.
This involves the following deployment steps:
Place the TrustedSec situational awareness collection on disk (e.g. in restapi/scripts_folder/ or restapi/BOF/ ).
Add the filepath of SA.cna into the cna_scripts.config file so the REST server will load it upon startup.
Once the csrestapi is restarted, we can use the /help endpoint to verify that the Situational Awareness aliases are available.(e.g. the command probe or whoami from Situational Awareness should be listed in the output of /help.)
This route has optional parameters for sleepMaskCNA and a udrlCNA that can point to an @artifacts reference so that payload generation can be fully customized. In the video below this functionality is demonstrated with the AceLDR UDLR.
Video 5: Server-side payload generation using custom .cna files and retrieval of the resulting payload.
OpenAPI & Development SDK
The examples provided thus far in this blog relied on Swagger and Curl. These serve as excellent examples to illustrate the API but are not the best suited to integrate in a mature programming language. As the Cobalt Strike REST API supports OpenAPI, it is possible to generate an SDK for a large variety of programming languages. On our GitHub we provide a Jupyter notebook with instructions on how to generate an SDK and use the API from Python.
This video demonstrates installing and using the OpenAPI SDK for Python.
Video 6: Using OpenAPI to generate a Python SDK.
Scope and Caveats of This Beta
The following should be considered when using the beta release of the REST API:
The current REST API is not fully feature complete: The API supports the vast majority of Cobalt strike functionality. There are, however, some areas where the API is not (yet) complete:
The reporting functionality and specific data models, such as services, sites and targets are not included.
The resource kit/artifact kit and process inject kit are not yet exposed via REST. Thus exporting filetypes such as exe, dll, hta is currently not possible.
Controlling the SSH Beacon is not supported via REST.
There is a limited set of commands not ported over (e.g. GUI commands such as ‘history’). Please refer to the command to REST mapping for additional details.
No roles, authorizations and command restrictions yet: The functionality for roles or ‘command restrictions’ as described in our motivations is not yet provided. However, we did design our API to facilitate this in future releases.
Task tracking has imperfections: We added a fair share of task-management and state tracking in the team server. However, we also hit limits in the exact communication flows between Beacon and the team server. Further mitigating these imperfections required a larger overhaul of Beacon and its messaging. For now, it is known behavior that various tasks never get to the state COMPLETED but remain in the state OUTPUT_RECEIVED or IN-PROGRESS if there is no output. For example, altering the sleep of a beacon will remain IN-PROGRESS indefinitely.
Not all features are backported in the native client: With the REST server, we introduce the concept of ‘server-side storage’. A user can store and use artifacts (e.g. a generated payload, a BOF, .cna or .net assembly) in the REST-storage so all operators can use the same version of a specific artifact via REST. However, this functionality is not yet natively implemented in the regular Cobalt Strike client. We do have a prototype Aggressor script which enables the execution of server-side artifacts from the Cobalt Strike GUI. We will polish this up and release it soon.
Real-world experience and feedback is needed: The changes around tasking and central database storage within the team server needs real-world usage. We have done performance tests, but nothing beats the experience of our users.
Next Steps
Release our internal prototypes, including our MCP server: As part of our internal research, testing, and QA process, we have created various internal prototypes that rely on REST. For example, we have made a Model Context Protocol (MCP) that integrates the Cobalt Strike REST API in an LLM, a ‘mobile webapp’ and Aggressor scripts to call into the REST API from the regular client. We believe these examples serve as excellent showcases to prove the power of this API. In the upcoming weeks, we will polish up the internal prototypes and release them.
Further mature the REST API: As indicated earlier, in future releases we will further mature this API and we foresee it becoming a core component of the Cobalt Strike architecture.
We want your feedback: Besides this release, we have also improved our feedback process. We have added a simple feedback form on our support page under the “Support” header which can be used to submit bugs, ask questions, or provide feedback on the REST Beta as well as on other features of the product.. You can also access this form directly from your Cobalt Strike client via Help->Support.
Help us improve Cobalt Strike!
Get to Know Cobalt Strike: New Introductory Training
We’re excited to announce the launch of a brand-new Cobalt Strike training course, created in collaboration between Fortra and Zero-Point Security. This unique partnership brings together the expertise of Cobalt Strike’s team with the field-tested training experience of Zero-Point Security to deliver an unmatched learning opportunity.
Through this course users can learn how to use Cobalt Strike to carry out red team assessments and adversary simulations, making it the perfect starting point for security professionals who are new to red teaming. The course contains learning modules and guided labs where users will gain hands-on experience with the concepts and workflows needed to confidently begin using Cobalt Strike in their operations.
What You’ll Learn
This training covers key areas including:
Getting Started in Red Teaming – Adversary emulation vs. simulation and the attack lifecycle.
Privilege Escalation & Lateral Movement – UAC bypasses, impersonation, session passing, and pivoting.
Malleable C2 – Customizing traffic and understanding Beacon behavior.
Extending & Reporting – Using Aggressor functions, creating custom templates, and logging activity.
Each module is paired with hands-on labs to help learners build practical skills step by step. Get more course details in the datasheet.
Who Should Enroll
This training is ideal for:
Security professionals new to red teaming
Teams adopting Cobalt Strike for the first time
Practitioners who want a strong foundation before exploring advanced tradecraft
Even experienced Cobalt Strike users can benefit from this course by learning useful tips and tricks to help with their red team workflows.
What’s Next?
This training is intended for novice Cobalt Strike users. We are planning a more advanced training that will go in to more depth into Cobalt Strike customization (e.g. custom payload generation, User-Defined Reflective Loaders (UDRLs), customization of the various kits and advanced evasion). Stay tuned!
Interested and Want More Info?
The training is available on demand, so you can learn at your own pace anytime, anywhere.
For more information, get in touch with the offensive security sales team.
Artificial Intelligence for Post-Exploitation
Post-exploitation tasks frequently require manual analysis, such as relying on an operators’ expertise to scan a target environment for sensitive information that could support in the pursuit of an objective. For example, searching file shares and internal applications for sensitive information of credentials. These tasks are often time consuming, but can be dramatically improved with the application of AI/ML.
This blog will discuss prior work in AI tooling and explore the requirements for AI/ML in post exploitation scenarios. Additionally, it will discuss key advancements in Windows AI/ML APIs that make it easy to integrate them into Cobalt Strike’s post-exploitation workflows. Lastly, this blog will also present two proof-of-concept implementations for AI-augmented post-exploitation capabilities in Cobalt Strike. The two proof-of-concept implementations can be found here.
Prior Research
Many current post-exploitation tools used for credential search, like Trufflehog, rely on regular expressions to scan for credential patterns in files. While effective in certain contexts, regex-based detection is inherently limited to known formats. This means unconventional or unformatted plaintext may be missed, leaving gaps in coverage that AI approaches are better positioned to address.
One notable example of prior work in weaponizing AI for post-exploitation tasks is SpecterOps’ DeepPass implementation. SpecterOps trained a Bi-directional Long Short-Term Memory (BiLSTM) model to identify passwords in downloaded documents. While the capability itself is compelling, it does have a significant limitation in that all documents of interest must first be identified and exfiltrated before classification can occur. These requirements increase operational risk in cases where documents are blindly downloaded in bulk and undermine the primary advantage of AI-driven automation when documents must be pre-filtered by operators.
In contrast, SharpML by AtlanDigital takes a more self-contained approach by embedding a machine learning inference directly into a single binary designed for on-target deployment. This implementation avoids reliance on external infrastructure but introduces its own limitations. During execution, SharpML writes three components to disk: the model, rule definitions, and password samples. This reliance on file-based artifacts makes it easily identifiable and therefore reduces its stealth and viability in real-world offensive workflows.
This diagram shows where the tools mentioned in this section may run relative to the victim network.
Post-Exploitation Considerations
Previously, the context in which a post exploitation task is typically performed has imposed operational restrictions around the use of AI/ML. This was because the available models and ML primitives used during preprocessing were not available from an in-memory context. Therefore, to maximize the utility of our AI-enabled tooling, dependencies must be minimized, and the development format should be compatible with in-memory execution.
In Cobalt Strike 4.10 we introduced the postex-kit, a template that allows users to plug-in to Cobalt Strike’s existing job architecture to create long running postex jobs. Postex DLLs function by being reflectively loaded into either a sacrificial process or an explicit target process and communicate with Beacon through a named pipe. At development time, the postex-kit allows access to higher-level C++ programming practices that are normally unavailable in more primitive formats like BOFs. By making available these higher-level C++ features, the postex-kit reduces the effort required for data manipulations often needed in pre-processing steps. These attributes make the postex DLL format ideal for AI/ML post-exploitation capability development.
Advances in AI/ML Libraries
Since the release of Windows 10 version 1809 in October 2018, Microsoft has made AI/ML APIs available through the Windows ML framework. This framework is built on top of the ONNX Runtime, which is a platform agnostic library that allows for the use of models stored in the Open Neural Network Exchange (ONNX) format. The ONNX Runtime and the CPU and DirectML execution providers were initially designed for deploying machine learning models within Universal Windows Platform (UWP) applications. Although early support was limited to legacy ONNX opsets, Windows 11 version 21H2 (2104) introduced support for ONNX opset 12, significantly expanding model compatibility and functionality.
Importantly, these APIs are not limited to UWP applications; they can also be accessed from native C++ applications, enabling broader integration scenarios. This means that models trained using standard Python-based workflows can be exported to a supported ONNX format and seamlessly used in C++ code. When combined with the flexibility of the postex DLL template discussed earlier, these Windows ML APIs can be integrated into post-exploitation tooling, reflectively loaded with either the default or a user-defined postex reflective loader, and executed entirely in-memory. Through these interactions, the ability to access model inference (i.e. predictions or decisions) in a reflectively loaded context becomes available to users of Cobalt Strike.
This diagram shows how an AI-enabled postex DLL may be used from an in-memory context on a victim network.
Building a Local Credential Finder
The advances in the AI/ML ecosystem on Windows outlined in the previous section, along with the release of the postex-kit, have provided a powerful platform for the development of novel AI-augmented capabilities for offensive security professionals. By re-implementing SpecterOps’ DeepPass in a compatible format, a credential classification model can be embedded into a postex DLL and used to provide inference on candidate strings at run time. The process begins by loading the model from a byte array.
LearningModel LoadModel()
{
/* Ensure the COM apartment is initialized for this thread */
init_apartment();
/* Create an in - memory stream */
InMemoryRandomAccessStream memoryStream;
/* Create a DataWriter to write the raw bytes to the stream */
DataWriter writer(memoryStream);
writer.WriteBytes(array_view<const uint8_t>(modelBytes, modelBytes + sizeof(modelBytes)));
writer.StoreAsync().get(); // Ensure data is written to the stream
writer.FlushAsync().get();
/* Rewind the stream to the beginning */
memoryStream.Seek(0);
/* Create a stream reference from the in - memory stream */
RandomAccessStreamReference streamReference = RandomAccessStreamReference::CreateFromStream(memoryStream);
if (streamReference == nullptr) {
return nullptr;
}
/* Load the model from the stream reference */
LearningModel model = LoadModelFromStream(streamReference);
return model;
}
Performing any kind of recursive search, candidate strings can be extracted from documents on the target system, encoded using the encoding scheme used at training time, and then passed into the model for classification. In this example, this capability is largely implemented in a single function shown below.
float GetPasswordProbability(LearningModel deepPassModel, UCHAR* testString) {
/* check the test string pointer and correct length */
if (testString == NULL || strlen((char*)testString) < MIN_PASS_LENGTH || strlen((char*)testString) > MAX_PASS_LENGTH) {
return 0.0f;
}
/* Set model device to CPU for max compatability */
LearningModelDevice device = LearningModelDevice(LearningModelDeviceKind::Cpu);
/* Create Session and binding */
LearningModelSession session(deepPassModel, device);
LearningModelBinding binding(session);
/* Get encodings from test strings */
std::vector<int64_t> encodedInput = EncodeWord(std::string((char*)testString));
/* Allocate setup shape for input tensor */
std::vector<int64_t> shapeInput = { 1, (int64_t)encodedInput.size() };
/* Build input tensor from input shape and data */
TensorInt64Bit inputTensor = TensorInt64Bit::CreateFromIterable(shapeInput, encodedInput);
/* Bind required inputs to model's input features */
binding.Bind(deepPassModel.InputFeatures().GetAt(0).Name(), inputTensor);
/* Run the model on the inputs */
auto results = session.Evaluate(binding, L"\0"); // Second param is supposed to be optional per the docs, but this call will fail on Win 10 without *some* wchar* in there
/* Get the results as a vector */
auto resultsVector = results.Outputs().Lookup(deepPassModel.OutputFeatures().GetAt(0).Name()).as<TensorFloat>().GetAsVectorView();
/* deepPassModel returns only 1 output, a probability expressed as a float */
return resultsVector.GetAt(0);
}
Weaponizing Existing AI Models
Another approach that is viable with the Windows ML APIs is the use of existing models. One use case for this might be the implementation of natural language-based semantic search to identify high-value information on target systems. A requirement for implementing semantic search is access to an embedding model, such as bge-base-en-v1.5, to generate embedding vectors from input strings. An embedding vector generated in this way effectively contains a numerical representation of the input text’s context, which can then be used to calculate similarities between two strings.
Training a capable embedding model of adequate capability requires significant time and resources. Therefore, being able to access existing versions of these models is a valuable capability. Modern embedding models are complex and generally require access to ONNX opset compatibility greater than what is available via the Windows ML APIs. However, by implementing a tailored distillation and conversion process, it was possible to export the bge-base-en-v1.5 model into ONNX opset 12, which provides compatibility with Windows 11 version 21H2. An additional benefit to this distillation process is that it provides an opportunity to reduce the embedding model’s size from approximately 400 MBs to around 30 MBs.
A couple of additional considerations should be kept in mind when working with an embedding model. Unlike the tailored BiLSTM model used in the previous example, the additional complexity of embedding models necessarily means that their size will be significant. In fact, working with over 30 MBs in a byte array in Visual Studio resulted in broken features and an unusable development experience. To circumvent this and improve performance at runtime, a compression step was applied to the model. Then, Matt Ehrnschwender’s bin2coff.py script was used to make the model a linkable COFF object, accessible at link time via Visual Studio’s project settings. Resolution of both issues allowed for the implementation of the SemanticComparison function, as shown below.
extern "C" unsigned char model_onnx_smol_start[];
extern "C" unsigned char model_onnx_smol_end;
float SemanticComparison(LearningModel model, std::string string_1, std::string string_2){
/* Input batch */
std::vector<std::string> text_1 = {string_1};
std::vector<std::string> text_2 = {string_2};
/* Evaluate the model and get embeddings */
IVectorView<float> embeddings_1 = EvaluateModel(model, text_1);
IVectorView<float> embeddings_2 = EvaluateModel(model, text_2);
[ …snip…]
/* Return similarity of the embeddings */
return CalculateCosineSimilarity(embeddings_1, embeddings_2);
}
BOOL IntelligenceMain(PPOSTEX_DATA postexData){
[ …snip…]
/* Decompress model from buffer */
DecompressData(model_onnx_smol_start, model_size, &decompressed_model, &decompressed_size);
/* Load Model */
LearningModel model = LoadModelFromBuffer(decompressed_model, decompressed_size);
/* Recursive search for strings - perform SemanticComparison */
return SemanticSearchDirectoryContents(model, referenceSemanticString, threshold, filePath);
}
For more in-depth implementation details and ready-to-use binaries, review the code available in the repository.
Integrating AI Post-Exploitation
To further demonstrate the seamless integration of postex DLLs within the Cobalt Strike framework ai-postex.cna was implemented to register these capabilities as custom commands available from the Beacon console.
Considerations
The implemented examples in our repository have some important limitations that must be acknowledged. The necessary Windows ML APIs are only available on modern versions of Windows and the examples have only been tested on the latest version of Windows 11.
To reduce the size of the semantic search postex DLL, a distillation step was applied to the bge-base-en-v1.5 model resulting in reduced inference-time fidelity and accuracy. The BiLSTM model developed as a part of this research was trained on a relatively small set of 4 million ASCII passwords and words and therefore should be considered unreliable when examining strings outside of the ASCII range. During internal testing the model was observed to be biased towards capitalization, and hyphenated words, and biased against excessive symbols in candidate strings.
Both DLLs are implemented to leverage CPU computation for model inference, which means significant CPU spikes can be expected during use. These DLLs are intended to be proof-of-concept implementations and use in production environments is discouraged.
Closing Thoughts
While much of the recent attention around Artificial Intelligence has focused on its generative capabilities and offensive use in social engineering, this blog has demonstrated that AI/ML can also offer meaningful advances in the post-exploitation phase. By leveraging modern Windows ML APIs, ONNX model compatibility, and the Cobalt Strike postex-kit, it’s now possible to build fully in-memory, AI-augmented post-exploitation tooling. The proof-of-concept implementations, credentialFinder.dll, and semanticSearch.dll highlight two compelling use cases: high-confidence password classification and contextual semantic search directly on target systems. These implementations serve not only as demonstrations of technical feasibility but also introduce the potential of AI-augmented post-exploitation tools to the security conversation.
Out of Band Update: Cobalt Strike 4.11.1
Cobalt Strike 4.11.1 is now available. This is an out of band update to fix an issue regarding module stomping that was discovered in the 4.11 release that we felt should be fixed prior to the next release.
Besides that issue, this out of band release also allowed us to include two other smaller bugfixes/quality of life improvements.
Module Stomping
We fixed an issue which caused Beacon to crash in edge cases when module stomping was used in conjunction with ObfSetThreadContext injection when the target process had Control Flow Guard enabled. We’ve added a patch for this issue.
Note: If you are using a UDRL which performs module stomping, you should ensure you set `METHOD_MODULESTOMP` as part of the `ALLOCATED_MEMORY` structure in your UDRL to make Beacon is aware to avoid any CFG related issues. See the bud-loader in UDRL-vs (part of the Cobalt Strike arsenal kit) for an example on how to do this.
“Enable SSL” Checkbox
We have fixed an issue with using self-signed certificates and the teamserver not allowing HTTPS to be enabled. Once a user configures the ‘https-certificate’ and points towards a self-signed certificate, the ‘Enable SSL’ checkbox would be disabled.
In the 4.11 release blog, we announced that we switched to prepend loaders and are ending support for stomp loaders. In this hotfix we’ve added a deprecation warning in the c2lint program to make the deprecation more explicit (and with this hotfix release blog we highlight the deprecation once more).
Download and update
Licensed users can download version 4.11.1 from here. If you need to update your CS license for an existing Cobalt Strike environment that you don’t want to update, you can obtain a new authorization file using the Authorization Generation page rather than running the update command
We thank our customers for reporting these issues. If you notice any other issues with Cobalt Strike, please refer to the online support page, or report them to our support email address. To learn more about Cobalt Strike, please contact us.
Cobalt Strike 4.11: Shhhhhh, Beacon is Sleeping....
Cobalt Strike 4.11 is now available. This release introduces a novel Sleepmask, a novel process injection technique, new out-of-the-box obfuscation options for Beacon, asynchronous BOFs, and a DNS over HTTPS (DoH) Beacon. Additionally, we have overhauled Beacon’s reflective loader and there are numerous QoL updates.
Out-of-the-Box Evasion Overhaul
The focus of this release (and the next) was to overhaul Cobalt Strike’s out-of-the-box evasion options.
Firstly, we have added a novel Sleepmask which is automatically enabled via Malleable C2. In previous releases, Cobalt Strike’s “evasive sleep” has been available in the Arsenal Kit, but it was based upon a (modified) open-source technique and required a significant amount of customisation to use with Beacon. We felt that runtime masking is essential in modern operations with Cobalt Strike, which is why we wanted to update and improve it with something new and novel. The new evasive Sleepmask will obfuscate Beacon, its heap allocations, and itself, meaning that Beacon is robust against static signatures at runtime, out-of-the-box, without any further configuration required. You can of course still use the evasive sleep in the Arsenal Kit or your own Sleepmask if you desire.
Note: The new Sleepmask only applies to HTTP(S)/DNS Beacons; we are currently overhauling the pivot Beacon Sleepmask for the next release.
Secondly, we have added a new novel process injection technique, which is the default injection method used by Beacon as of 4.11. Injected threads are one of the pillars of modern detection and can be identified with high fidelity by simply looking for threads with a start address that is not backed by a Portable Executable (PE) image on disk. However, there are still many ways to bypass this approach, such as using various gadgets to redirect execution flow, meaning that EDR vendors typically have advanced logic to identify this type of behaviour.
In Cobalt Strike 4.11, we have added our own custom process injection technique, ObfSetThreadContext. In the following screenshot, we use ObfSetThreadContext to inject a Beacon into a remote process. We then scan the process with Get-InjectedThreadEx and observe that no suspicious threads have been identified:
Fig. 1 – A screenshot showing the results of Get-InjectedThreadEx scanning a process into which a 4.11 Beacon has just been injected.
By default, this new option will automatically set the injected thread start address as the (legitimate) remote image entry point, but can be additionally configured as shown below:
The option above sets ObfSetThreadContext as the default process injection technique and will ensure that all new threads are spawned at the exported ntdll function, TpReleaseCleanupGroupMembers (i.e. the entry point for thread pool threads on Win10).
Note: As shown above, the execute block allows you to specify multiple backup techniques (in this case NtQueueApcThread and SetThreadContext) in the event that your default technique fails for certain corner cases (i.e. x86 -> x64 injection, self-injection etc.). For example, ObfSetThreadContext currently only supports same arch injection, so a backup technique is recommended for cross arch injection (or alternatively use the proc-inj kit).
Thirdly, we have ported Beacon’s default reflective loader to a new prepend/sRDI style loader and added several new evasive features:
A new EAF bypass option (stage.set eaf_bypass “true”) which can be used to bypass security solutions which use Export Address Filtering (EAF) techniques/ guard pages.
Support for indirect syscalls (stage.set rdll_use_syscalls “true”).
Support for automatically applying complex obfuscation routines to Beacon payloads (stage.transform-obfuscate {}).
A demo of the new EAF bypass in operation can be seen below:
We have previously blogged about creating custom obfuscation loaders for Beacon. This work was initially inspired by Hasherezade’s blog on custom PE formats and Elastic Security Lab’s blog on the Blister loader, which uses compression and encryption to add layers of obfuscation.
transform-obfuscate abstracts these ideas and enables Cobalt Strike users to automatically apply complex obfuscation routines to Beacon payloads. In this sense, it is analogous to the transforms Malleable C2 supports on Beacon’s network comms (but for the Beacon DLL instead of C2 traffic).
For example, the transform-obfuscate option below will compress a Beacon payload, rc4 encrypt it with a random 64 bit key, xor it with a random 32 bit key and then base64 encode it:
stage {
transform-obfuscate {
lznt1;
rc4 “64”; # NB The max supported rc4 key size is 128
xor “32”; # NB The max supported xor key size is 2048
base64;
}
}
These transformation rules can be applied in any order and specified more than once. For example, if you wanted to emulate Roshtyak malware you could add 14 different transforms.
Note: Extensive transforms (and in particular compression) can add slight delays to payload generation (as Cobalt Strike will need to compress a payload potentially multiple times).
Additionally, this reflective loader overhaul allowed us to make several improvements to Cobalt Strike’s existing Malleable C2 options. For example, it allowed us to decouple stage.obfuscate from controlling whether the PE header is copied into memory as part of reflectively loading Beacon (which has added complications to UDRL development; see Sleepmask Redux here). This can now be configured via the stage.copy_pe_header “false”; option.
Lastly, Beacon is now robust against static signatures out-of-the-box, at all stages of the attack chain, as in 4.11 we have enabled by default:
set sleepmask “true”
set cleanup “true”
transform-obfuscate { xor “32”; }
If you want to disable Cobalt Strike automatically xor’ing the entire Beacon payload with a random key, you can set transform-obfuscate { } in your Malleable C2 profile (NB This is only applicable when using Beacon’s default prepend loader and will not impact UDRLs as they ignore PE modifications).
Note: As of 4.11, Beacon will now use the new prepend loader by default. The legacy stomp / exported reflective loader is still being supported in 4.11 and if you still want this behaviour you can manually enable it via stage.rdll_loader “StompLoader”;. However, we recommend against using it and are ending support for stomp loaders in 4.12.
Asynchronous BOFs
We have added a new Postex DLL, async-execute.dll which can be used to asynchronously execute BOFs (i.e.in a new thread while Beacon is sleeping). This means that operators can now run multiple BOFs at the same time all within the same process without blocking Beacon. This Postex DLL operates in two modes:
Single shot: a single BOF will be executed asynchronously and the async-execute Postex DLL will immediately exit.
Background: the async-execute Postex DLL will act as a server and repeatedly execute all BOFs sent to it.
Each asynchronous BOF will run as its own job and its specific output can be viewed in its job console window in the Cobalt Strike GUI. Additionally, async-execute honours the process-inject.bof_allocator method (virtualalloc, mapviewoffile, heapalloc), supports indirect syscalls, and will automatically free itself from memory on termination.
A demo of async-execute in operation can be seen below:
Note: The majority of the Beacon C API is supported, so most BOFs will run without requiring any modification. However, there are some APIs which are not supported for obvious reasons (i.e. Beacon data store APIs). Check the async-execute-README in kits/postex/artifacts/async-execute for a complete list.
It is important to stress that async-execute was written entirely with the Postex Kit (released in 4.10). This is why you will find the compiled DLLs in the Arsenal Kit (kits/postex/artifacts/async-execute) with their corresponding async-execute.cna script. We have added it to the Postex Kit as an example to demonstrate the power and extensibility of the Postex Kit for developing custom long running jobs which plug directly into CS.
Note: To support async-execute we have added a new Aggressor function bread_pipe. This allows you to register a custom job via reading from the specified named pipe and gives greater flexibility when writing custom tooling with the Postex Kit.
Additionally, we hope to demonstrate with this example that all Cobalt Strike users have all the tools to be Cobalt Strike developers. As this release shows, we are committed to adding novel evasion into Cobalt Strike, but if you still don’t like Cobalt Strike’s default options, you will always have scope to customise the product to your liking.
For example, you can effectively add your ‘own’ Malleable C2 options for reflective loading, via using Aggressor Script and UDRL-VS (the obfuscation-loader is a great example of how to do this). If you have a great idea for a new post exploitation capability, the Postex Kit makes it possible to integrate custom tradecraft directly into Cobalt Strike (as demonstrated by async-execute!).
Furthermore, with UDRL-VS, Sleepmask-VS, BOF-VS, and the Postex Kit, you have access to the same tooling that the Cobalt Strike developers use and can integrate custom tradecraft into the Cobalt Strike ecosystem, at all stages of the attack chain, quicker than ever before.
Cobalt Strike customers can download the latest Arsenal Kit here.
Note: You can combine your own postex DLLs with a custom postex UDRL and additionally control the process injection technique used (via the proc-inj kit), giving Cobalt Strike users full control over their postex attack chain.
Stealthy Network Comms with DNS over HTTPS Beacon
Cobalt Strike 4.11 introduces a DNS over HTTPS (DoH) Beacon, which provides another stealthy network egress option for Cobalt Strike users. Assuming DNS C2 infrastructure has already been configured, using the DoH Beacon is as simple as enabling it on payload generation, as demonstrated below, and it will run out-of-the-box with all the default options.
Fig. 2 – The payload generation dialogue box for a DNS Listener, showing the new DNS Comm Mode option. This can be configured to set up a DoH Beacon which will use the default DoH settings.
By default, Beacon will use mozilla.cloudflare-dns.com,cloudflare-dns.com as its target DoH-compatible DNS server. However, you can configure Beacon’s DoH settings via Malleable C2 as demonstrated below:
dns-beacon "DOH_EXAMPLE" {
set comm_mode "dns-over-https"; # [dns | dns-over-https]
dns-over-https {
# ----------------------------------------------------------------------
# Verb:
# - GET | POST
# - Default: "POST"
# ----------------------------------------------------------------------
set doh_verb "GET";
# ----------------------------------------------------------------------
# Useragent
# - Default: Blank
# ----------------------------------------------------------------------
set doh_useragent "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)";
# ----------------------------------------------------------------------
# Proxy Server for HTTP
# ----------------------------------------------------------------------
# set doh_proxy_server "123.123.123.123:4321";
# ----------------------------------------------------------------------
# DOH Server List
# - Default: "mozilla.cloudflare-dns.com,cloudflare-dns.com"
# ----------------------------------------------------------------------
set doh_server "cloudflare-dns.com";
# ----------------------------------------------------------------------
# Accept
# - Default = application/dns-message
# ----------------------------------------------------------------------
set doh_accept "application/dns-message";
# ----------------------------------------------------------------------
# Headers
# - Default = Content-Type: application/dns-message
# ----------------------------------------------------------------------
header "Content-Type" "application/dns-message";
header "header1" "value1";
}
A demo of the new DoH Beacon in action can be seen below:
Additional Updates
This release also contains a number of QoL updates, most notably:
Added command line variables ($BEACON_PID, $BEACON_ARCH etc.) corresponding to Beacon console metadata, which can be used during command execution (i.e. inject $BEACON_PID x64 HTTP). Use the variables beacon console command to see the list of available variables and values.
Beacon’s help command has been reorganised into groups to make commands easier to find and now supports adding custom commands to new/existing help groups. To see more information on help groupings, run the beacon console help for the help command: help help.
Fig. 3 – A screenshot showing Beacon’s updated help command which has been reorganised into groups.
You can now specify the default chunking size for Beacon’s GET/POST requests to bypass data exfiltration prevention solutions:
Use client_max_post_post_size to reduce the maximum post request size.Use client_max_post_get_size to control the size of chunked data (i.e. data sent per request) when Beacon is posting with a GET verb.
Use client_max_post_get_packet to control the amount of file download data that Beacon can process during one cycle (i.e. check-in) when using HTTP posts with the GET verb.
Make_token now supports UserPrincipalName (UPN) syntax (User@DNSDomainName).
BeaconGetSyscallInformation() has had a breaking change, as it previously returned pointers to Beacon’s data section which could cause errors when using syscalls after masking. It now fills out a copy for the caller, making it much easier to use syscalls when developing custom Sleepmask/BeaconGate BOFs (more to come on this very soon!).
To aid BeaconGate development, Beacon will now resolve a more extensive set of syscalls. The full list of resolved syscall functions can be found in the SYSCALL_API struct in Beacon.h.
Added numerous GUI improvements such as:
Support for customising the max Beacon console buffer size to display more console data before truncation occurs (Preferences -> Console -> Console Buffer Size).Support for wrapping long text lines in the console on word breaks (Preferences -> Console -> Default Hzt-Scroll) to better support copying and pasting from tools like Rubeus.
There is now the option to disable auto scrolling in console windows. This can be found in the bottom right corner of the CS client:
Fig 4. A screenshot showing the new GUI option to disable auto scrolling in console windows.
To see a full list of what’s new in Cobalt Strike 4.11, please check out the release notes.
Update: Stopping Cybercriminals from Abusing Cobalt Strike
Since 2023, Microsoft’s Digital Crimes Unit (DCU), Fortra, and the Health Information Sharing and Analysis Center (Health-ISAC) have been working together to combat the use of unauthorized, legacy copies of Cobalt Strike and compromised Microsoft software, which have been weaponized by cybercriminals to deploy ransomware and other malware, causing significant harm to critical sectors like healthcare.
Microsoft, Fortra, and Health ISAC remain committed to this endeavor, leveraging legal, technical, and collaborative efforts to dismantle cybercriminal operations. This initiative underscores the importance of persistence and partnership in securing the digital ecosystem.
As we near the second anniversary, we want to highlight updates on our progress and share our planned focus for 2025.
Accelerated Takedowns: Limiting Dwell Time and Damage
Over the past two years, the number of unauthorized copies of Cobalt Strike observed in the wild has decreased by 80%, drastically reducing availability to cybercriminals. This reduction has had a tangible impact, with these tools now being abused far less often.
We have successfully seized and sinkholed over 200 malicious domains, effectively cutting off their ability to accept legitimate traffic and preventing further exploitation by threat actors.
Additionally, the average dwell time—the period between initial detection and takedown—has been reduced to less than one week in the United States and less than two weeks worldwide.
A Global Success with Operation MORPHEUS
In July of 2024, Fortra was part of Operation MORPHEUS, a three-year investigation that culminated in a coordinated global effort to takedown known IP addresses and domain names associated with criminal activity to further disable unauthorized versions of Cobalt Strike. A total of 690 IP addresses were flagged to online service providers in 27 countries. In total, 593 of these addresses were taken down.
The UK’s National Crime Agency led this investigation, with support from law enforcement in Australia, Canada, Germany, the Netherlands, Poland, and the United States. Europol coordinated international operations and collaborated with private partners, including Fortra.
Continued Takedown Efforts and Next Steps
Our campaign to combat the malicious use of unauthorized Cobalt Strike copies are ongoing and evolving. We remain committed to providing any new and relevant information to law enforcement agencies worldwide to support their investigations. Fortra is also invested in other public-private partnerships, having signed onto the Pall Mall Process, an international initiative is focused on developing regulations to combat the unauthorized distribution and usage of commercial cyber intrusion tools.
Additionally, we are continuing to send takedown notices to hosting providers, raising awareness of the illicit use of unauthorized copies. We actively track these activities to the point of origin, identifying root causes to prevent reoccurrence. We concurrently issue notices on a persistent basis until these illegal versions are removed from web properties. Compliant web properties are also passively monitored in case of reappearance.
These efforts are gaining momentum and have entered a new phase of heightened efficacy. Automation processes have been put into place to further increase efficiency and simplify the takedown process. Additionally, just as cybercriminals adapt their techniques, Fortra continuously updates Cobalt Strike’s security controls to thwart cracking attempts and protect legitimate users.
Strengthening Red Team Tool Security
The nature of the modern cybersecurity landscape makes the critical need for red team solutions undeniable. However, these tools inherently carry some risk of misuse..
By proactively sharing our disruption techniques through conference talks and webinars, we have provided the broader security community with a proven roadmap that other solution providers can follow to engage in public/private disruption partnerships when faced with similar challenges.
Collaboration is essential in advancing cybersecurity overall. This not only strengthens the collective defense against cybercriminals but also ensures that legitimate security tools can continue to be used responsibly and effectively to protect organizations worldwide.
We want to thank Microsoft DCU, Health ISAC, and every other organization we’ve joined forces with in these efforts and look forward to continuing our work together to defend the integrity of critical commercial cybersecurity tools.
Celebrating 10 Years of Cobalt Strike
Can you believe it? Cobalt Strike is 10 years old! Think back to the summer of 2012. The Olympics were taking place in London. CERN announced the discovery of a new particle. The Mars Rover, Curiosity, successfully landed on the red planet. And despite the numerous eschatological claims of the world ending by December, Raphael Mudge diligently worked to create and debut a solution unique to the cybersecurity market.
Raphael designed Cobalt Strike as a big brother to Armitage, his original project that served as a graphical cyber-attack management tool for Metasploit. Cobalt Strike quickly took off as an advanced adversary emulation tool ideal for post-exploitation exercises by Red Teams.
Flash forward to 2022 and not only is the world still turning, Cobalt Strike continues to mature, having become a favorite tool of top cybersecurity experts. The Cobalt Strike team has also grown accordingly, with more members than ever working on research activities to further add features, enhance security, and fulfill customer requests. With version 4.7 nearly ready, we’re eager to show you what we’ve been working on.
However, we’d be remiss not to take a moment to pause and thank the Cobalt Strike user community for all you’ve done to contribute over the years to help this solution evolve. But how could we best show our appreciation? A glitter unicorn card talking about “celebrating the journey”? A flash mob dance to Hall & Oates’ “You Make My Dreams Come True”? Hire a plane to write “With users like you, we’ve Cobalt Struck gold!” It turns out that that it is very difficult to express gratitude in a non-cheesy way, but we’ve tried our best with the following video:
Building Upon a Strong Foundation
In the weeks ahead, Cobalt Strike 4.6 will go live and will be a minor foundational release before we move into our new development model. This release will be less about features and is more focused on bolstering security even further. This is all in preparation for a much bigger release later, which will also serve as a celebration of Cobalt Strike’s 10th birthday. As we approach this 10-year anniversary, we’ve also taken the time to reflect on the incredible journey of this product.
Raphael Mudge created and developed Cobalt Strike for many years, entirely on his own. With the acquisition by HelpSystems more than two years ago, additional support came along to bring about some great new features, including the reconnect button, new Aggressor Script hooks, the Sleep Mask Kit, and the User Defined Reflective Loader (UDRL).
Now, with Raphael’s vision always in mind, we have a growing team focused on supporting this solution to bring more stability and flexibility. We’re also dedicating additional resources to research activities, with the goal of creating and releasing new tools into the Community Kit and the Cobalt Strike arsenal. Additionally, we are placing a great deal of emphasis on the security of the product itself in order to prevent misuse by malicious, non-licensed users.
The pricing for the Offensive Security – Advanced Bundle of Cobalt Strike and Core Impact will remain the same so you can pair any version of Core Impact—basic, pro, or enterprise—with Cobalt Strike at a reduced cost. Cobalt Strike’s interoperability with Core Impact highlights another one of the advantages of being part of a company with an ever-growing list of cybersecurity offerings. Developers of these products work together to help organizations create a cohesive security strategy that provides full coverage of their environments.
As we continue to evolve with the threat landscape and strengthen Cobalt Strike accordingly, a permanent fixture in our strategy will always be to listen to our customers. Many aspects of our updates are a direct result of customer feedback, so we encourage you to keep being vocal about the features that you most want to see.
