Why Your C2 Beacon is Already Dead - Malleable Profiles with AdaptixC2
In the modern landscape of information security, default settings are not enough to evade detections. Let's dive in and explore how we can further harden our C2 implants.
Introduction
The era of spinning up a default C2 server and then expecting a callback is over; we have advanced in the modern threat landscape with tools such as XDRs, NGFWs, behavioral analytics and Ai that has fundamentally changed how we detect modern threats. The problem isn't the frameworks but rather the fingerprint, by default each tool will have a default set of indicators that will indicate suspicious activity right away. In this article we will cover how to craft a believable malleable HTTP profile with AdaptixC2 a free open-source modern command-and-control framework, utilize TLS for encryption to not have unencrypted traffic, and what the defender's perspective looks like with Wireshark.
Why Default C2 Settings Gets Caught
Before going over adjusting default malleable profiles, we will go over some of the basics of the framework to understand how to utilize it. Within AdaptixC2 just like any other framework, we are able to generate a 'Listener' which will look for a connection from our 'Implant' (a.k.a beacon) that will allow us to establish a connection to the host and send commands to remotely. We can notice already some default IOCs such as /api/v1/status, /updates/check.php, /content.html and X-Beacon-Id. These are all default settings that will get us caught immediately if a defender is looking for these out of the box settings as it will be a high indicator of C2 activity.
Figure 1: Default listener config
Additionally, beyond the URI headers we can see how this traffic will look like completely unencrypted with no attempt to blend into normal network traffic. A defender with any slight network telemetry will immediate pick up on these plaintext requests being made to these endpoints and heavily scrutinize this traffic.
Figure 2: Wireshark plaintext default traffic
Not only are these immediate IOC's but our sleep time is also consistent and there's no randomness in between which is usually typical of a large enterprise environment; our implant 'beaconing' back to our C2 server every 4 seconds which is an immediate giveaway to heuristics based analysis. This is another default setting we want to change when generating our agents.
Figure 3: Fixed beacon intervals
In summary, this is not attempting to try and blend in with typical network traffic whatsoever and is a sure-fire way to immediately get caught to heuristics, alongside the fact that we have default HTTP profiles with no encryption whatsoever.
How to Harden our C2 Profiles and Agents
Now that we've established what a weak profile looks like, we can finally go ahead and make our profile more evasive. The goal is not to entirely create something undetectable, rather, it is to make it more difficult for defenders to analyze our traffic and have blend in within an environment much more smoothly that would make it more likely to ignore during analysis.
Figure 4: Custom Listener config
Notice how in our screenshot, we provide values that are not default to AdaptixC2.
Callback addresses: https[:]www[.]cdn-metrics[.]online
Method: POST or GET
URIs: /cdn-cgi/trace,static/js/metrics.min.js,/api/v1/collect,/assets/telemtry.js.
User-Agents: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36
Heartbeat Header: X-Request-ID
Use SSL (HTTPS): Enabled
Each of the decisions have a specific purpose. The URIs will mimic the CDN telemetry and static asset paths which look indicative of regular API calls being made. The User-Agent will match a common Chrome browser string rather than the framework. Then the X-Request-ID is a substitute for the dead giveaway of X-Beacon-Id.
We can then move on to the HTTP Headers configuration and change those as well.
Figure 5: Custom HTTP Headers
Now we are going to harden our Request Headers are with the following changes:
Accept: */*
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Pragma: no-cache
Referer: https://cdn-metrics.online/
Server Headers:
Content-Type: application/javascript
Server: nginx/1.24.0
Furthermore, the Page error response is configured to return an nginx 1.24.0 error page, this matches the redirector infrastructure so that direct probing of the listener is returned a convincing error rather than an obvious C2 response back.
Figure 6: Custom Page Error
Lastly, we can go ahead and finally generate our hardened beacon also adding some basic protections to it: such as Sleep timer, a random jitter, the working time being set from 9 to 5, and finally IAT Hiding to mask functions being utilized. While this doesn't guarantee our payload won't get caught, it's definitely better than the default settings provided by AdaptixC2.
Figure 7: Hardened agent generation
Finally, an example of how the traffic would look like once we enable the SSL option, all our traffic will be encrypted which is non-negotiable in the modern landscape. Something of note is that in a real engagement, ideally this should be replaced with a Let's Encrypt certificate to remove the self-signed CA as a potential IOC.
Figure 8: Wireshark encrypted TLS traffic
Conclusion
The gap between a default C2 deployment and a believable one is not only a matter of sophisticated exploit development, but also deliberate configuration. Default URIs, headers, User-Agent strings, and fixed beacon intervals are an easy catch for any defender with a well-tuned detection stack. Replacing these patterns which mirror legitimate CDNs, analytics, or even just regular browser traffic can force defenders away from signature-based detections and towards more heuristic based analysis.
With the utilization of TLS on top of a well-crafted profile to remove any plaintext inspection and also replacing the self-signed certificate, we further harden our implant to remove reliable static fingerprints.
Consequently, at VSAT security we believe that understanding the offensive toolchain at this level of depth is what will separate a meaningful red team engagement from one that gets caught the moment our implant gets executed. The techniques here are not novel by any means, they are well-documented practices and expected of operators that want to deliver real value to clients. Thank you for taking the time to read this post and until next time where we will be covering advanced infrastructure such as redirectors, actual CDNs such as Azure to mask our traffic, proxies to filter out any unintended traffic, and other methods of executing an implant to evade defenses. Until next time!
