I blogged about the Cobalt Strike roadmap in March last year and while the fundamental tenets of our approach to R&D remain unaltered, a lot has changed behind the scenes over the past year or so. I try to engage with our customers on various platforms and over the past few months, I’ve been asked a lot of questions about our roadmap. My hope is that this blog post will help to answer some of those questions. As we have some major changes planned for the next 12-18 months, I’d like to spend a little time providing some insights into the current state of Cobalt Strike R&D as well as offering some transparency about our plans for 2023 and beyond.
Cobalt Strike R&D Team
I mentioned in the roadmap update last year that we were planning on expanding the size of the R&D team. Over the past 12 months we have more than doubled the size of the team. We have added experienced software engineers to the core development team and built a research team that is dedicated to driving the product forward.
One of our more recent hires, William Burgess, is leading our research team. He will be playing a key role in shaping the future direction of the product, bringing his extensive experience in developing security tools to bear. A key part of his role is to provide technical guidance and help to define priorities for both research activities and main product releases. In addition to this, he will also be conducting his own research activities. He recently released a blog post on spoofing call stacks dynamically with timers and already has others in the pipeline.
Henri Nurmi is another recent hire and he brings both extensive red teaming and software engineering experience to the team. Henri was behind the token store change in the 4.8 release (which was an update on the version that he submitted to the Community Kit a while ago!). In addition to his work on the core product, Henri has also been working on several other items that we’ll eventually be releasing into the Arsenal Kit and blogging about. Jean-François Maes has been a team member for quite some time and while he is currently focussing on updating and improving our training material (as a certified SANS instructor, this is definitely in his wheelhouse) he is also continuing to perform research activities.
Several other new (and older) team members prefer to keep a lower public profile but are nonetheless helping to drive development of the core product, contribute to research, update product security and more. A recent example of this was the first post in a series revisiting the User-Defined Reflective Loader (UDRL) that accompanied a new addition to the Arsenal Kit.
It has taken a while to hire the team that we were looking for and build up some momentum on associated R&D tasks, but I feel that we’re in a really good place now. We are cognisant of the fact that we have customers with a wide range of expertise and skill levels and I feel we are now better able to cater to the needs of our customers. Things were relatively quiet while that was playing out but you can now expect to see more output on the blog, more tools in the Arsenal Kit, and more cutting-edge features in the main product releases. Fortra continues to invest in Cobalt Strike and I’m grateful for the support from our leadership team.
Collaboration
The Cobalt Strike R&D team is part of a wider team that we are actively collaborating with on multiple fronts. Fortra acquired Outflank in September last year and the two teams are working closely together, collaborating on research topics and looking at ways in which we can improve the interoperability between Cobalt Strike and Outflank’s OST. Users can benefit from the new Cobalt Strike/OST bundle and leverage tools within OST to help with their engagements.
We also work closely on research topics with the Core Security team. Some members of the Core Impact research team also work on Cobalt Strike research items and both teams look at ways to improve the interoperability between the products. We are also lucky enough to work alongside and collaborate closely with other members of the wider Core Security team such as Santiago Pecin, as well as exploit writers and other red teams and penetration testing teams across Fortra.
There is a huge array of talent right across the Offensive Security department within Fortra and we are all pulling in the same direction. It has taken a while to get this all ramped up but you will now start to see the benefits of this work – especially customers that own other offensive security products from Fortra (OST/Core Impact) in addition to Cobalt Strike.
Flexibility And Stability
The recent customer survey (thank you to everyone that responded) affirmed our belief that stability and flexibility are key features of the product and are very much something that our users value. They are the core tenets of our development philosophy and play a key role in our releases.
Cobalt Strike’s strategy around evasion has always been “evasion through flexibility” meaning that we want to provide you with tools that you can use to modify default behaviours. This approach was something that Raphael Mudge pioneered with the Artifact and Resource kits and is something that we continue to support via the Arsenal Kit. It is important for us to address the concerns of our customers and we are aware that “evasion through flexibility” only works when there is enough documentation and example code to simplify modifications to the tools that we provide. This was one of the reasons behind the UDRL-VS that we recently released into the Arsenal Kit. In addition to this, we will also continue to update the tools available in the Arsenal Kit – for example, the evasive changes made to the Sleep Mask Kit in the 4.8 release.
We are also acutely aware that Cobalt Strike’s Beacon has been widely signatured in recent years. We have a blog post coming out in the next week or two which will help address some of these concerns and we will continue to review this in future. Ultimately, I have every confidence that our research team will continue to ease the burden on our users with these efforts.
The focus on flexibility is also a key reason for the infrequent releases. As I mentioned, our users have told us that they want fewer releases to give them more time to test the product before putting it into service – due at least in part to the fact that we give them the ability to bring their own tooling to bear.
Roadmap
It’s fair to say that we have a very ambitious roadmap for the next 9-12 months. I’m not going to go into a huge amount of detail, partly because I don’t want to risk over-promising and under-delivering (I’m being pragmatic, as our priorities may change), and partly because we do still like to keep our cards close to our chest to some degree at least. I would like to offer some degree of transparency into both our roadmap and strategy though.
There are essentially three strands to our R&D activities over the coming months, all of which are underpinned by the varied research activities carried out by our research team. Main product releases are of course the focus, with the 4.9 release already being scoped out and features for subsequent releases already being planned as well. Secondly, we will be tackling some technical debt which will allow the product to gracefully evolve (i.e. it will allow us to bring in some ground-breaking changes without fundamentally changing what the product has grown to be). Thirdly, we are aiming to overhaul our update infrastructure which will allow us to make improvements to product security, as well as add some really impactful features later on down the line.
We have a lot of key updates on our backlog that we will start to address once we have completed the infrastructure migration. The migration will open up a number of different possibilities to evolve the product and offer our users some amazing new features. There is a lot more to come from us towards the end of this year and into 2024.
Main Product Releases
The 4.9 release is shaping up to be quite significant and while we’re still working on fleshing out the scope, a late Summer release is what we’re working towards at the moment. We’re also currently planning a further release towards the end of the year. This release should also start to provide greater interoperability between Cobalt Strike and Outflank’s OST, which will be an ongoing development focus.
Features requested and pain points expressed by our users all feed into our roadmap. Your feedback is paramount when considering the scope of each release.
Technical Debt
There is a need for us to address some technical debt. This will provide a platform to evolve the product while we stay true to the fundamentals of the incredible product created by Raphael Mudge. We want to do the product justice and improve upon it, not tear apart Raphael’s legacy. This is always at the forefront of any change that we make. Tackling technical debt is a necessary part of the development process for any professionally maintained product, but not something that we talk about in the release blogs.
Addressing technical debt will allow us to evolve our product security measures. The changes that we have made over the last few releases have had a very real, demonstrable impact on malicious use of the software, but we need to continue to make improvements in this area. It will also allow us to address some pain points and feature suggestions that can’t currently be addressed. An example that I know will be popular is to “do something about Sleep”. We’re limited in what we can do right now but adding support for other scripting languages is definitely something that we can consider once we have made the necessary changes under the covers.
Update Infrastructure Migration
The migration of the Cobalt Strike update infrastructure is a huge undertaking and we will be collaborating with other teams within Fortra to roll this change out. One of the main drivers for the change is that it will allow us to make several key product security changes, although it does also provide us with a platform that we can use to evolve the product and bring several significant benefits to users as well. I will follow up in a separate blog post to go into those additional benefits in more detail when we are a lot further along as the migration will be an iterative process – but there will be a number of useful features that we are looking to include right from the off.
The first change of note is that we ultimately intend to deprecate the current download site and migrate to a new platform that will pull everything that users need into one place. This should eventually include software downloads, documentation, training material, a feature suggestion portal, the ability to submit technical support tickets and more. Ultimately, we have a raft of features that we intend build into the platform, giving users unprecedented levels of flexibility. As I said, more to come on that topic further on down the line. We have a lot of work to do before we get to those really innovative items.
Another part of the migration is the deprecation of the current update process. We will be aiming to tighten up product security in a number of different ways as well as make it easier for users to provision their red teaming infrastructure. One change that we are planning to make in this area is the addition of API support to make the process of provisioning red teaming infrastructure via scripting much more straightforward and more secure.
We are also looking to make changes to how the product is licensed and how license keys feed into the update process. We’ve actually had some timely customer requests in this area (again, thanks to the customer survey) and we’ll be taking that into account.
We are carefully considering how to roll these changes out so that we don’t negatively impact users that are used to working in specific ways. These changes, along with others that we will be making to the new platform, will be positively impactful for users that choose to take advantage of them but won’t negatively impact users that can’t or don’t want to.
Community
Before wrapping up this post, I wanted to mention our user community. We continue to add flexibility to the product and our users continue to take advantage of that to mould it into something that works for them. The real power of Cobalt Strike, and something that Raphael Mudge was passionate about, is the flexibility that allows our users to customise, extend and use their own tools as well as share them with other community members. This is where our incredible user community really shines and has helped shape the product into what it is today. We do not take our users for granted and it is your feedback and feature suggestions that continue to shape the direction of the product. Thank you for your support.
One of the ways that we try to recognise the contributions of our user community is the Cobalt Strike Community Kit. There are hundreds of tools written by our user community that are scattered all over GitHub and the Community Kit was created to cultivate a number of those projects into one easy-to-reference area. There are over 100 projects listed, with more being added regularly. If you have a tool that you would like to submit, there is a submission link on the site that can be used for that.
Feature requests can be submitted to [email protected] and we are always happy to talk to users on social media, Slack and Discord.
Thank you again for your continued support.
