Adapt or pay: an analysis of the AdaptixC2 framework

Introduction

As highlighted in our previous post about the Mythic framework, threat actors are rapidly adopting emerging technologies and frameworks. A prime example of this trend is AdaptixC2, a relatively new open-source post-exploitation framework that has quickly captured the attention of the offensive security community. Its popularity stems from its open-source nature and high extensibility; the framework supports BOFs (Beacon Object Files) – including asynchronous ones – and features a growing ecosystem of modules, extensions, and third-party BOF collections. We are increasingly observing AdaptixC2 in the wild, particularly within APT attacks and ransomware campaigns, which we regularly report on.

To minimize its footprint, AdaptixC2 employs diverse network communication and post-exploitation techniques designed to bypass traffic monitoring tools like IDS and NDR solutions. Despite these evasion tactics, network-level detection remains one of the most effective methods for identifying agent presence and activity, as many of the framework’s host-based post-exploitation techniques aim to complicate artifact-based forensic analysis. Consequently, standard defensive measures may fall short, necessitating advanced endpoint monitoring that uses EDR solutions.

This article details ways of detecting the AdaptixC2 framework by analyzing its command-and-control traffic and activity on the endpoint.

The AdaptixC2 framework

AdaptixC2 is a command-and-control (C2) framework engineered for post-exploitation and stealthy interaction with its malicious agents deployed on compromised systems. Unlike many general-purpose C2 platforms, AdaptixC2 focuses on advanced agent-to-C2 communication and specific evasion techniques designed to bypass modern security tools, including EDR and NDR solutions.

Written in Go and C++, the AdaptixC2 architecture follows a model that separates the server-side component from the agents deployed on compromised hosts. This approach enables centralized agent management, command execution tracking, and supports post-exploitation activities. Particular emphasis is placed on the flexibility of network communications and the ability to modify communication channels. This allows agent behavior to be tailored to specific environments and complicates detection by monitoring tools.

The framework provides the flexibility to develop custom agents while also including standard agent implementations in Go and C++ for Windows, macOS, and Linux.

Additionally, it supports a modular approach to extending its functionality. Features can be added in the form of modules that use BOFs. This approach allows operators to deploy new post-exploitation capabilities without recompiling the core agent. It also streamlines the development and integration of custom modules.

From a defender’s perspective, AdaptixC2 activity can surface across various stages of infrastructure compromise. It aligns with multiple phases of the Unified Kill Chain and maps to several MITRE ATT&CK tactics and techniques – primarily those associated with controlling compromised systems, executing commands, and maintaining a persistent C2 channel.

• Command and Control (TA0011) involves establishing and maintaining communication between the operator and compromised hosts to transmit commands, retrieve outputs, and monitor agent status. AdaptixC2 offers a diverse array of C2 communication methods.
• Credential Access (TA0006) is the credential harvesting tactic. The AdaptixC2 Extension Kit implements an extensive suite of methods to obtain credentials, from standard LSASS dumping to more sophisticated ADCS exploitation and Kerberos-based attacks.
• Defense Evasion (TA0005) is the tactic designed to bypass detection by security controls. AdaptixC2 features a sophisticated toolkit of advanced methods for implementing this tactic.
• Lateral Movement (TA0008) designates methods enabling the adversary to move within the target infrastructure. Of these, AdaptixC2 supports PsExec and WinRM.

In this article, we shift our focus beyond detecting network communication to look at the methods for detecting agent activity on endpoints.

AdaptixC2 network indicators

As of this writing, AdaptixC2 supports data transmission over HTTP/S, TCP/mTLS, SMB, DNS, and DoH.

The framework has two distinct approaches to communication:

• External (Egress): agents communicate directly with the C2 server by utilizing HTTP/S, TCP, and DNS/DoH.
• Internal (P2P): agents communicate with adjacent agents, establishing a chain back to a host that interfaces directly with the C2 server. This approach leverages TCP and SMB.

Egress (external communications)

Direct agent-to-server communication is facilitated through the following protocols:

• HTTP(S)
• TCP
• DNS

Of the list provided, HTTP is the most common protocol for agent-to-C2 communication. TCP is less prevalent, while the DNS transport module suffers from several technical issues and is rarely encountered in the wild. Despite this, we will examine the DNS transport implementation and highlight the key factors that facilitate the detection of agent activity in network traffic.

HTTP

Due to the ubiquitous nature of HTTP, agent network traffic can blend into the flow of ordinary HTTP requests. Additionally, configuring the HTTP listener’s server side with OPSEC principles in mind allows this activity to be masked as legitimate network exchange, significantly reducing the likelihood of detection.

The server identifies the agent by a unique value transmitted in an HTTP request header, referred to as the Heartbeat Header. This value is linked to the agent ID and other technical data that the agent needs to function. Before transmission, this data is encrypted using the RC4 algorithm and then Base64-encoded. The encryption key is regenerated every time an HTTP server is created.

By default, the header containing this value is named X-Beacon-Id. This name is set automatically, but it can be changed if necessary.

Another default parameter is the User-Agent header. Its initial value is:
Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0.

Below is an example of AdaptixC2 network traffic over HTTP, utilizing default field values.

The User-Agent value used here is not unique and can be found in legitimate network traffic. The X-Beacon-Id header serves as a more distinct network indicator that may point to the presence of the AdaptixC2 framework.

The agent encrypts the payload using the RC4 algorithm and transmits it within the body of a POST request. Due to this encryption, the request content cannot be decrypted without the corresponding key; consequently, it’s generally difficult to build reliable detection logic based on this data alone.

The following screenshot shows how the NDR module within Kaspersky Anti Targeted Attack detects agent-to-server communication over HTTP when standard headers are used. This activity triggers a Backdoor.AdaptixC2.HTTP.C&C alert.

The framework also allows for the customization of the Heartbeat Header, allowing the operator to assign it any arbitrary name. For instance, we’ve identified samples that mimic authorization tokens and identifiers used by popular platforms.

Below is an example of AdaptixC2 network traffic over HTTP using customized headers.

Given the constraints on allowable characters in HTTP headers and considering that the X-Beacon-Id content consists of Base64-encoded data, a signature-based rule can be developed to detect agent-initiated requests over this protocol. Furthermore, detection logic can incorporate conditions regarding the specific order and presence of HTTP headers, as well as the frequency of these requests. In this scenario, the implementation of rules for GET and POST methods would differ only slightly, while retaining all the previously described techniques.

The combination of these indicators allows for developing a detection mechanism capable of identifying agent activity even when the agent has been customized and masked as a source of legitimate network traffic.

Below is an example of AdaptixC2 agent network traffic found in the wild and using HTTP with customized headers. Here, the X-Beacon-Id is transmitted within the Cookie field, while the User-Agent and endpoint attempt to mimic legitimate Windows Update activity.

The server response follows a standard structure and is transmitted in JSON format, containing status, data, and metrics fields. The payload is located within the data field and encrypted using the RC4 algorithm. The remaining fields are essentially unused and serve only to create a plausible-looking response structure.

This structure mimics responses from services and platforms that handle various metrics. However, even with these masking techniques, this response format can serve as a highly reliable network indicator. It is susceptible to signature-based detection, especially when supplemented by an analysis of communication intervals and packet counts, while excluding known legitimate platforms that use similar formats.

Based on our findings and the examples provided, customization is most frequently applied to the client side, while server responses typically remain standard. However, these can also be modified. The server response format is limited only by the developer’s imagination and the need to transmit the RC4-encrypted payload.

Below are examples of AdaptixC2 agent HTTP network traffic found in the wild utilizing a customized server response. In one instance, the JSON fields were modified; in another, they were removed entirely, leaving only the encrypted payload.

The following screenshot illustrates how the NDR module detects agent-to-C2 communication over HTTP. In this case, the agent’s network traffic mimics legitimate service activity and lacks standard fields. KATA generates a Backdoor.AdaptixC2.HTTP.C&C alert.

HTTPS

AdaptixC2 agents can also interact with the control server over HTTPS using a dedicated transport module. In this case, the transmitted data is encrypted using TLS, which significantly complicates content analysis and reduces the effectiveness of direct signature-based approaches.

However, even with encryption in place, such network activity can be identified by a combination of indirect indicators associated with establishing and maintaining the connection. In certain instances, specific characteristics of the secure channel configuration unique to AdaptixC2 serve as additional factors that simplify detection.

Below is an example of AdaptixC2 agent detection based on its traffic. In this scenario, a rule was triggered by the establishment of an HTTPS connection featuring distinctive TLS parameters.

TCP

The AdaptixC2 framework also implements a method for agent-to-C2 communication based on the reverse-shell principle. This approach bypasses various network restrictions, as outbound connections are typically permitted by security policies. The reverse-shell-like connection is established over the TCP protocol: the agent connects to the C2 server using TCP sockets.

By default, after the agent initiates the connection, the C2 server responds with a standard banner: AdaptixC2 server. Once this banner is received, internal agent initialization begins, followed by the exchange of service data.

Below is an example of TCP network traffic where the server returns the standard banner.

If the server doesn’t recognize the agent, it uses another boilerplate response: Connection error…. These artifacts can be identified through signature-based analysis of network traffic.

However, the values can be modified when creating a listener on the operator side. Therefore, relying solely on these is not a robust solution for building detection logic.

Once the client receives the banner, all subsequent communication between the agent and the C2 server is encrypted using the RC4 algorithm. As a result, the traffic content is generally resistant to signature-based analysis. In such cases, the following behavioral indicators may serve as signs of suspicious activity:

• Atypical, previously unobserved host interaction with an external server
• A persistent encrypted data stream with high entropy similar to the values characteristic of RC4-encrypted traffic

Below is a screenshot of a KATA NDR module alert detecting AdaptixC2 agent activity in TCP network traffic in Egress mode.

The transport module in question operates over TCP and independently provides traffic encryption between the agent and the server.

mTLS

For enhanced stealth during TCP data transmission, AdaptixC2 supports the Mutual TLS (mTLS) protocol. This is an extended version of the standard TLS protocol that implements mutual authentication. Unlike the traditional TLS scheme with its one-way authentication process (the client verifying the server’s identity via its certificate), mTLS requires the server to also request and verify a client certificate before establishing a secure connection.

Due to the mutual verification of certificates on both the client and server sides, intercepting and decrypting this traffic is significantly more difficult.

To capture the decrypted payload, modifications were made to the mTLS transport module’s code, adding the ability to log transmitted data before encryption and after decryption.

Below is an example of a log containing agent communication over the mTLS protocol, alongside its decrypted portion.

Analysis of the payload transmitted via Mutual TLS (mTLS) shows that it is identical to the data found in sessions using TLS and TCP transport modules. The command structure, data encapsulation format, and encryption algorithms remain consistent regardless of the underlying transport layer.

However, the implementation of mutual authentication (mTLS) substantially limits the effectiveness of network monitoring tools in detecting agent activity. When traffic decryption at the network level is not feasible, identifying agent activity becomes challenging and, as a rule, can only be achieved by using EDR solutions on the endpoint.

DNS

AdaptixC2 supports the transmission of data and commands from C2 via both traditional DNS over UDP and DNS over HTTPS (DoH).

This communication method enables the masking of the communication channel between the agent and the server. When using standard DNS over UDP, the payload is encapsulated within legitimate domain name resolution requests; in DNS over HTTPS mode, the data exchange is further disguised as routine HTTPS traffic.

DNS over UDP

DNS over UDP is a standard protocol for domain name resolution that attackers frequently leverage to establish covert communication channels.

In AdaptixC2, this protocol serves as the primary transport for Beacon DNS. It facilitates command delivery and transfer of collected data between the agent deployed on a compromised system and the C2 server, which in this case is the authoritative DNS server for the associated domain.

Beacon DNS supports four primary operations, which are unambiguously identified by the second element (from left to right) within the DNS request structure.

Each operation type is assigned a specific string identifier:

• Initialization (www/hi): agent registration with the C2 server and the initial handshake
• Data transfer (cdn/put): sending data fragments (for example, command output or exfiltrated data)
• Data retrieval (api/get): downloading tasks, commands, and configurations from the server
• Heartbeat (hb): maintaining session activity, periodically polling for pending tasks, and confirming successful data downloads

Despite differences in processing logic, all packet types adhere to a unified hierarchical domain name structure. Each dot-delimited subdomain has strictly defined semantics and is interpreted by the corresponding handler on the C2 server. The screenshot below shows a fragment of agent traffic using the DNS protocol.

The initial packet performs agent initialization using the www operation identifier. Subsequent requests maintain communication between the agent and the server using the hb identifier.

Analysis of the network traffic reveals anomalous DNS requests featuring a distinctive hierarchical subdomain structure.

In the provided packet dump, DNS requests follow this format:

Let’s take a closer look at the structure of an initialization packet using a specific example:

Field decomposition:

• Session ID (base[0]): an 8-byte unique session identifier (in this example, 39912991). This is used to consistently identify all requests from a specific agent within a single session.
• Operation identifier (base[1]): specifies the operation type, such as agent registration, heartbeat signaling, or task processing. This is represented as an ASCII string.
• Sequence number (base[2]): an 8-byte packet sequence number, encrypted using XOR. This serves as a defense against replay attacks, ensuring each request remains unique even when the data is identical.
• Unused (base[3]): this field is not utilized by the handler.
• Encrypted data (base[4]): the payload, encoded in Base32 and encrypted with the RC4 algorithm. In the initialization packet, this field contains critical data: operating system details (version, build, and x86/x64 architecture), the name of the process hosting the agent, the host name, user credentials, network environment information, and more.

This DNS request structure exhibits several characteristics typical of DNS tunneling:

1. High subdomain nesting: a request contains more than eight subdomain levels, which is atypical for legitimate DNS traffic.
2. High name entropy: subdomains consist of pseudorandom character sequences, such as hex strings or Base32/Base64-like encoding.
3. Structured data encoding: subdomains like 2HNLIUOKKYKFYML3KIJDPOBHLO67TE5PKSWA indicate the use of encoding algorithms to encapsulate a payload.

This technique allows attackers to bypass traditional perimeter security controls, as DNS traffic (port 53/UDP) is rarely subjected to deep packet inspection and is typically permitted for outbound connections by default.

The use of string literals such as www, cdn, api, and hb combined with a strictly structured subdomain hierarchy and predictable field lengths creates a distinct network indicator for identifying agent activity. Additional indicators of compromise include what we mentioned above: abnormally long domain names (exceeding 100 characters) along with high subdomain entropy, an excessive number of nesting levels (more than five subdomains), and the frequency of requests, such as periodic heartbeats targeting the same domain.

The combination of these characteristics enables the effective detection of AdaptixC2 agents utilizing DNS over UDP as a command-and-control and data exfiltration channel.

The following screenshot shows how the NDR module detects agent-to-server communication conducted over the DNS protocol. This activity triggers a Backdoor.AdaptixC2.DNS.C&C alert.

DNS over HTTPS

To implement Beacon DNS, the AdaptixC2 agent also supports the DNS over HTTPS (DoH) protocol. This mechanism encapsulates standard DNS queries within HTTP messages transmitted over a secure TLS connection. From the network analysis perspective, DoH masks agent activity as legitimate web traffic, making it significantly more difficult for monitoring tools designed to analyze unencrypted traffic to detect malicious actions.

Below is a screenshot of network traffic during agent initialization, shown without TLS decryption.

The network traffic generated by the agent reveals not only connections to the C2 server but also name resolution attempts through trusted public resolvers specified during the agent creation phase. In particular, the analyzed traffic includes DNS queries directed to the following public resolvers:

• https://dns.google/dns-query
• https://cloudflare-dns.com/dns-query
• https://dns.quad9.net/dns-query

Using these services allows attackers to hide malicious traffic within the overall flow of legitimate requests to popular infrastructure services.

When creating an agent, the default User-Agent used is Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0. It’s worth noting that Firefox version 20.0 is obsolete and was supported by operating systems such as Windows 7/8, Windows Server 2003, and Windows XP.

After decrypting the TLS session, the packet structure appears as follows:

Characteristics of agent operation over DoH:

1. Transmission method: the POST method is used to send DNS queries through the DoH mechanism.
2. Content headers: the presence of the two headers, namely Content-Type: application/dns-message and Accept: application/dns-message complies with the RFC 8484 specification and is a hallmark of DoH traffic.
3. Payload structure: the body of the POST request fully replicates the structure of DNS over UDP packets. The high-entropy subdomain string (Base32 encoded, then RC4-encrypted) is transmitted unmodified and is encapsulated into a binary DNS message, which is then carried within the HTTPS request.

Despite the use of HTTPS encryption, the DoH implementation in AdaptixC2 features several stable network indicators that allow for effective detection. These indicators include the use of the obsolete Firefox version in the User-Agent header, regular POST requests to the /dns-query endpoint, and a repetitive domain name structure with predictable subdomain lengths. Together, these characteristics form a distinct behavioral profile of AdaptixC2 agent DoH traffic.

The image below displays the KATA NDR interface with an alert detecting AdaptixC2 agent activity during its initialization via DNS over HTTPS using traffic decryption. The Backdoor.AdaptixC2.HTTP.C&C rule was triggered.

P2P (internal communication)

AdaptixC2 offers pivoting capabilities through named SMB pipes and TCP sockets. To identify agent activity in P2P mode, we will examine their network traffic and highlight the specific features and patterns that enable the detection of these malicious actions.

SMB

To establish communication between agents via the SMB protocol, the framework utilizes named pipes. The pipe name can be customized to any value when the listener is created.

Messages transmitted between agents are encrypted using the RC4 algorithm, rendering their content resistant to signature-based analysis. Nevertheless, during SMB communication, distinct characteristics can be identified – not only within the packets themselves but also in their sequence and frequency. These anomalies allow for detecting agent activity within the network.

The screenshot below illustrates how a connection establishment session between agents appears in Wireshark.

During agent initialization, we focus on the following sequence of commands:

• GetInfo Response
• Ioctl Response: STATUS_BUFFER_OVERFLOW
• Read Response

Of these commands, the Read Response is directly related to agent activity. The response contains the size of the subsequent packet as a single DWORD (4 bytes), ranging from 100 to 140 in decimal. The following packet contains technical information for agent registration, encrypted with RC4. Below is an example of a Read Response.

Individually, these commands are not particularly noteworthy, however, their strict order and placement at the beginning of the SMB data stream are key elements for detection logic.

Another behavioral characteristic of communication using this transport is the traffic generated while the agent is idle. Every N seconds, the agent checks for new commands by reading the named pipe.

The frequency of these checks for commands over SMB is inherited from the polling interval of the parent transport module in Egress mode, through which commands are relayed to the C2 server. Depending on the Sleep and Jitter values, these requests will be executed at varying intervals.

If the agent is idle and no commands are present, its traffic with the parent agent will appear as follows:

The structure of the Ioctl Request is presented below:

Given the specific request type and characteristic protocol flags (Command: Ioctl (11), Function: FSCTL_PIPE_PEEK), as well as the strict packet sequence during idle mode, AdaptixC2 agent activity over the SMB transport can be identified using signature-based methods.

The image below shows the KATA NDR interface with an alert detecting AdaptixC2 agent operation in P2P mode via the SMB protocol. In this instance, the rule triggered upon detecting agent activity during its initialization phase.

TCP

In addition to named communication channels, AdaptixC2 provides the capability for pivoting via TCP.

This transport is based on raw TCP sockets and implements a client-server data transmission model. To complicate detection, the framework allows for a Prepend Data parameter – custom data that should be added to the beginning of every agent message.

In the default configuration, the port is set to 9000 and Prepend Data is pre-filled with a value of \x12\xabSimple\x20word\xa. However, it’s impossible to create a listener with this specific value as it triggers a syntax error. Consequently, encountering a payload utilizing this default Prepend Data value is impossible in a real-world scenario.

Furthermore, analysis has revealed that this field is not actually utilized by the agent during communication and has no functional impact on the traffic flow.

The screenshot below displays the network traffic during agent initialization and subsequent communication.

Consistent with the SMB transport behavior, the first message transmits the data length, typically ranging from 100 to 140 in decimal, as a big-endian DWORD (4 bytes). This value represents the size of the following packet, which contains the agent’s service metadata. All communication between agents is encrypted using the RC4 algorithm, making it resistant to content-based signature analysis.

Nevertheless, several characteristic features can be identified that indicate a high probability of AdaptixC2 agent activity over TCP. These involve not only the individual packets but also their specific sequence within the data stream.

One of the primary methods for detecting agent activity is identifying network communication between internal hosts on port 9000, which is used by this transport by default. Furthermore, the data exchange structure itself is highly revealing, as it contains elements identical to those found in the SMB protocol: the characteristic size of the initial packet and its contained value, the encryption algorithm used, and the sequence of messages. All subsequent communications follow a similar pattern, with the exception that payload package constraints are relaxed to accommodate the diverse range of commands and their corresponding output sizes.

The screenshot below illustrates the agent initialization process followed by the transmission of several commands.

By accounting for these specific characteristics, it’s possible to construct a streaming signature capable of detecting agent activity after the execution of just a few commands.

The image below shows the NDR interface with an example of an AdaptixC2 agent being detected in P2P mode over TCP, using a rule based on the logic described above.

In summary, network-based indicators allow for the effective detection of AdaptixC2 during the interaction phase between an agent, its C2 infrastructure, and other agents. However, detection capabilities are not limited to this. The endpoint remains a critical source of telemetry, where the execution of specific modules and typical post-exploitation behaviors can be identified. Accordingly, the next section will focus on analyzing agent activity on the host and the detection opportunities provided by EDR solutions.

Detecting post-exploitation activity using AdaptixC2 modules as an example

Let’s examine the capabilities of the AdaptixC2 agent using a typical post-exploitation attack chain as an example. This chain reflects the most characteristic scenarios of an attack’s progression on a compromised host, which can serve as a basis for building detection logic. Note that the actions described below can serve as indicators of not only AdaptixC2 but also other post-exploitation activities within the infrastructure.

Credential Access

After gaining access to a host, an attacker typically requires credentials. To extract them, they can employ several AdaptixC2 modules. Let’s consider the most likely scenarios for their application.

If the attacker has the necessary permissions, they can carry out an attack on the LAPS system to gain access to the attribute that stores the local administrator account password.

This activity can be detected by monitoring access requests to Active Directory attributes related to LAPS, as these store managed local passwords and administrative information regarding their rotation. Unauthorized access to such information may indicate an attempt to obtain privileged credentials.

Kaspersky EDR (KEDR) Expert detects this activity using the following rules: computer_discovery_via_ldap, laps_passwords_scan_via_ldap, and not_signed_process_ldap_request.

In addition, to gain access to credentials, an attacker may attempt to extract sensitive information directly from the memory of the lsass.exe process. This process is responsible for authentication and temporarily stores password hashes, Kerberos tickets, and other credentials used by the system to authenticate users and services. This type of activity on a compromised host is typically accompanied by opening the process with elevated access rights, utilizing memory dump mechanisms, or calling system APIs to read protected memory regions. These actions are anomalous for the majority of user and application processes and serve as a strong indicator of system compromise.

Therefore, to detect this activity, monitoring should focus on processes accessing the memory of lsass.exe, as these events identify malicious actions with high precision.

Kaspersky EDR (KEDR) Expert detects this activity using the suspicious_lsass_memory_access rule.

Furthermore, attackers may attempt to extract credentials from registry hives that store authentication parameters, cached data, and configuration values affecting the operation of security mechanisms. Taken together, this actions can be leveraged for subsequent privilege escalation or lateral movement within the network.

To identify this activity, it’s necessary to monitor access to critical registry hives. This allows for the tracking of requests originating from atypical or suspicious processes.

KEDR Expert detects this activity using the registry_key_sam_users_queried rule.

One of the most common methods for obtaining credentials involves accessing directories containing browser user data. Modern browsers store a significant amount of sensitive information within local profiles, including saved logins and passwords, session cookies, authentication tokens, browsing history, and form autofill data. By gaining access to profile directories, an attacker can extract credentials for corporate web services, email systems, and cloud platforms, as well as use active session cookies to bypass re-authentication and MFA mechanisms.

In some cases, this data is protected by operating system tools; however, when accessed within the user’s context or with elevated privileges, it can be decrypted and leveraged to further the attack. Obtaining access to browser data often serves as the starting point for lateral movement, the compromise of additional accounts, and establishing persistence within the infrastructure.

To detect this activity, it’s necessary to monitor access to directories containing sensitive browser data. It’s important to consider not only the access to profile catalogs itself but also the nature of the operations performed: mass reading of database files, copying these to temporary directories, creating archives, and launching processes that do not typically interact with user profiles.

Special attention should be paid to instances where these actions are performed outside of an interactive user session – for example, from the context of processes with elevated privileges or service accounts. This may indicate an attempt at centralized credential harvesting. Correlating file events with network activity is also helpful, as extracted data is often prepared for exfiltration to external resources.

KEDR Expert detects this activity using the credentials_from_web_browsers rule.

Furthermore, credential acquisition also strongly relies on attacks on the Kerberos protocol. Misconfigurations in this authentication mechanism can allow an attacker to gain access to accounts with elevated privileges, creating the conditions for further attack progression. AdaptixC2 supports specialized modules designed to exploit specific features of the Kerberos protocol.

To identify this activity, Active Directory auditing for Kerberos must be properly configured. This enables the detection of attacks by analyzing Windows security events – specifically Event IDs 4768 and 4769, which record the issuance and usage of authentication tickets.

KEDR Expert detects this behavior via the possible_asreproasting_via_preauth_value rule.

Defense Evasion

During malicious operations, attackers typically aim to minimize suspicious artifacts to evade security controls. A common technique for achieving this is injecting malicious code into the address space of a legitimate process.

Consequently, the payload executes under the identity of a trusted system or user process, significantly complicating detection by both signature-based and behavioral security mechanisms.

To detect this activity, defenders should monitor for the use of WinAPI functions frequently associated with process injection. These include calls that allow gaining access to a remote process, allocating memory within its address space, writing arbitrary code, and initiating execution.

Typically, these actions occur sequentially, forming a characteristic chain: opening a target process, allocating memory, writing data, and either launching a new thread or modifying the execution context. Such sequences – especially when occurring between processes with disparate privilege or trust levels – are strong indicators of a process injection attempt.

Another red flag is when a standard user process initiates these operations against system processes or widely used legitimate processes. Attackers favor this approach to mask malicious activity and bypass traditional defense layers.

Lateral Movement

Further progression of an attack typically involves lateral movement within the network – a capability fully integrated into AdaptixC2.

Let’s examine the lateral movement detection techniques using the exploitation of the WinRM (Windows Remote Management) service as a primary example.

To detect this activity, defenders must monitor processes characteristic of WinRM, as these facilitate remote command execution. Typically, the processes servicing WinRM sessions act as the parent for any new processes launched via remote management. Consequently, commands executed through WinRM spawn child processes that may appear to be launched locally, but their process tree reveals a parent linked to the WinRM infrastructure. This specific chain is a critical artifact for uncovering remote management abuse.

Furthermore, the launch of command shells, administrative utilities, or reconnaissance tools via WinRM is considered highly suspicious, particularly if this behavior is anomalous for the specific host.

KEDR Expert detects this activity using the suspicious_processes_spawned_by_winrm rule.

Conclusion

The AdaptixC2 post-exploitation framework continues to evolve and gain traction. As new agents and stealth persistence mechanisms emerge, the repertoire of techniques used to gain foothold, perform command and control functions, and move laterally expands too. However, despite the diversity of supported protocols, AdaptixC2 network communications retain several persistent characteristics. That’s why NDR solutions are capable of effective agent detection based on network traffic analysis. Kaspersky products provide such functionality in Kaspersky Anti Targeted Attack with an NDR module.

Kaspersky NDR is designed to identify modern threats within network infrastructure, detecting common post-exploitation frameworks via their distinct communication signatures. Even when an agent employs advanced evasion, masking, or obfuscation techniques on the endpoint, it must maintain a connection with its C2 server to receive commands, exfiltrate results, and coordinate subsequent attack stages. Consequently, network traffic monitoring remains a vital and effective method for uncovering AdaptixC2 activity.

Complementing network-layer detection, it is important to provide visibility into activity on workstations and servers using a powerful endpoint protection platform, such as Kaspersky EDR Expert. A bundle like that enables the capture of specific post-exploitation action chains and correlates isolated host events into a unified attack context. The combined use of Kaspersky NDR and Kaspersky EDR enhances detection coverage, identifying both the network manifestations of the framework and the agent’s internal maneuvers. This multi-layered approach is critical in countering sophisticated modern attacks that rely on post-exploitation tools and covert management.

Kaspersky solution verdicts (Kaspersky Anti-Targeted Attack with NDR module)

Backdoor.AdaptixC2.TLS.C&C
Backdoor.AdaptixC2.TCP.C&C
Backdoor.AdaptixC2.SMB.C&C
Backdoor.AdaptixC2.HTTP.C&C
Backdoor.AdaptixC2.DNS.C&C