In modern cyber defense, understanding the command-and-control (C2) infrastructure used by both legitimate red teams and unauthorized threat actors is critical for proactive threat mitigation. Over the past few years, frameworks like Cobalt Strike, Havoc, and Sliver have dominated adversary operations. However, the continuous evolution of endpoint detection and response (EDR) agents has catalyzed the development of newer, less-analyzed platforms. Enter AdaptixC2, an open-source post-exploitation C2 framework that has recently gained traction. Written primarily in Go for its backend server engine and C++/Qt for its operator graphical interface, AdaptixC2 provides flexible, cross-platform capabilities. Yet, like many emerging open-source platforms, its default deployment configurations exhibit deterministic architectural artifacts. This deep dive covers its internal architecture, cryptographic constructs, implant design, and the global infrastructure landscape exposed via internet-wide passive scanning.

Architectural Deep Dive: Teamserver Infrastructure and the Extender Model

At the heart of the AdaptixC2 ecosystem lies the teamserver, compiled as a singular, highly concurrent Go binary. Upon execution, the teamserver ingests its core operational parameters from a localized configuration file designated as profile.yaml. This structured configuration governs critical environmental variables, including bound network interfaces, listener ports, specialized endpoint paths, administrative cryptographic credentials, and distinct HTTP response parameters. Internally, the server instantiates an SQLite database to maintain state across operator sessions, tracks historical implant callbacks, and logs tasking metrics.

The routing topology of AdaptixC2 is architected via the popular Gin web framework. As delineated within the platform’s core routing file, connector.go, the application builds a strict hierarchical router group structure positioned beneath a user-defined primary path, which defaults to /endpoint. The routing hierarchy branches into four primary operational vectors:

/endpoint
├── /login          -> Initial Authentication Group
├── /api_group      -> JWT-Protected Operator Controls
├── /public_group   -> Unauthenticated Asset Exchange
└── NoRoute Handler -> Fallback Catch-All Error Route

The extensibility of AdaptixC2 relies heavily on its dynamic plugin system, referred to as “extenders.” Listeners targeting diverse transport mechanisms—such as HTTP/S, DNS/DoH, SMB named pipes, and raw TCP sockets—are compiled as standalone Go shared libraries (.so files) and dynamically loaded by the main teamserver execution thread at runtime. When an extender is initialized, it registers corresponding network listeners. Crucially, the standard HTTP beacon listener (BeaconHTTP) diverges from standard teamserver routing; rather than exposing callback URIs through the primary Gin engine, it generates an isolated, independent HTTP instance listening on a distinct operator-specified callback port. This design choice splits the internet-facing infrastructure into two easily identifiable listening surfaces: administrative teamservers typically bound to port 4321, and agent-callback listeners hosted across separate high-numbered ports such as 43211.

Cryptographic Operations and the Two-Tier Authentication Pipeline

Securing the control plane against rogue access is vital for an offensive platform, and AdaptixC2 implements a definitive two-tier cryptographic authentication model. Initial interaction occurs via an explicit POST request targeting the /login route, passing a standardized JSON payload populated with an operator’s username and password. If validated against the database, the server generates a duo of JSON Web Tokens (JWT): a short-lived access token boasting a 12-hour expiration window, and an extended refresh token valid for 168 hours (7 days).

[Operator Login Request] 
          │
          ▼
   [Teamserver Validation] ──(Generates Fresh Keys via crypto/rand)
          │
          ├──► Access Token (JWT - 12 Hours - HS256)
          └──► Refresh Token (JWT - 168 Hours - HS256)

To prevent key re-use or external key extraction attacks, the teamserver does not rely on static signing keys. Instead, every distinct startup event leverages Go’s native crypto/rand package to generate transient cryptographic keys in memory, using the HMAC-SHA256 (HS256) algorithm to sign every subsequent token. For advanced control plane operations, such as establishing WebSocket upgrades for real-time collaboration or conducting administrative file transfers, the framework demands an additional single-use token tier. The authenticated operator must hit the /otp/generate route using a valid JWT to obtain a unique 64-character hexadecimal One-Time Password (OTP). These OTPs are highly transient and enforce a strict single-use constraint; if a specific token is reused across duplicate requests, the underlying validation logic explicitly drops the connection.

Implant Deep Dive: Deconstructing Beacon and Gopher Agent Families

AdaptixC2 relies on two primary agent families designed to handle tasking, execution, and data exfiltration from within compromised endpoints:

1. The Beacon Agent

The premium agent, written in native C++, focuses heavily on execution efficiency and stealth. Its standout capability is native support for Beacon Object Files (BOFs). This allows operators to load and execute compiled, unlinked C code directly within the memory space of the host process without spinning up child processes or writing malicious artifacts to disk—a tactic explicitly designed to bypass legacy EDR process creation heuristics.

[C++ Beacon Agent Memory Space]
 └── [In-Process Execution Engine] ──► Loads and runs compiled, unlinked C code (BOFs)

The framework packages diverse transport sub-systems within this agent:

• BeaconHTTP: Implements standard HTTP/S beaconing alongside user-agent rotation matrices and customizable request/response metadata headers. Communications over this medium are obfuscated using a static RC4 key: 1baccab4cbd2b84f6bc54bf8e6551f93.
• BeaconDNS: Leverages the domain name system as a covert channel. The listener logic asserts an Authoritative Answer (AA=true) bit flag on every response packet, replying with a flat TXT "OK" string whenever it processes standard queries or short hostnames that do not conform to its strict multi-labeled check-in protocol format.
• BeaconTCP & BeaconSMB: Internal pivot mechanisms. While BeaconTCP exposes a bind-style raw socket on the local host, BeaconSMB communicates via Windows named pipes. Remarkably, the teamserver-side initialization for the SMB extender operates as a complete no-op; it opens no external sockets, routing all traffic purely through preexisting peer-to-peer infected relays inside the victim’s internal network perimeter.

2. The Gopher Agent

Complementing the C++ component is the Gopher agent, written in Go. It compiles into a completely static, independent binary with no external shared-object or runtime library dependencies, making it an excellent payload for diverse Linux distributions. Gopher supports asynchronous BOF execution, utilizing Go’s native goroutines to spawn tasking tracks in the background, allowing the core agent loop to continue polling the teamserver for commands without blocking execution. Both the Beacon and Gopher variants carry default embedded watermarks—unique hexadecimal strings compiled into the binary payload (be4c0149 for Beacon and 904e5493 for Gopher)—which can serve as strong signature material for host-based memory forensics.

Passive Fingerprinting at Scale: The Mechanics of Default Configurations

Despite its advanced post-exploitation capabilities, AdaptixC2 remains heavily exposed on the open internet due to systemic implementation details within its error-handling mechanisms. By default, the HttpServer.error configuration node within profile.yaml dictates the precise structural composition of the fallback 404 response returned whenever a scanner probes an unregistered route or hits an unmatched path.

YAML

HttpServer:
  error:
    status: 404
    headers:
      Content-Type: "text/html; charset=UTF-8"
      Server: "AdaptixC2"
      Adaptix-Version: "v1.2"
    page: "404page.html"

Because this configuration binds directly to Gin’s NoRoute handler, any passive internet scanner probing the top-level directory (/), standard crawlers checking /robots.txt, or arbitrary asset paths will receive this response. This completely circumvents the secrecy of the actual /endpoint path, enabling effortless framework identification without authentication or brute-forcing.

Furthermore, defensive threat hunting platforms like Censys exploit a secondary defensive gap: the underlying HTML page body. The default 404page.html hardcodes a distinct signature:

HTML

<h1>AdaptixC2 404</h1>
<p>You need to enter the correct connection details.</p>

Even if an operator attempts to evade standard network detection rules by modifying the Server header to a generic value (such as Apache or Nginx), the default body structure frequently remains unaltered. Internet-wide scanners can match these two orthogonal data points to track down modified instances. This includes capturing evasion attempts such as the known “TestCoonection” header modification variant.

Additionally, for hosts that drop HTTP surfaces entirely and run pure DNS callback loops, threat hunters pivot to look for the dns.version: "OK" signature paired with anomalous TTL values jittering between 10 and 70 seconds.

Global Infrastructure Insights and Real-World Threat Landscape

As of June 16, 2026, real-time threat intelligence tracking from Censys shows significant adoption of the platform, identifying 412 unique web properties spread across 236 discrete hosts running AdaptixC2 under default or near-default configurations. Analysis of the global port distribution confirms that many operators omit standard configuration hardening steps:

Port Number	Active Property Count	Classification / Operational Context
4321	46 Properties	Default administrative Teamserver port
43211	15 Properties	Default HTTP Beacon listener callback port
8080 / 8443 / 8989	~3 Properties each	Custom non-standard Teamserver ports
Various (1337, 9999, 8562)	50+ Properties	Randomized high-ports or obfuscated layouts

Geographically, the active infrastructure is highly concentrated, with the United States hosting 38 discrete nodes and Hong Kong hosting 18. Multi-node clustering highlights coordinated deployments by single operators. For instance, across hosting providers like Hivelocity (HVC-AS), M247, and PSB Hosting, clusters of adjacent or sequential IP addresses have been observed exposing matching listener ports while serving identical default OpenSSL certificates. This pattern indicates single actors setting up highly redundant, multi-server callback topologies.

[Coordinated Cluster Deployment]
 ├── IP: 46.21.153.146  ──► Port 43211 (HVC-AS) ──┐
 ├── IP: 46.21.153.148  ──► Port 43211 (HVC-AS) ──┼──► (Shared Default OpenSSL Cert)
 └── IP: 23.227.203.205 ──► Port 43211 (HVC-AS) ──┘

A closer look at specific hosts reveals distinct setup variants and operational configurations:

• 185.190.142[.]66 (Contabo, France): Operates an active teamserver on port 4321 while simultaneously exposing Remote Desktop Protocol (RDP) on port 3389 and presenting a TLS certificate under the organizational name O=OpenClaw on port 443.
• 89.125.255[.]29 (RoyaleHosting, Netherlands): Presents a self-signed TLS certificate with geographic identifiers set to C=RU, ST=as, O=as.
• 38.147.173[.]24 (Lucidacloud, Hong Kong): Hosts a teamserver on port 8562 alongside an open listener on port 50050.
• 202.95.8[.]92, .97, and .98 (CTG Server, Hong Kong): Represents three strictly sequential IP addresses, all running default teamserver ports.
• 167.17.47[.]121 (Trunk Networks, Singapore) & 91.230.94[.]235 (Netrack, Russia): Both show dual-purpose configurations, exposing the Go teamserver interface alongside an active DNS beacon listener responding with dns.version: "OK".

Case Study: Live Artifact Exposure at 2.26.229[.]254

The most critical exposure was identified on an active host (2.26.229[.]254) that misconfigured its directory permissions, exposing a collection of weaponized payloads in an open directory:

Open Directory (2.26.229[.]254)
 ├── install.sh           -> Linux persistence installer (12 mechanisms, Russian comments)
 ├── timesync.bin         -> Gopher agent (ELF x64, SHA256: fb1f4f5a...)
 ├── svhost.exe           -> C++ Windows x64 Beacon (SHA256: 06b13dfd...)
 ├── svc_timesync.x64.exe -> C++ Windows x64 Beacon (SHA256: 7d35d687...)
 └── agent.x86.exe        -> C++ Windows x86 Beacon (SHA256: 51fba778...)

Deep-dive analysis of the retrieved install.sh script revealed 12 distinct persistence mechanisms targeting Linux endpoints, along with extensive Russian-language code comments. Crucially, the installation file contained a hardcoded operator SSH public key:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIoi/bPuWr2EOQZo2OVDqG8XsRMz5epEGqG9sjcwZGJ1 timesync-manager

The presence of this explicit public key in the authorized_keys file of any victim asset provides a clear, high-fidelity indicator of compromise (IoC) that directly links the host to this specific operator’s infrastructure. In Censys, all of these tracked assets are cataloged under the threat classification label THREAT-0210 (Adaptix C2), giving security teams the necessary tools to implement proactive edge-blocking rules and enhance threat hunting operations.

Our Opinion on This Case

The operational data surrounding AdaptixC2 highlights a common trend in modern offensive security tools: the tension between advanced payload functionality and basic operational security (OPSEC) failures in the infrastructure plane. While AdaptixC2 features sophisticated endpoint capabilities—such as cross-platform async Beacon Object File (BOF) execution and peer-to-peer SMB named-pipe relaying—these are undermined by simple, predictable network signatures in its default configuration.

Leaving identifiable headers like Server: AdaptixC2 in the global error handler is an elementary operational oversight. It allows defensive telemetry platforms to map out the framework’s global footprint before an operator even launches an engagement. Furthermore, the multi-node clusters discovered in sequential subnets with default OpenSSL certificates demonstrate that many operators rely on automated deployment scripts without hardening their network visibility.

For defensive teams, this case highlights the value of proactive, source-code-driven threat hunting. By analyzing open-source repositories before they see widespread use in active campaigns, defenders can build effective passive signatures. This allows organizations to identify, track, and block adversarial control surfaces well before they are targeted.