Cobalt Strike 4.7 is now available. This release sees support for SOCKS5, new options to provide flexibility around how BOFs live in memory, updates to how Beacon sleeps and a number of other changes that have been requested by our users. We’ve also given the user interface a bit of a refresh (including support for the much-requested dark mode!).
In recognition of Cobalt Strike’s 10th anniversary, I’d like to say a sincere thanks to all of our users for your continued support over the years – from the very first version created by Raphael Mudge, through the acquisition by Fortra (the new face of HelpSystems) and up to today and beyond. When I first met Raphael, he impressed upon me how unique and special Cobalt Strike’s user community is, and I’m reminded of that every day – from interactions on social media, to submissions to the Community Kit and all of the great (and to be honest, sometimes not so great!) feedback that we receive. Cobalt Strike wouldn’t be where it is today without your support and constant feedback, so thank you. Here’s to the next 10 years!
A Word About Evasion
Before getting into the details of the 4.7 release, I’d like to spend a little time talking about what isn’t in the release. We’ve had a lot of feedback over the last few months that Cobalt Strike is being aggressively fingerprinted, and this is making it difficult to bypass AV and EDR tools. This is making things particularly difficult for teams that don’t have the time to develop their own tools, and you may have been expecting changes in the 4.7 release to push back on this. However, as I mentioned in a blog post about our roadmap back in March, we aren’t going to be adding any out of the box evasive measures to the core Cobalt Strike product (and just to avoid repeating myself, please do read the blog post as it goes into depth about why that’s the case). That isn’t to say that we aren’t doing anything at all–of course we take this seriously, and of course we are focussing our efforts on making improvements. Our main product releases will continue to add flexibility, make changes to the product requested by our users, and keep things stable. Meanwhile, our growing research team will focus on adding new and updating existing evasive tools to the Arsenal Kit outside of the main release cycle, keeping things moving without affecting or making you wait for main product releases. This should work out much better for you, our users, in the long term. Rather than waiting for main product releases, you should start to see regular releases of, and updates to, the evasive tooling that you need in the Arsenal Kit.
Fortra continues to invest in both the development team and the research team. We recently released a Thread Stack Spoofing tool into the Cobalt Strike Arsenal Kit and we have a number of other tools currently in development that we are expecting to release over the next few weeks, filling in the gap between now and the 4.8 release at the end of the year. The reason for this aside is to reassure you all that we are acutely aware of the issues that you’re facing and while the 4.7 release itself doesn’t contain a raft of tools to address issues around evasion, we are taking this seriously and already working on this in the background. Thank you all for your patience as our research team finds their feet and research efforts ramp up.
Now, back to the details of the 4.7 release. That’s what you’re here for, after all.
SOCKS5 Proxy Server Support
This release sees the implementation of a popular feature request – support for SOCKS5. Rather than replacing SOCKS4a altogether, you can choose whether to use SOCKS4a or SOCKS5 when starting SOCKS. A number of changes have been made, including an update to the “Start SOCKS” dialog to enable you to choose between SOCKS4a and SOCKS5 (as well as enter required parameters if SOCKS5 is selected), an update to the Proxy Pivots table to display whether SOCKS4a or SOCKS5 is being used, updates to the commands to start and stop SOCKS in the Beacon console, and an update to the bsocks Aggressor Script command. For details on the new command line options, run help socks within a Beacon console. For general details of the changes, please refer to the documentation.
It is important to note that these changes currently only add support for DNS resolution and UDP. We have not added support for IPv6 or GSSAPI authentication in this release, because the feedback that we got from you is that those features aren’t critical. We will, of course, continue to monitor feedback and will add support for those features if and when you indicate that they are important to add. We also intend to make other changes in future releases, including decoupling SOCKS5 from Beacon which should improve both speed and reliability. That is a bigger change though, and our priority for this release was to add this initial support.
Adding Flexibility Around How BOFs Live In Memory
Beacon Object Files are a key feature for Cobalt Strike. We have added more malleability around how Beacon Object Files live in memory, which should make them more difficult to fingerprint. To facilitate this, two new Malleable C2 profile settings have been added:
bof_allocator controls how you allocate memory for your BOF. Supported settings are VirtualAlloc, MapViewOfFile and HeapAlloc.
bof_reuse_memory determines whether or not memory is released. If this setting is “true”, memory is cleared and then reused for the next BOF execution; if this setting is “false”, memory is released and the appropriate memory free function is used, based on the bof_allocator setting.
Memory permissions (RWX/RX or RW/RX) are set according to the values set in the new Malleable C2 profile settings above. The exception is HeapAlloc, which is always RWX.
Review Of BOF Usage Of VirtualAlloc RWX/RX Memory
Adding flexibility around how BOFs live in memory provided us with the means to address another item that we had on our backlog. We have added support for additional relocation types for BOFs, specifically the .xdata, .pdata, and .bss sections. This change firstly means that an issue has been resolved whereby BOFs sometimes wouldn’t run because the address offset was greater than 4GB. Secondly, the number of available dynamic functions has been increased from 32 to 64.
Changes have been made to the Sleep Mask Kit and around sleep in general.
The main change is that you are now able to override the method called when Beacon goes to sleep. From 4.4 through 4.6, Beacon would call the sleep mask function that was patched into the .text section. This had some drawbacks as you were limited on how the code could be written in the sleep_mask.c files used for writing BOFs, and there was also an issue related to size constraints. In this release, Beacon has been reworked to add support for all of the things that you can do in a BOF when it comes to sleeping. Not only do you now have the ability to use your own sleep function, but you are also now able to call dynamic functions (LIBRARY$function) and Beacon API functions (when the Beacon code isn’t masked).
There are two other benefits of this change worth highlighting:
Executable code is now no longer located within Beacon’s .text section and has instead been moved to a different memory region.
The sleep mask BOF size limit has been increased from 769 bytes to 8192 bytes.
Related to this, while the Arsenal Kit still supports the older versions of the sleep mask, this release adds support for implementing the sleep mask as a true BOF. You will need to pull the updated Arsenal Kit to be able to use this feature.
Steal Token Update
The steal_token function has been updated to enable it to steal tokens from processes that it previously couldn’t get to. A user reported that as Beacon used OpenProcessToken to request TOKEN_ALL_ACCESS, in some cases this returned an access denied error. Manually tweaking the permissions in Beacon when it called OpenProcessToken was enough for them to get steal_token to succeed.
We took this feedback on board and you are now able to customize the access mask when steal_token is invoked. A number of changes have been made to facilitate this:
A steal_token_access_mask option has been added to the Malleable C2 profile. This is optional and allows you to set a default access mask used for steal_token and bsteal_token.
Support has been added to allow you to set the access mask (and override the default value) when invoking steal_token and bsteal_token from the command line.
The Steal Token dialog has been updated to allow you to set the access mask (and override the default value). This applies when both a single process and multiple processes are selected before opening the dialog.
Note that if no default value for the access mask is provided (either via the new Malleable C2 profile option, dialog option, or command line options), steal_token will default to the current access mask of TOKEN_ALL_ACCESS.
Module Stomping Update
Based on user feedback, a small change has been made to module stomping. In some cases, although the module was loaded, the actual stomping failed because Beacon remained in virtual memory. This was because unless the exported function had an ordinal value between 1 and 15, Beacon would default to using VirtualAlloc. This limitation has now been addressed by adding optional syntax to the setting to specify the starting ordinal when searching for exported functions.
You are now able to steal the contents of the Windows clipboard on the target system via a command (clipboard) or an Aggressor Script command (bclipboard), with a caveat: this feature is only useful when the clipboard contains text (for example, credential material). This is a quick change and the intended use case is for those occasions where a target is observed using a password manager (or similar) to grab a password; you would then be able to copy that password (or other relevant material) from the clipboard for use. If there is text on the clipboard, this will be returned and displayed; if not, an error will be displayed informing you that the clipboard contents are not text based. The exception to this is that if the clipboard contents exceed 204800 bytes, an error will be returned instead.
While this is a quick change with limited scope, we will likely enhance this feature in a future release. There are a number of interesting directions that we could go with this and we’d be interested to hear your feedback.
User Interface/Default Aggressor Script Updates
This release brings a refresh to the look and feel of the client UI (although not the complete overhaul that we’re still considering for a future release), along with a number of changes to the default aggressor script that introduce some usability improvements. You may recognise some of the default Aggressor Script changes, as some of those changes were inspired by mgeeky’s “cobalt-arsenal” Aggressor Scripts (which incidentally can be found within the Cobalt Strike Community Kit). While we have also added our own changes and implemented some things in our own way, we would just like to say a huge thank you to mgeeky for permission to bring some of that functionality into Cobalt Strike itself.
We have made a number of changes in this area. Here are a few highlights:
The most eye-catching change (and one of the most requested) is the addition of dark mode. This can be toggled via a new menu option.
Sleep Time Tracking
Sleep time tracking works by recording the sleep time for each Beacon and displaying it in a new column in the Beacon table view. This information is persisted between teamserver restarts so it should always be available.
Beacon Health Tracking
Linked to the sleep time tracking is a new Beacon Health tracking feature. This feature uses the sleep time and cross references this with the last check-in time to determine whether the Beacon is active, disconnected, or dead. This information is displayed in the Beacon table view and reflected in the Beacon’s icon. This feature can be enabled or disabled via a new option on the preferences dialog.
Speaking of icons, we have updated the icons that are used on the pivot graph and in the Beacon table view to represent Beacon status and OS type.
Toolbar And Menu Updates
We have also updated the icons on the toolbar in the client and have removed toolbar buttons for some of the less popular functions. Related to this change, the main menu has been reorganised, flattening the menus and moving some of the options around into more useful and intuitive locations.
Bulk Payload Generation
Related to the menu reorganisation, we have added a new menu item to allow you to generate x86 and x64 stageless payloads for all available payload variants at once. A new Sleep function, all_payloads, has also been added to allow you to do this from the command line.
Stageless Payload Generator With Exit Option
We have added a stageless payload generator dialog that allows you to set either “thread” or “process” as the exit option.
Windows Error Code Resolution
Windows error codes are now automatically parsed and resolved, so you no longer need to memorise every single Windows error code or go and look it up when Beacon just returns the error code. The relevant error message is now displayed alongside the error code. We have also added a new Beacon console command (windows_error_code) and an Aggressor Script function (windows_error_code) that can be used to convert an error code to a message on demand.
Process List Display Updates
The output of the ps command has been enhanced to resolve parent/child relationships and display the process list as a treeview instead of the old, flat version. The Beacon process is displayed in yellow. We have plans to enhance this with more colour coding in a future release, too.
There are a number of other UI changes that have been implemented, including displaying more information in the Beacon and event status bars, displaying timestamps, making it easier to interact with Beacons, a new “import credentials” option, and much more.
To see a full list of what’s new in Cobalt Strike 4.7, please check out the release notes. Licensed users can run the update program to get the latest version, or download version 4.7 from scratch from the website. To purchase Cobalt Strike or learn more, please contact us.