Author:

Profile picture of Greg Darwin
Website
https://dev-cobalt-strike-archive.pantheonsite.io
About Greg Darwin
Greg Darwin is the software development manager for Cobalt Strike, by Fortra. He is responsible for all R&D activities related to the product. He spent about a year working closely with founder Raphael Mudge after Fortra acquired Cobalt Strike and continues to prioritize the foundational principles of Cobalt Strike: stability and flexibility. Greg writes about Cobalt Strike's roadmap, new releases, and more.

Posts by Greg Darwin

Cobalt Strike 4.6: The Line In The Sand

 

Cobalt Strike 4.6 is now available. As I mentioned in the recent Roadmap Update blog post, this isn’t a regular release, as it mostly focuses on security updates. There are also a couple of useful updates for users. A major release is planned for this summer, so this release lays the groundwork for the changes that are coming at that point.

Execute-assembly 1MB Limit Increase

A number of users have been asking for this for quite some time, and the change that we made affect not only execute-assembly, but other tasks (eg. dllinject) as well. We have added three new settings to the Malleable C2 profile (tasks_max_size, tasks_proxy_max_size and tasks_dns_proxy_max_size) that can be used to control maximum size limits. Note that these settings need to be set prior to team server startup. If the size is increased at a later time, old artifacts will still use the previous size settings and tasks that are too large will be rejected.

Comprehensive information on the new settings can be found in the Cobalt Strike documentation.

Arsenal Kit

We have combined the individual kits in the Cobalt Strike arsenal into a single kit, appropriately known as the Arsenal Kit. Building this kit yields a single aggressor script that can be loaded instead of loading all of the separate kits individually. The kit is controlled by the arsenal_kit_config file which is used to configure the kits that are built with the build_arsenal_kit.sh script.

The Arsenal Kit can be downloaded by licensed users from the Cobalt Strike arsenal.

Security Updates

This is the main focus of the Cobalt Strike 4.6 release. It is a necessary step as it lays the groundwork for our future development efforts.

Product security is nothing new. There has always been anti-proliferation processing in the software and, as discussed in this blog post (published by Raphael Mudge in 2019), we do our due diligence when it comes to screening potential customers and working with law enforcement. I think it is worth pointing out that the processes described by Raphael in that blog post are still processes that are followed at Fortra (the new face of HelpSystems) today–specifically:

“From time to time, we receive informal requests for technical assistance or records from private entities. Our policy is not to perform analysis for, provide deconfliction services to, or disclose our records to private entities upon informal request.

If we have information relevant to a law enforcement investigation, we comply with valid legal process.

This stance is to avoid frivolous requests and to protect our customer’s information.

We also investigate tips. We can’t usually share information back, but we look into things brought to our attention.”

We are also proactive when it comes to searching for Cobalt Strike teamservers out in the wild. This work is carried out by our own, dedicated threat intelligence team and it helps us to improve our product controls. That team also issues takedown requests if cracked copies are found.

Over the past few releases, we have made enhancements to Cobalt Strike’s product security. We intentionally haven’t described product security changes in much detail, but we do take it very seriously. Product security has been and will continue to be a key feature on our roadmap.

The 4.5 release in December 2021 saw changes to product licensing and improvements on the watermarking in the software. Those changes made it significantly more difficult to tamper with the authorization ID and locate the ever-changing hidden watermarks, therefore making it easier for us to trace stolen copies of Cobalt Strike back to specific customers. We have yet to see any credible reports of cracked copies of the 4.5 release being used because of these changes. We have seen what are claimed to be cracked copies of 4.5 being sold, but those have all turned out to be older versions badged as 4.5. By design, if the watermarks in the 4.5 release are tampered with, it will simply no longer work.

The 4.6 release brings a change to how the teamserver is deployed. Rather than a Java .jar archive, the teamserver has been built as a native binary. The client is still shipped as a .jar archive but we also plan to change that at some point as well. You shouldn’t notice anything different about the update process itself, but it is important to note that “cobaltstrike.jar” is now just a container for the team server (“TeamServerImage”) and client (“cobaltstrike-client.jar”), both of which will automatically be extracted during the update process. One thing to bear in mind though is that due to the changes in how Cobalt Strike 4.6 is installed and how it runs, coupled with changes to the download infrastructure to facilitate those changes, any scripts that you might have to automate the update process will likely no longer work and will need to be changed.

What does this mean? For you, moving forward, there is no real change. You can still download, update and use Cobalt Strike in the same way–however, please be aware that in this instance, you will need to download 4.6 directly from the website as the version 4.5 updater is incompatible with this release and will not recognize that an update is available. For us, building the software in this way is another step forward in terms of product security.

This is a line in the sand for us. We needed to make these necessary security enhancements so that we can forge ahead with our new development strategy and deliver more of what matters to our users. Normal service will be resumed with the 4.7 release this summer. Cobalt Strike will be 10 years old then so we’re hoping to do that release justice to mark the occasion properly.

To see a full list of what’s new in Cobalt Strike 4.6, please check out the release notes. Licensed users can download version 4.6 from the website. To purchase Cobalt Strike or learn more, please contact us.

Cobalt Strike Roadmap Update

 

Historically, Raphael Mudge, the creator of Cobalt Strike, didn’t typically talk about the Cobalt Strike roadmap publicly. He preferred to play his cards close to his chest and only revealed the details about each release when it went live (and he didn’t give much warning about the release date, either). That was his way of building excitement for each release. For the most part we’ve continued that tradition, but I’d like to spend a little time being a bit more transparent about our future development plans, before dropping back into the shadows.

I spent about a year working closely with Raphael after HelpSystems acquired Strategic Cyber, amongst other things being educated on what makes Cobalt Strike so special. One of the many things that he instilled in me is that the fundamental principles of Cobalt Strike are stability and flexibility. He was excited to see a team of experienced, professional software engineers being built around the product to provide the stability and we’ve continued to add flexibility over the past few releases – for example, with the recent sleep mask kit and user defined reflective loader kit. That’s our mantra: Stability and Flexibility.

Raphael also cautioned against adding cutting edge, out of the box evasion techniques to Cobalt Strike. The obvious danger is that once they’re inevitably fingerprinted, we’d get stuck in an endless loop of fixing those issues rather than working on new features. Cobalt Strike’s defaults are easily fingerprinted and that’s by design. The idea is that you bring your own tools and techniques to Cobalt Strike and use those. That’s what makes it unique.

We spend a lot of time engaging with our user community on social media, Slack and Discord, sometimes engaging directly in those threads and sometimes via DM, email or on video calls. I love that aspect of my role. It’s great to get the opportunity to interact directly with people that are using Cobalt Strike and see first-hand what’s working and what isn’t.

We’ve had a lot of feedback recently that some users just don’t have the time to work on their own tools because they’re so busy on engagements. We created the Cobalt Strike Community Kit to act as a central repository of extensions written by our users to make it easier to find useful tools but obviously there are cases where specific tools just don’t exist and you don’t have time to write them yourselves. We don’t want to abandon our core philosophy and start adding out of the box evasion to the core product, but we are making some changes.

Firstly, we are expanding the development team to provide additional capacity. Secondly, and more importantly, we are changing our development cycle so that we can give you your cake AND let you eat it.

Up until now, we have aimed to get at least three releases out per year. We are moving to a model where we will release updates to core Cobalt Strike (Stability and Flexibility) twice per year. One release will be in the Summer, and another in the Winter. You’re confused. I can sense it. “How does reducing the number of releases help?” Well, the second part of the new release schedule is to ramp up research activities and start releasing more tools outside the regular release schedule. What does this mean? The plan is that essentially, in between those core releases (which should contain more features due to the extended development time between them), we’ll be releasing a steady stream of tools into the Community Kit and/or into the Cobalt Strike arsenal. The location of each tool pretty much depends on the type of tool being released and whether we’re releasing the source as well.

There is a caveat to this, though. There is a little short-term pain while we pivot to this new release model. There will be a small, intermediate Cobalt Strike release this Spring (late March or early April) that doesn’t really have a lot of flashy new features for you, our users, but sets the foundation for future releases. We have a much bigger release planned that should ship around July/August to mark Cobalt Strike’s 10-year anniversary.

The future is bright. HelpSystems continues to invest in Cobalt Strike and expand the team around it. We will continue to listen to our users and give you the product and features that you need.

Feature requests can be submitted to [email protected] and I’m always happy to talk to users on social media, Slack and Discord.

Cobalt Strike 4.5: Fork&Run - you're "history"

 

Cobalt Strike 4.5 is now available. This release sees new options for process injection, updates to the sleep mask and UDRL kits, evasion improvements and a command history update along with other, smaller changes.

Security Updates

Before getting into the details of the release, I just wanted to impress upon you how seriously we take product security. We dedicated a significant portion of this release to improving controls around product licensing. We are fully committed to improving the security of the product and will continue to make product security enhancements a priority in future releases.

Process Injection

Until now, Cobalt Strike’s only process injection option was the built-in fork&run technique. While this is good for stability, it limits OPSEC options. We have added two new Aggressor Script hooks (PROCESS_INJECT_SPAWN and PROCESS_INJECT_EXPLICIT) to allow you to define how the fork&run and explicit injection techniques are implemented when executing post exploitation commands. A new BOF along with an Aggressor Script function implements both of these new techniques. You will now have the option of using the built-in fork&run technique or creating your own process injection technique.

Example: The keylogger using a custom process injection technique written by @ajpc500

Command History

Since adding the reconnect button in the 4.4 release, the new number one change request relates to issues with command history. There was an outstanding issue whereby scrolling back through your command history and then running a new command would insert that command in the wrong place in the command history. Not only did we fix that, we also overhauled command history to make it much more usable.

We have added a “history” command that displays your command history. You can choose to display all commands in the command history (“history all”) or specify how many commands that you want to display (for example, “history 10”). Is that all? No! We’ve also made working with command history more Unix-like by adding support for bang (!) characters.

history command

“Max Retry” Processing

This release also sees the addition of a complementary strategy to the existing Host Rotation Strategy. The “max retry” strategy is available for HTTP, HTTPS and DNS Beacons and it allows you to tell a Beacon to exit after a specified failure count. As failure count crosses a threshold, the sleep time is adjusted to a specified value.

The strategy comes with a number of default values for exit and sleep thresholds but you will be able to add custom values with a new Aggressor hook (LISTENER_MAX_RETRY_STRATEGIES).

Max Retry Strategy

Sleep Mask Kit Updates

The Sleep Mask kit was introduced in Cobalt Strike 4.4. There are two changes to the sleep mask kit in this release. Firstly, following user feedback, we have increased available space from 289 to 769 bytes. Secondly, we have added support to the kit for masking heap memory.

User Defined Reflective Loader Kit Update

Like the Sleep Mask kit, the User Defined Reflective Loader kit was introduced in Cobalt Strike 4.4. Following user feedback, we have increased the reserved size in Beacon for a larger User Defined Reflective Loader. A new Aggressor hook (BEACON_DLL_SIZE) allows you to specify whether to reserve 5k (the current threshold) or 100k for your custom loader.

Other Changes

One final, small update to mention is that to save you a click, the x64 checkbox is now checked by default on all payload generation dialogs. Please be aware of this change so that you don’t rely on muscle memory when working with those dialogs and accidentally uncheck that checkbox!

x64 checked by default

Documentation Changes

Unrelated to this release, but still relevant, is a change to the documentation. Earlier this month we made some changes to the Cobalt Strike infrastructure. One of those changes was an overhaul of the Cobalt Strike website, and the manual is now searchable: https://www.cobaltstrike.com/support.

Please note that you may need to refresh your browser cache to see the new documentation.

The support manual is now searchable

We will be publishing follow-up blog posts that provide much more detail on most of these changes in the next few days, so please keep your eye on the blog for those updates.

To see a full list of what’s new in Cobalt Strike 4.5, please check out the release notes. Licensed users can run the version 4.4 update program to get version 4.5. If you have not yet updated to version 4.4, you will need download from the website. To purchase Cobalt Strike or ask about evaluation options, please contact us for more information.

Cobalt Strike infrastructure changes

 

We will be making some changes to the Cobalt Strike infrastructure in late November/early December. We are not anticipating any downtime but we wanted to make you aware of what is changing and when.

TLS certificate updates

The current TLS certificates for www.cobaltstrike.com and verify.cobaltstrike.com both expire on 6th December. The certificates will be updated on Monday November 29th. If you haven’t already done so, you will need to download the latest update program before that date.
The update program pins the TLS certificates for both www.cobaltstrike.com and verify.cobaltstrike.com and checks them during the update process. If the certificates do not match the ones that the update application is expecting then you will see a warning message about the server being untrusted.
The latest version of the update application (20210804) shipped with Cobalt Strike 4.4 in August and has been available for download since then. Simply download and extract the distribution package for your platform to get the latest update application.

download.cobaltstrike.com

We will be moving the download pages for Cobalt Strike away from www.cobaltstrike.com/download to download.cobaltstrike.com on Thursday December 2nd. This is a logistical change and the current www.cobaltstrike.com/download link will automatically redirect to download.cobaltstrike.com so you shouldn’t notice any difference. There is a small chance that any scripts to automate updates that you may have may run into issues due to the URI change, and if that’s the case then we apologize for the inconvenience.

Cobalt Strike 4.4: The One with the Reconnect Button

 

Cobalt Strike 4.4 is now available. This release puts more control into your hands, improves Cobalt Strike’s evasive qualities and addresses a number of smaller changes requested by our users… and yes! We’ve added a reconnect button!

User Defined Reflective DLL Loader

Cobalt Strike has a lot of flexibility in its Reflective Loading foundation but it does have limitations. We’ve seen a lot of community interest in this area, so we’ve made changes to allow you to completely bypass that and define your own Reflective Loading process instead. The default Reflective Loader will still be available to use at any time.

We’ve extended the changes that were initially made to the Reflective Loader in the 4.2 release to give you an Aggressor Script hook that allows you to specify your own Reflective Loader and completely redefine how Beacon is loaded into memory. An Aggressor Script API has been provided to facilitate this process. This is a huge change and we plan to follow up with a separate blog post to go into more detail on this feature. For now, you can find more information here. The User Defined Reflective Loader kit can be downloaded from the Cobalt Strike arsenal.

Avoid localhost Sysmon Event 22 for Beacon Metadata Resolution

When Beacon starts, it resolves metadata to send back to Cobalt Strike. Previously, Beacon stuck out like a sore thumb in mature environments since the method used to resolve this metadata triggered Sysmon event 22 (DNS Query) and had become a way to reliably fingerprint Beacon every time it runs. The 4.4 release modifies how this metadata is resolved so that this no longer happens.

User-defined sleep_mask mask/unmask Stub

The sleep_mask is Cobalt Strike’s ability to mask and unmask itself in memory. The goal of this feature is to push memory detections away from content-based signatures. Although sleep_mask can encode Beacon’s data and code (if the agent is in RWX memory), the static stub is still a target for in-memory hunting based on content.

To combat this, we have made the sleep_mask stub user-definable via a kit that can be downloaded from the Cobalt Strike arsenal. Full details on this feature and how to use it can be found here and like the Reflective Loader changes, we plan to go into full detail in a separate blog post.

Reconnect button

Hands down, the single most requested change on the Cobalt Strike backlog is the addition of a reconnect button. You asked (and asked, and asked!) and we listened – but we didn’t just give you a reconnect button. If your Cobalt Strike client detects that a teamserver has been disconnected, it will attempt to reconnect automatically. The automatic reconnect attempts will repeat until either the connection has been re-established, or you choose to stop the process.

If disconnection is user-initiated from the menu, toolbar, or switchbar server button, a reconnect button appears and this allows you to manually reconnect to the teamserver.

Feature requests

We love to hear from our users – both feedback on what’s working, and requests to change things that aren’t. In addition to the reconnect button, we’ve made a few changes in this release to specifically address items raised by you.

A lot of users wanted us to add a way to persist aliases specified when renaming teamservers on the server switchbar in the main Cobalt Strike UI, so we have changed the New Connection dialog to facilitate this. When adding a new connection, you can now specify an alias for that teamserver. The alias is what you’ll see on the switchbar in the main Cobalt Strike UI. Likewise, if you rename a teamserver on the switchbar, this will update the alias for that connection. This change will be reflected in the New Connection dialog. You have the option to switch between the alias and connection view on the New Connection dialog.

Another change requested by our users was to add a way to view the Malleable C2 profile in use by your teamserver(s) in the Cobalt Strike UI. This new option can be found in the help menu (Help -> Malleable C2 Profile).

One final feature request to mention is that we’ve updated c2lint to return a result code upon completion, which can be parsed when scripting. The return codes are: 0 if c2lint completes with no errors 1 if c2lint completes with warnings 2 if c2lint completes with errors 3 if c2lint completes with both warnings and errors The number of detected errors and warnings are also displayed if any are found.

The number of detected errors and warnings are also displayed if any are found.

Vulnerability fix (CVE-2021-36798)

A denial of service (DoS) vulnerability (CVE-2021-36798) was found in Cobalt Strike. The vulnerability was fixed in the scope of the 4.4 release. More information can be found here.

Other enhancements

The failover host rotation strategy that was added in the 4.3 release has been improved to parse the content of the response as well as the return code before deciding whether failover needs to be actioned. This change makes the strategy much more reliable.

One final change to mention is the addition of an allow_useragents option to the http-config block in the Malleable C2 profile, to complement the block_useragents option that was added in the 4.3 release. This new option allows you to have better control over which user agents to respond to. Note that the settings are exclusive. You cannot specify values for both allow_useragents and block_useragents in the same Malleable C2 profile.

To see a full list of what’s new in Cobalt Strike 4.4, please check out the release notes. Licensed users can run the update program to get the latest version. To purchase Cobalt Strike or ask about evaluation options, please contact us for more information.

SSL certificate verification failure

 

UPDATE: This has now been fixed. I’ve amended this post to reflect that.

If you ran the Cobalt Strike update program today, you may have seen an error message about the failed SSL certificate verification for www.cobaltstrike.com:

The update program pins the certificate for this server. When the certificate does not match what the update expects, the update program gives a warning. This is by design and is so that you can be confident that you’re getting the update from HelpSystems.

The change that caused the error has been reverted and the issue has been addressed. No further action is required on your part, and updates should now be working again.

We’d like to offer our sincere apologies for any inconvenience that this issue caused, and thank you for your patience while the issue was resolved.

Cobalt Strike 4.3 - Command and CONTROL

 

Cobalt Strike 4.3 is now available. The bulk of the release involves updates to DNS processing but there are some other, smaller changes in there too.

DNS updates

We have added options to Malleable C2 to allow DNS traffic to be masked. A new dns-beacon block allows you to specify options to override the DNS subhost prefix used for different types of request. All existing options relating to DNS have also been moved inside this block. The affected options are: dns_idle, dns_max_txt, dns_sleep, dns_ttl, maxdns, dns_stager_prepend and dns_stager_subhost.

Something that you should be aware of is that the addition of the dns-beacon block means that in order for them to be processed, these existing options need to be defined inside the block. Values for these options outside of the dns-beacon block in existing profiles will be ignored.

dns-beacon {
# Options moved into 'dns-beacon' group in 4.3:
set dns_idle             "1.2.3.4";
set dns_max_txt          "199";
set dns_sleep            "1";
set dns_ttl              "5";
set maxdns               "200";
set dns_stager_prepend   "doc-stg-prepend";
set dns_stager_subhost   "doc-stg-sh.";

# DNS subhost override options added in 4.3:
set beacon               "doc.bc.";
set get_A                "doc.1a.";
set get_AAAA             "doc.4a.";
set get_TXT              "doc.tx.";
set put_metadata         "doc.md.";
set put_output           "doc.po.";
set ns_response          "zero";
}

Another change related to DNS is the addition of functionality to allow a DNS Beacon to egress using a specific DNS resolver, rather than the default DNS resolver for the target server. A new DNS Resolver field has been added to the DNS listener configuration dialog to facilitate this change.

Rounding out the DNS changes, a smaller change is the addition of a customization option related to how the server responds to NS record requests. We have noticed that some DNS resolvers do not allow the DNS Beacon to successfully egress to their team server due to unexpected NS record requests being injected into the communications. Prior to this release, the team server would drop the NS requests and if certain DNS resolvers fail to receive responses to those requests, DNS communications would fail. To get around this issue, we have added another option (ns_response) to the new dns-beacon block to allow the response to those requests to be customized.

Host rotation

We have made improvements to evasion in the DNS and HTTP/S Beacons by adding a host rotation strategy option. Prior to this release, a close examination of DNS and HTTP/S traffic would reveal a round robin pattern of host processing. A new host rotation strategy option in the listener configurations for the DNS and HTTP/S Beacons allows you to use different strategies for rotating through hosts. The options include the existing round robin rotation plus three new options – random, rotate on failure, and rotate after a set period of time.

Quality-of-life updates

Outside of the main DNS theme to the release, we have made a couple of a smaller, quality-of-life changes; the first of which is the addition of a PowerShell IEX option in Scripted Web Delivery. The new powershell IEX option outputs a shorter IEX command that can be pasted directly into a PowerShell console.

Another quality-of-life change is the option to prefix console messages with a timestamp. This option can be turned on or off via the console preferences dialog.

User agent handling

One final update to mention involves how requests from certain user agents are handled. The default behaviour of the team server prior to this release has been to block requests from user agents starting with “curl”, “lynx” or “wget” with a 404 response. We have received feedback that this causes problems for some users that want their server to be able to respond to requests from traffic that appears to be coming from certain user agents. To address this, we have added a block_useragents option to the http-config block within the Malleable C2 profile. This allows you to specify which user agents to respond to.

To see a full list of what’s new in Cobalt Strike 4.3, please check out the release notes. Licensed users can run the update program to get the latest version. To purchase Cobalt Strike or ask about evaluation options, please contact us for more information.