C2 overload
3 reasons more command-and-control servers surface every year
Every year, it seems like a dozen new command-and-control (C2) centers are released on GitHub. These open-source C2s are written in the hottest languages and offer solutions to niche problems the existing options don’t touch.
After a few years, most of these C2s go by the wayside. The code is hard to maintain over time, especially while taking open-source contributions and no paycheck. The larger a code base grows, the more surgical refactoring it requires to sustain it.
So take a step back. Why are coders continuing to pump out new C2s instead of maintaining a handful of solid technologies?
Problem #1: A new language comes out
If you’ve been around technology long enough, you’ve seen the trend: Ruby on Rails is released (2004) and the next several years everyone wants it. Golang hits the ‘net (2009) and everyone needs to write their next app in it. Rust hits the marketplace (2013) and coders start shifting to it for efficient memory management (whether they need it or not!).
Like other sectors of tech, when a new technology comes out, there’s a rush to rewrite existing C2 solutions with it.
Solution: Let your needs dictate your solution, not vice versa
Instead of jumping on the new tech bandwagon, put more time up front to understand what problems you hope to address with your application and build it with modularity. This way, you can rewrite components - not the entire system - over time as newer solutions become available. This makes an application future-proof and capable of incorporating new technology if parts prove better at solving specific problems.
Problem #2: Coders want to use a protocol that is not supported in their favorite C2
When you’re conducting a security assessment, you’ll notice they’re not one-size-fits-all. What works in one environment is unlikely to work in another. This is especially true when it comes to the protocols used for agent <-> C2 communication.
For example, TCP may be completely blocked by a firewall, so you need to hop to HTTP. Or maybe too many pings-and-pongs set off alarms and RPC will help you stay under the radar. Maybe gRPC can bypass the firewall (by leveraging HTTP) whereas regular RPC gets caught up by Snort signatures on the network.
When faced with these dilemmas, coders may opt to write their own custom C2 solution, with a niche protocol that works for their scenario. This is great - problem solved - but there is a better option.
Solution: Extend a proven C2 platform
If you are using a C2 already (chances are, you are), you should always look first to extend it. If there is an open-source arm of the solution (again, chances are, there is!) you can likely extend it to include your custom protocol.
Not only will this likely be faster and more efficient, you’ll also be helping the community and building relationships with the authors of the C2 framework.
Back to the speed factor: the reason this will be faster is there are numerous problems solved in any non-trivial C2 platform and you won’t have to resolve them in your custom solution. Problems like agent connection resiliency, end-to-end encryption, beacon management, handling TTPs, etc.
Problem #3: There is not enough community in the open-solutions today
While open-source is huge in the security space, it’s often trampled over to get to the newest, flashiest product to hit the market. Is this because boots-on-the-ground hackers lack focus or because their managers dictate which solutions are used? Not sure.
But either way, there isn’t enough focus on fostering a long-term sense of community.
Building open C2 technology is complicated. Usually small teams - or individuals - take on the challenge, oftentimes in a vacuum. And because of the value a decent C2 brings, large numbers of users descend on it. Most of them give it a good ‘ole GitHub star, some may post an issue and even fewer, a pull request.
Most of these users fall away after some time. Off to the next solution.
Solution: (Truly) engage with the community
Instead of building a solution for your user base, solutions should be trying to build it with them.
As a C2 user (i.e., red/blue teamer or InfoSec operator), you should look to engage with the community around your platform of choice. If there is no focus on community, you’re using the wrong tool: if security history tells us one thing, it’s that collaboration is required for long-term sustainability.
Some C2 solutions do engage with the community. But it’s clearly not enough. C2’s continue to be developed, instead of adapting and growing as technology dictates.
So as you look at the best command-and-control solution for your needs, consider these problem statements. Before reaching for your keyboard to create yet another C2, look around and see if there is a modular, community-driven C2 that you can extend and build off of instead of reinventing the wheel.
The more we work together in the security industry, the more actual security we can bring to our customers.