Playing On Hard Mode: Why We Built Our Own C2

Playing On Hard Mode. Why We Built Our Own C2

We’re hackers. Our job is to exploit security vulnerabilities and break into IT environments (always with the owners’ permission, of course). To do that, we need to be able to establish and maintain a presence in well-defended environments, whatever security controls they have in place.

Unfortunately (for hackers, at least), security tools have been getting better.

The vast majority of organisations still have fundamental security weaknesses, like poor password management or flaws in security configuration. In many cases, in order to identify them, we need to get past the initial security controls. The challenge is how do we keep emulating threats at the cutting edge against companies whose defence is also cutting edge.

Security operation centres (SOCs) are gaining more capabilities. We’ve seen endpoint detection and response (EDR) tools with heuristics and memory scanning that make it harder to compromise well-protected environments become widespread. Add in new layers of runtime defences, and there are not many places for hackers to hide.

“Off the shelf” Cobalt Strike and other offensive security C2 tools are increasingly getting detected and become less and less stealthy as a result. Threat intelligence is getting better, and defenders are mapping specific IOCs for actions that used to be signatureless.

We don’t think the standard approach many hackers take–modifying commercial C2s to evade detection–will be sustainable for much longer. Artefacts of the original software will always create signatures, and as heuristics improve, those signatures will trigger detections.

That's why we developed our own C2.

We know what it takes to avoid even the most advanced defences and wanted to turn that knowledge into a long-term solution for advanced threat emulation.

Here’s what we can share with you.


Current State of SECFORCE’s Own C2

What started as a side project has become part of our ongoing red team research efforts to beat the latest EDRs, extended detection and response (XDR) platforms, etc.

While we’re not using our custom C2 in client engagements just yet, it’s only a matter of time.

We Built a Custom C2 Tool Using Nim + C (Implant), Go (Server), and Node js React (for the UI)

Our tool has evasion capabilities to get past the latest EDR heuristic and machine learning capabilities that include:

It avoids using Windows API altogether (only syscalls).

Plus, it has various other undisclosed evasion techniques. These capabilities allow us to avoid the most advanced multi-layered defences and maintain persistence, but we don’t want to give away all of our secrets. For some hints, have a look at some of our team’s past research. These posts from Dimitri Di Cristofaro and Pieter Van Schaik might hold a few clues.

Our C2 can also load BOF and COFF files, hijack DLLs, deploy executables, enable lateral movement, do dotnet assembly and more.


Building a C2 Was Not Easy

We are a hacking company, not a development company.

Yes, we have some extremely talented coders on staff who are constantly developing custom software and exploits, but as we found out, building your own C2 is on another level. It is expensive and time-consuming.

To build a C2, you need highly skilled hackers to code a complex application on top of their regular jobs.

It would have been (much) easier and cheaper to keep modding commercial tools like Cobalt Strike—software that has teams of dedicated developers.

But in the long term, we knew we needed to keep ahead of the most advanced defences. And to be frank, most commercial tools cannot meet this goal.

Plus, we had a few major advantages. We could apply “lessons learnt” from our red team engagements to expand and improve our C2. And we can also translate our ongoing research into the latest evasion and bypassing techniques into new capabilities.


So Why Bother?

A custom C2 gives us the flexibility to always get past defences. We can create and deploy any code we need, allowing us to stay undetected for longer and deliver maximum value to our clients.

Our clients need flexibility. If a SECFORCE client needs to test a specific attack, they require an implant. If this implant relies on a known signature framework like Cobalt Strike, which will be stopped by their EDR, the attack cannot proceed, stopping it before it even begins.

We knew that if we were to continue to depend only on commercial tools, we would risk being detected not because of a specific attack but because defensive controls recognise the signature of the framework we rely on.

Mitigation strategies like obfuscation or encryption on payloads help, but, as we explained earlier in this blog post, they are less useful than in the past.

There is also one more reason why the SECFORCE team developed a custom C2 tool–it is just really, really interesting.


Stay Tuned

From bypassing server-side filters of the Dynamics 365 Rich Text to discovering new vulnerabilities in platforms like VM cloud director, the SECFORCE team has been pushing threat research since day one.

Now, hackers also want to push the boundaries of what C2 tools can do. That’s why we built our own C2 to emulate some of the most advanced threats in the world.

Stay tuned for more updates.

You may also be interested in...

Visual-Portada-Red-Team-Pitfalls
Feb. 4, 2025

How to Waste a Red Team Engagement: 5 Pitfalls to Avoid

There are plenty of good tips on what to do to make a red team engagement a success. However, to ensure a successful red team engagement, you also need to know how to avoid common pitfalls.

See more
Visual DORA vs NIS2
May 29, 2024

Don't Sleep On DORA vs NIS2

Our high level digest on two of the most important security legislative instruments in history.

See more