Development Archives - Cobalt Strike Research and Development

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 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 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.

A Deeper Look Into the Max Retry Strategy Option

A complementary strategy to the Host Rotation Strategy was introduced to Cobalt Strike 4.5. The max retry strategy was added to HTTP, HTTPS, and DNS beacon listeners. A max retry strategy allows a beacon to exit after a specified failure count. As the failure count increases, sleep is adjusted to a specified value. By default, sleep is adjusted at 50% of the failure count.

A max retry can be selected from a list via the create listener GUI:

max retry option set as a listener option

The list can be updated with custom values using the aggressor hook LISTENER_MAX_RETRY_STRATEGIES.

The values in aggressor allow combination of options to be set vs. selecting from the default list.

# Use a hard coded list of strategies
    $out .= "exit-18-12-5m\n";
    $out .= "exit-22-14-5m\n";
    return $out;
# Use loops to build a list of strategies
    @attempts = @(50, 100);
    @durations = @("5m", "15m");
    $increase = 25;
    foreach $attempt (@attempts)
        foreach $duration (@durations)
            $out .= "exit $+ - $+ $attempt $+ - $+ $increase $+ - $+ $duration\n";
    return $out;

Understanding the Max Retry Syntax

Max Retry Strategy Syntax

The syntax is broken into four sections separated by a dash:

2Exit beacon after this number of failures
3Number of failures to begin adjust sleep
4Sleep time to set when sleep failures are met. Note: The jitter is kept to the current setting.

Using Aggressor to Create a Listener

If you use aggressor to create listeners, you can set the max retry using the max_retry option. This can be set to your custom max retry strategy without the need to be pre-defined.

Below is an example of the listener_create_ext function used to create a listener.

# create an HTTP Beacon listener
listener_create_ext("HTTP", "windows/beacon_http/reverse_http",
      %(host => "",
      profile => "default",
      port => 80,
      beacons => ",",
      althost => "",
      bindto => 8080,
      strategy => "failover-5x",
      max_retry => "exit-10-5-5m",
      proxy => ""));

TIP: Running Cobalt Strike Teamserver as a Service

These scripts can be used as a template to set up teamserver as a service and to auto-start listeners.

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:

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.


Following the 4.4 release, you may have noticed a warning message when starting your teamserver:

The missing file is optional and its absence does not break the teamserver. It contains a number of optional parameters that can be used to customize the settings used to validate screenshot and keylog callback data, which allows you to tweak the fix for the “HotCobalt” vulnerability. You can suppress the warning by creating an empty file called TeamServer.prop and saving it in your Cobalt Strike directory.

An example TeamServer.prop file can be downloaded from the Cobalt-Strike/TeamServerProp GitHub repository here. We recommend that either an empty “TeamServer.prop” file is created, the file is created but the default settings are used, or the warning is simply ignored. If, however, you want to make changes to those settings, you’re now able to do so.

The default TeamServer.prop file contains the following:

#Cobalt Strike Team Server Properties
#Fri May 07 12:00:00 CDT 2021
# ------------------------------------------------
# Validation for screenshot messages from beacons
# ------------------------------------------------
# limits.screenshot_validated=true
# limits.screenshot_data_maxlen=4194304
# limits.screenshot_user_maxlen=1024
# limits.screenshot_title_maxlen=1024
# Stop writing screenshot data when Disk Usage reaches XX%
# Example: Off
#          "limits.screenshot_diskused_percent=0"
# Example: Stop writing screenshot data when Disk Usage reaches 95%
#          "limits.screenshot_diskused_percent=95"
# Default:
# limits.screenshot_diskused_percent=95
# ------------------------------------------------
# Validation for keystroke messages from beacons
# ------------------------------------------------
# limits.keystrokes_validated=true
# limits.keystrokes_data_maxlen=8192
# limits.keystrokes_user_maxlen=1024
# limits.keystrokes_title_maxlen=1024
# Stop writing keystroke data when Disk Usage reaches XX%
# Example: Off
#          "limits.keystrokes_diskused_percent=0"
# Example: Stop writing keystroke data when Disk Usage reaches 95%
#          "limits.keystrokes_diskused_percent=95"
# Default:
# limits.keystrokes_diskused_percent=95
  • Lines starting with “#” are comments.
  • limits.*_data_maxlen is the maximum size of screenshot/keylog data that will be processed. Callbacks exceeding this limit will be rejected.
  • limits.*_validated=false means that the three following “…_maxlen” settings are ignored
  • Setting any of the “…_maxlen” settings to zero will disable that particular setting
  • limits.*_diskused_percent sets the threshold for callback processing. Callbacks are rejected when disk usage exceeds the specified percentage
    • limits.*_diskused_percent=0 (zero) disables this setting
    • Valid values are 0-99

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.

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.

Cobalt Strike DoS Vulnerability (CVE-2021-36798)

SentinelOne discovered a denial of service (DoS) vulnerability in Cobalt Strike. The bug (aka Hotcobalt) can cause a denial of service on a teamserver by using a fake beacon sending abnormally large screenshots.

This bug has been fixed in Cobalt Strike 4.4

Consider mitigating this risk to a teamserver by hardening your C2 infrastructure.

  • Update to Cobalt Strike 4.4
  • Disable staging on versions of Cobalt Strike prior to 4.4
  • Limit access to your teamserver infrastructure to only trusted sources

Thank you, SentinelOne working with us and responsibly disclosing this bug.



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

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             "";
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         "";
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.

Cobalt Strike 4.2 – Everything but the kitchen sink

Cobalt Strike 4.2 is now available. This release overhauls our user exploitation features, adds more memory flexibility options to Beacon, adds more behavior flexibility to our post-exploitation features, and makes some nice changes to Malleable C2 too.

User Exploitation Redux

Cobalt Strike’s screenshot tool and keystroke logger are examples of user exploitation tools. These capabilities are great for risk demonstration and story telling. But, with good UX, these features are also powerful capabilities to collect information that aids moving closer to an objective in a network.

Cobalt Strike’s screenshot tool and keystroke logger now report active window, username, and desktop session with each of their results. This context helps our GUI, logs, and reports display where this information came from. It’s a subtle change, but a big enhancement:

The right-click menu in the screenshot and keystroke has updates too. You can now remove a keystroke buffer or screenshot from the interface. Highlight a row with a color. And, save the keystroke buffer or screenshot to a local file as well.

We also split screenshot into two commands: screenshot and screenwatch. The screenshot command takes a single screenshot. The screenwatch command (which can fork&run or inject into a specific process) takes screenshots continuously until it’s stopped with the jobkill command.

As believers in offense in depth, we’ve added new options to acquire screenshots and log keystrokes too. The printscreen command forces a PrintScr keypress and grabs the screenshot from the clipboard. This command was inspired by the creative and awesome Advanced Post-Exploitation Workshop given by @zerosum0x0 and @aleph__naught at 2017’s DEF CON 25. And, we’ve added a post-ex -> keylogger Malleable C2 option to change the keystroke logger between GetAsyncKeyState and SetWindowsHookEx methods.

More In-memory Flexibility

Cobalt Strike has long had an interest in in-memory detection and evasion. I love in-memory detections, because I think these tactics put real pressure on post-exploitation survival. But, it’s also important to challenge security teams that rely on these tactics, to force thinking beyond that “one easy trick” that’s working right now.

Cobalt Strike 4.2 continues to build Beacon’s in-memory flexibility.

Beacon’s Reflective Loader now has two added options for allocating memory for the Beacon payload in memory. Set stage -> allocator to HeapAlloc to use RWX heap memory for the Beacon payload. Set stage -> allocator to MapViewOfFile to stick Beacon in mapped memory. This is in addition to VirtualAlloc (the default) and 3.11’s module stomping, which is our way of putting Beacon into image memory.

We’ve also added new options for content flexibility. Beacon’s Reflective DLL follows Metasploit’s conventions to make itself self-bootstrapping. We patch the beginning of the DLL (the part with that MZ header) with instructions to call the Reflective Loader with a few arguments. A common in-memory detection trick is to scan executable memory regions for MZ and PE content that looks like a PE/COFF file. These items are easy “it has to be there” content to find a Reflective DLL. Not anymore though.

Set magic_mz_x86 to change the x86 Reflective DLL MZ header in Beacon. This updates the other parts of the loading process that depend on the value. The catch is that valid x86 instructions are required for magic_mz_x86. For example, MZ in x86 are the instructions dec ebp, pop edx. You don’t want to begin execution with unexpected state, so it’s also recommended to undo any state changes made by your instructions. This is why the default magic_mz_x86 value is MZRE. The R and E bytes decode to push edx, inc ebp. They undo the effect of the MZ instructions. The same idea applies for set magic_mz_x64 too.

We’ve also added set magic_pe which changes the PE header magic bytes (and code that depends on these bytes) to something else. You can use whatever you want here, so long as it’s two characters.

Post-ex Omikase Shimasu: Second serving

Cobalt Strike 3.14 introduced a lot of options to change behaviors, characteristics, and content in Cobalt Strike’s post-exploitation DLLs. Cobalt Strike 4.2 continues this work.

We’ve added post-ex -> pipename to Malleable C2. This is an option to specify a comma-separated list of pipenames. Cobalt Strike will choose one of these when it executes its post-exploitation jobs. #s in the pipename are replaced with a [a-f0-9] character. We’ve also added set ssh_pipename to change the named pipe used by Cobalt Strike’s SSH client. Multiple pipenames are allowed in this option too.

Some of Beacon’s post-exploitation DLLs do create threads. In a keystroke logger that uses GetAsyncKeyState, this isn’t easily avoidable. 🙂 To help these situations, we’ve introduced post-ex -> thread_hint to Malleable C2. When set, our post-ex DLLs will create a suspended thread with the specified module!function+0x[offset] address. Update the thread to run the post-exploitation capability. And, resume it. This is a way to push back on point-in-time analysis that looks for moduleless thread start addresses.

And, one of my favorite features in Cobalt Strike is the obfuscate and sleep feature. This is the ability for Beacon to mask its content [and code, if you’re RWX] in memory during long blocking periods. Obfuscate and sleep is a method to push back on point-in-time analysis that looks for known strings in memory. Now, when post-ex -> obfuscate is true, Cobalt Strike’s execute-assembly, keystroke logger, screenshot, and SSH client features will mask many of their strings while they’re running.

Malleable C2 Things…

And, we’ve made several updates to the communicate side of Malleable C2. We’ve doubled the maximum size of the global useragent field. We’ve also doubled the max size of the the http-get -> client and http-post -> client programs too. This will help those of you that had run into the previous limits in your profile writing.

This release adds the global headers_remove option. This option affects http-get and http-post client blocks. It’s a late-in-the-transaction option to remove unwanted HTTP client headers from the communication. WinINet, based on its configuration, will force some headers into the transaction. You may specify specify multiple unwanted headers (separate them with commas) in this option.

And, Cobalt Strike 4.2 introduces a data content jitter as well. Set data_jitter to a number value and Cobalt Strike will append a random content and length string (up to the data_jitter value bytes) to its http-get and http-post server output.

Check out the release notes to see a full list of what’s new in Cobalt Strike 4.2. Licensed users may run the update program to get the latest. To procure Cobalt Strike (or ask about evaluation options), please contact us for more information.