AdaptixC2: A Modular C2 Framework with a Golang Server and Qt Client

What AdaptixC2 Is For

AdaptixC2 describes itself as an extensible post-exploitation and adversarial emulation framework, and the README repeats the legal warning that it is for authorized security testing and red team operations only. The intended user is a red team operator or a lab engineer who needs more than a fixed set of beacon commands. The feature list reads like a checklist of what a team needs once several operators share one engagement: a server and client split for multiplayer support, a credentials manager, a targets manager, a task and jobs store, remote terminal and shell access, file and process browsers, local and reverse port forwarding, and Socks4, Socks5 and Socks5 Auth support.

The interesting part is the word extensible. Listeners and agents are plugins, which the project calls extenders. The README lists HTTP/S, DNS/DoH, SMB and TCP beacon listeners, a Beacon agent, and a TCP/mTLS Gopher listener with a matching Gopher agent, with an official Extension-Kit repository linked separately. That means the framework is a host for other people's code, not a finished product. If you want a C2 that ships one agent and one transport, the plugin layer is overhead you will pay for and never use.

Golang Server, C++ Qt Client, and the Extender Split

The architecture is stated plainly in the README: the Adaptix server is written in Golang, and the GUI client is written in C++ Qt so it runs on Linux, Windows and MacOS. That split is the reason the repository has two top-level source directories, AdaptixServer and AdaptixClient, and why the build has separate targets for each.

The extender model is what shapes the data flow. Listeners and agents are not compiled into the server. They live under AdaptixServer/extenders, and the Makefile discovers them by looking for subdirectories that contain their own Makefile. Each extender builds into its own dist directory, and the top-level build moves that output to dist/extenders/<plugin_name>. A listener therefore has to be built and placed next to the server before it can be used. That is a real operational constraint: upgrading the server and forgetting the extenders leaves you with a server that starts but has no transports.

The README also mentions an AxScript engine and BOF and Async BOF support, plus linking of agents and sessions into a graph, agent health checks, and kill-date and working-time controls. Those last two matter for engagements with a fixed window, because they let an operator bound how long an agent stays live.

Installing AdaptixC2: Docker Profiles and a First Build

The README does not walk through installation. It points at the wiki page under getting-starting/installation, and the repository carries a Dockerfile, a docker-compose.yml and a pre_install_linux_all.sh script. The compose file is organized around profiles rather than a single up command, so you choose what to build.

The client build is its own profile. The Dockerfile installs Qt 6.9.2 through aqtinstall with the qtwebsockets and qtnetworkauth modules, so that version is the one the build expects. The compose service for the client is declared as client-builder under the build-client profile, and it copies the result into AdaptixClient/client-dist.

For the server and its extenders, the repository offers a combined target. The compose service is declared as server-ext-builder under the build-server-ext profile, and its command copies adaptixserver, ssl_gen.sh, profile.yaml and 404page.html into AdaptixServer/server-dist, then copies the extenders directory alongside them. If you only want the server, the build-server profile does that alone, and build-extenders builds just the plugins. There is a runtime profile for running the server, and it uses network_mode: host, which is worth noting because host networking changes how the server sees the machine's interfaces.

If you prefer a local build, the Makefile's default target is all: clean prepare server client extenders. Note the order: clean runs first and removes the dist directory, so an incremental build through the default target throws away previous output. Use the individual targets if you want to keep what you already built. The README also asks contributors to push changes to the dev branch.

Where AdaptixC2 Gets in the Way

The heaviest cost is the toolchain. Building the client means a Qt 6.9.2 installation with the WebSockets and NetworkAuth modules, plus the XCB and font libraries the Dockerfile installs. That is a large dependency set for a client, and it is not optional if you want the GUI. The Dockerfile also pulls in mingw-w64 and g++-mingw-w64, which tells you the build expects to cross-compile Windows artifacts from Linux.

The documentation is thin in the repository itself. The README defers to the wiki for installation, and the repository carries no release notes, so there is no changelog to read before upgrading. The README does link a v1.2 changelog page, but nothing in the repository states a version compatibility policy between server, client and extenders. If you build the server from one commit and the extenders from another, nothing available says the combination is checked.

There is also a licensing boundary. The project is GPL-3.0. For internal red team use that is usually fine, but if you plan to ship an extender as part of a commercial product, the copyleft terms of GPL-3.0 are a question for your own legal review, not something this article can settle.

Finally, the legal warning is not decoration. This is a post-exploitation framework with port forwarding and Socks proxies. Running it against systems you do not own or have written authorization to test is the failure mode that ends careers.

AdaptixC2 Compared with Havoc and Mythic

The two comparisons people search for are Havoc and Mythic, and the difference is mostly in where the extension boundary sits.

Mythic is built around a containerized agent model: agents and C2 profiles are separate services that talk to the main server over a defined interface. That makes each agent independently deployable and language-agnostic, but it also means you run a container stack and learn the interface before you can add anything. AdaptixC2 takes the opposite route. Extenders are compiled artifacts discovered by the Makefile from AdaptixServer/extenders, built with the same toolchain as the server, and copied into a dist/extenders directory. You get a tighter integration and a single build system, and you give up the ability to drop in an agent written in an unrelated language without touching the build.

Havoc is closer in spirit, a C2 with a Golang teamserver and a Qt client, and the two are often mentioned in the same breath. The distinction that matters from the README is that AdaptixC2 treats listeners and agents both as extenders, ships a separate Extension-Kit repository, and includes an AxScript engine for scripting. If your team already has Havoc profiles written and working, moving to AdaptixC2 means rewriting them against a different plugin API, and nothing in the README suggests a compatibility layer.

None of this makes one tool better in the abstract. It makes them different bets on how much of the framework you want to own.

Maintenance, Upgrades and the GPL-3.0 Question

The repository is not archived, and the last push was on 2026-09-21. That is a recent commit, and the README carries a v1.2 changelog link, so development is ongoing. There are no release notes in the repository, so there is no published upgrade procedure to quote. What you can infer from the layout is that server, client and extenders version together: the compose profiles build them from the same context, and the Makefile builds all three from one tree. An upgrade that rebuilds only the server and leaves stale extenders in place is the kind of mistake the build layout invites.

On licensing, AdaptixC2 is GPL-3.0. The practical implication is that if you distribute a modified version, including a custom extender linked against the framework, the GPL-3.0 obligations attach to that distribution. Internal use inside one organization is a different situation from shipping a product. Treat this as a question for your legal team; the repository's LICENSE file is the authoritative text, and the README adds its own legal warning about authorized use only.

Editorial conclusion

AdaptixC2 fits teams that want a multiplayer C2 with plugin listeners and agents they can build themselves, and who accept a GPL-3.0 build from source. It is the wrong choice for anyone who wants a single-binary tool with no compiler, and for anyone unwilling to read the GitBook wiki before deployment. Before adopting it, confirm your client builds against Qt 6.9.2, that the extenders you need compile from AdaptixServer/extenders, and that your rules of engagement permit an agent that supports kill dates and working-time windows.

Frequently asked questions

Official sources

1. Adaptix-Framework/AdaptixC2 on GitHub
2. Issues
3. License: GPL-3.0
4. Project website
5. README