Malware of the Day – Agent-to-Agent Communication via SMB (AdaptixC2)

What is Malware of the Day?

 

Lab Setup

Malware: AdaptixC2

MITRE Tactics: TA0011 Command and Control, T1071.002 Application Layer Protocol: File Transfer Protocols, T1090.001 Proxy: Internal Proxy, T1021.002 Remote Services: SMB/Windows Admin Shares, T1090.001 Proxy: Internal Proxy

Traffic Type: HTTPS (external), SMB (internal)

Connection Type: TCP

C2 Platform: AdaptixC2

Origin of Sample: Active Countermeasures Threat Hunting Lab

Host Payload Delivery Method: SEO Poisoning > Malicious Installer

Target Host/Beachhead: 192.168.2.14 (Windows 10 Enterprise x64)

Pivot Host: 192.168.2.88 (Windows 10 Enterprise x64)

Adversary Host: 165.22.159.5 (Ubuntu Linux 22.04)

External Beacon Timing: Phase 1: 4s, Phase 2: 30s, Phase 3: 60s

 

 

Malware of the Day Mission

To identify and share examples of post-compromise network activity in order to better detect and respond to potential network threats. Specifically we are looking for Command and Control (C2) communication channels used by attackers to obtain intelligence, issue commands, and exfiltrate data through a compromised host or hosts.

 

Background

The Blind Spot in Traditional Network Monitoring

Most network security monitoring solutions focus heavily – and understandably – on north-south traffic: the data flowing between internal networks and the internet. This is where we typically expect to find command and control channels, data exfiltration, and connections to malicious infrastructure. Tools like Zeek, Suricata, and network-based threat hunting platforms like RITA and AC-Hunter excel at analyzing this egress traffic, identifying beaconing behaviors, long connections, and other suspicious patterns.

However, this focus creates a significant blind spot: east-west traffic – the lateral communications between systems within the internal network. While security teams monitor the perimeter, attackers also leverage internal protocols to move laterally, communicate between compromised hosts, and coordinate multi-stage attacks without ever touching the internet-facing boundary that our monitoring tools are watching.

 

Agent-to-Agent Communication

Traditional C2 architectures follow a hub-and-spoke model: each compromised endpoint (agent) maintains its own independent connection to a central C2 server – see Image 1 below. While effective, this model has limitations. Every compromised host generating outbound connections to the same suspicious IP creates multiple opportunities for detection. Each beacon is a potential alert, and the aggregated pattern becomes increasingly obvious to behavioral analysis tools.

 

Agent-to-agent communication (also called peer-to-peer C2 or mesh networking) represents an evolution in C2 design – See Image 2 below. In this architecture, only one or a small number of “gateway” agents maintain direct connections to the external C2 server. These gateway agents then communicate with other compromised hosts (“internal” agents) on the internal network using legitimate internal protocols-most commonly SMB (Server Message Block).

 

Advantages of Agent-to-Agent Communication

This approach offers attackers several advantages:

Reduced Detection Surface: Instead of ten compromised hosts all beaconing to the same external IP, only one host shows this suspicious pattern. The other nine appear to be conducting normal internal network operations.

Blending with Legitimate Traffic: SMB is ubiquitous in Windows environments. File sharing, printer access, domain authentication, and countless other routine operations generate constant SMB traffic. A few additional SMB connections between workstations blend seamlessly into this background noise.

Resilience: If the gateway agent is discovered and remediated, the attacker can simply designate another compromised host as the new gateway, maintaining persistent access even after partial remediation.

Operational Flexibility: Attackers can send commands through the gateway agent, which then distributes them to other agents via SMB. This allows for coordinated, multi-host operations without requiring each host to check in with the external server.

 

SMB and Named Pipes: The Technical Foundation

To understand how agent-to-agent communication works over SMB, we need to understand the role of named pipes. Named pipes are a Windows interprocess communication (IPC) mechanism that allows processes to communicate with each other, either on the same machine or across a network using SMB.

When a process creates a named pipe, it essentially creates a communication endpoint with a specific name (e.g., \pipe\mypipe). Other processes can then connect to this pipe by name and exchange data bidirectionally. Over SMB, this communication can happen across the network, allowing a process on one machine to communicate with a process on another.

In a C2 context, here’s how it works:

1. The gateway agent on Host A maintains the external connection to the C2 server at 165.22.159.5
2. A secondary agent on Host B creates a named pipe (e.g., \pipe\agent)
3. The gateway agent on Host A connects to Host B over SMB (port 445) and opens the named pipe
4. Commands from the C2 server flow: C2 Server > Host A > SMB > Named Pipe on Host B
5. Results flow back: Host B > Named Pipe > SMB > Host A > C2 Server

From a network perspective, Host B never communicates directly with the external C2 server. All we see is SMB traffic between two internal hosts-completely normal in a Windows environment.

 

AdaptixC2: A Modern C2 Framework

AdaptixC2 emerged in early 2024 as an open-source C2 framework that quickly gained traction in both red team and threat actor communities due to several compelling features:

Agent-to-Agent Communication: Built-in support for peer-to-peer agent networking via named pipes over SMB, making it ideal for enterprises with mature network monitoring.

Cross-Platform Support: Native agents for Windows, Linux, and macOS, compiled as small, standalone binaries with minimal dependencies.

Flexible Beaconing: Dynamic beacon intervals that can be adjusted on-the-fly, allowing operators to switch between “fast and loud” and “slow and stealthy” modes as needed.

Plugin Architecture: Extensible design allowing operators to load custom modules for specific tasks without modifying core agent code.

Operational Security Features: Support for domain fronting, custom User-Agents, and encrypted communications that blend with legitimate HTTPS traffic.

 

Real-World Impact: Akira Ransomware Campaign

The theoretical threat of AdaptixC2 became tangible reality in August 2025 when The DFIR Report reported its use in an Akira ransomware campaign. The attack chain demonstrated the framework’s effectiveness:

1. Initial access via SEO poisoning led victims to a malicious software download
2. The Bumblebee loader deployed an AdaptixC2 agent on the beachhead host
3. The agent established external C2 communications and conducted reconnaissance
4. Using SMB and named pipes, the attacker pivoted to additional hosts without generating external connections
5. Through this mesh of compromised systems, the attacker deployed the Akira ransomware payload

What made this campaign particularly concerning was the speed and stealth of the lateral movement phase. Traditional network monitoring would have caught the initial beachhead agent’s external communications, but the subsequent pivot to additional hosts occurred entirely within the internal network, invisible to perimeter-focused detection tools.

This case underscores an important reality: detecting the initial compromise is only half the battle. If we cannot identify lateral movement and agent-to-agent communications, attackers can maintain persistence and expand their foothold even after we’ve discovered and remediated the original entry point.

 

Scenario

In today’s investigation, we examine a compromise that mirrors the patterns observed in real-world AdaptixC2 deployments. The attack began with an employee at the target organization searching for productivity software. Through SEO poisoning techniques, the attacker had successfully manipulated search engine results to position a malicious website prominently in the results for specific software queries.

The employee, believing they were downloading legitimate software from an authoritative source, executed what appeared to be a standard installer package. In reality, the installer contained an AdaptixC2 agent. Upon execution, the malware established a beachhead on the user’s workstation (192.168.2.14) and immediately began communicating with the attacker’s C2 server at 165.22.159.5 over port 8443 using HTTPS.

Following a pattern we’ve observed in sophisticated campaigns, the attacker employed a multi-phase beaconing strategy. Initially, the agent checked in every 4 seconds – a rapid pace that allowed the attacker to efficiently conduct reconnaissance, enumerate the local system, and identify the network topology. After gathering sufficient intelligence, the beacon interval was adjusted to 30 seconds, representing a balance between operational efficiency and reduced network noise. Finally, once the attacker had positioned themselves for the next stage of the attack, the beacon slowed to 60 seconds, minimizing the detection surface while maintaining persistent access.

During the reconnaissance phase, the attacker identified a second workstation on the same network segment (192.168.2.88) that appeared to be a high-value target based on the user’s domain privileges and access to sensitive file shares. Rather than deploying a second agent that would independently beacon to the external C2 server-thereby doubling the risk of detection-the attacker leveraged AdaptixC2’s agent-to-agent communication capability.

The beachhead agent on 192.168.2.14 connected to 192.168.2.88 over SMB (port 445) and deployed a secondary agent. This secondary agent never established its own external connection. Instead, it created named pipes and waited for commands to be relayed through the beachhead agent.

 

Network Behavioral Analysis with RITA

Our investigation began, as it often does, with routine analysis of network logs in RITA. Examining the previous 24 hours of Zeek data, one connection immediately stood out – see Image 3 below.

 

The connection from internal host 192.168.2.14 to external IP 165.22.159.5 on port 8443 was flagged with high severity and displayed several concerning characteristics:

High Beacon Score: RITA calculated a beacon score of 87.3%, indicating highly regular, automated communication patterns consistent with C2 behavior.

Significant Duration: The connection spanned nearly 18 hours (17h 42m), far exceeding what we’d expect from legitimate application traffic.

Non-Standard Port: While HTTPS is common, the use of port 8443 (commonly used for alternative HTTPS services) rather than standard port 443 is slightly unusual and worth investigating.

Further, we can also see that RITA applied the “Rare Signature” modifier, indicating that this connection used a User-Agent string that was unique among all connections from this host – see Image 4 below. While not inherently malicious, this rarity suggests the application generating this traffic is not part of the host’s normal communication profile.

 

The User-Agent in question was: Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20121202 Firefox/20.0

At first glance, this appears to be a legitimate Firefox browser string. However, several details raise suspicion. The Windows version referenced is Windows 8 (NT 6.2), an operating system that reached end-of-life in 2016. The Firefox version (20.0) was released in 2013. While it’s not impossible for a user to be running such outdated software, it’s increasingly uncommon in managed enterprise environments.

A basic Google search for this User-Agent string returns numerous generic results – it appears frequently in various contexts. However, refining the search to include “malware” produces more interesting results – see Image 5 below.

 

Multiple security blogs and threat intelligence reports mention this specific User-Agent string in connection with AdaptixC2. Further research reveals this is the default User-Agent configured in AdaptixC2’s codebase. While attackers can change this value, many operators – particularly less sophisticated ones – use the defaults provided by the framework.

It’s crucial to note that there is nothing inherently malicious about this User-Agent string. The browser version and build are legitimate Firefox identifiers from 2013. The issue is contextual: why would a modern Windows 10 system (which we can confirm from other Zeek logs) be sending traffic that identifies itself as an outdated Windows 8 machine running decade-old Firefox?

This combination of factors – high beacon score, long duration, non-standard port, rare signature, and a User-Agent associated with known malware – provides strong justification for deeper investigation. We pivot to AC-Hunter for more detailed behavioral analysis.

 

Network Behavioral Analysis with AC-Hunter

Loading the same dataset into AC-Hunter allows us to visualize the connection’s characteristics in greater detail. Navigating to the Beacons module and filtering for connections from 192.168.2.14, we immediately locate the same suspicious connection to 165.22.159.5. The first thing that draws our attention is the connection interval histogram – the distribution of time delays between subsequent connections – see Image 6 below.

 

Rather than displaying the single, bell-curve-shaped cluster we typically see with simple beacons, this histogram shows three distinct groupings:

Cluster 1: Approximately 5,000 connections at 4-second intervals
Cluster 2: Approximately 1,500 connections at 30-second intervals
Cluster 3: Approximately 300 connections at 60-second intervals

This multi-modal distribution is the signature of a dynamic, adaptive C2 framework. The agent didn’t maintain a constant beacon interval. Instead, it operated in three distinct phases, each with its own timing characteristics.

Cross-referencing with the hourly connection graph at the bottom of the interface, we can map out the attack timeline – see Image 7 below.

 

Phase 1 (Green): The rapid 4-second beacon corresponds to the initial reconnaissance period. The high connection frequency allowed the attacker to efficiently run enumeration commands and receive results quickly. During this phase, we see the highest density of connections per hour-approximately 900 check-ins per hour.

Phase 2 (Red): The 30-second beacon represents a “balanced” operational mode. The attacker had gathered initial intelligence and was likely conducting more targeted actions: credential harvesting, privilege escalation attempts, lateral movement preparation. The connection frequency drops to roughly 120 check-ins per hour – still interactive, but less “loud” than the initial phase.

Phase 3 (Yellow): The 60-second beacon indicates a “maintenance” or “low and slow” mode. Having achieved their immediate objectives, the attacker dialed back the connection frequency to approximately 60 check-ins per hour, minimizing network noise while maintaining persistent access for future operations.

This adaptive behavior speaks to both the sophistication of the C2 framework and the operational discipline of the attacker. Many simpler C2 implementations use a fixed beacon interval configured at deployment time.

At this point in our investigation, we have strong suspicion of a compromised host:

1. High-confidence behavioral indicators (beacon score, duration, pattern)
2. Multiple independent anomalies (rare User-Agent, non-standard port, multi-phase timing)
3. OSINT correlation with known malware (AdaptixC2)

However, a critical question remains: Is this the only compromised host, or has the attacker pivoted laterally within the network? Given what we know about AdaptixC2’s agent-to-agent communication capabilities, we need to investigate whether 192.168.2.14 is serving as a gateway to other compromised systems.

 

The Detection Challenge: East-West Traffic

Here’s where traditional network monitoring reaches its limits. Our analysis thus far has relied on Zeek logs capturing north-south traffic-communications crossing the network perimeter. Zeek, like most network security monitoring tools, is typically deployed at strategic egress points: the border between the internal network and the internet, between network segments separated by firewalls, or at critical chokepoints in the architecture.

This deployment strategy is logical and efficient – we’re monitoring the points where malicious traffic is most likely to be identifiable: connections to suspicious external IPs, known malicious domains, unusual protocols at the network boundary, and data leaving the organization. However, this leaves east-west traffic -the lateral communications between hosts within the same network segment – largely unmonitored.

If our attacker has leveraged AdaptixC2’s agent-to-agent communication to pivot from 192.168.2.14 to another internal host, that communication would most likely occur over SMB on the local subnet. Unless we have network taps and sensors capturing intra-subnet traffic (which most organizations do not), these connections would be invisible to our network-based monitoring tools.

This is not a shortcoming of Zeek, RITA, or AC-Hunter – it’s a fundamental architectural reality. These tools can only analyze the traffic they can see, and in typical deployments, intra-subnet traffic is not captured.

So how do we detect lateral movement and agent-to-agent communication? We need to shift our detection strategy from the network layer to the host layer, leveraging endpoint telemetry.

 

Introducing Sysmon: Visibility into Host-Level Activity

System Monitor (Sysmon) is a Windows system service and device driver that, once installed, remains resident across system reboots to monitor and log system activity to the Windows event log. Developed by Microsoft as part of the Sysinternals suite, Sysmon provides detailed information about process creation, network connections, file creation, registry modifications, and numerous other events critical for security monitoring.

What makes Sysmon particularly valuable for threat hunting is its granularity and its ability to provide context that network monitoring alone cannot deliver. While network logs tell us that “a connection occurred between Host A and Host B on port 445,” Sysmon tells us “the process svchost.exe with PID 1234, running under user DOMAIN\jsmith, initiated a connection to Host B on port 445.”

This level of detail transforms ambiguous network connections into actionable intelligence. Sysmon is widely deployed in enterprise environments because it:

• Is Free and Supported: Developed and maintained by Microsoft, with no licensing costs
• Has Minimal Performance Impact: Optimized kernel-level driver with negligible overhead
• Provides Rich Telemetry: Over 20 distinct event types covering the most security-relevant system activities
• Is Highly Configurable: XML-based configuration allows administrators to fine-tune exactly what gets logged
• Integrates Seamlessly: Logs to standard Windows Event Log, easily forwarded to SIEM platforms

For our investigation, we’re particularly interested in three Sysmon event types:

Event ID 3 (Network Connection): Logs TCP/UDP connections made by processes, including source/destination IPs, ports, and process details

Event ID 17 (Named Pipe Created): Logs when a named pipe is created, capturing the pipe name and creating process

Event ID 18 (Named Pipe Connected): Logs when a connection is made to a named pipe, capturing both ends of the communication

These three event types, when analyzed together, can reveal agent-to-agent communication patterns that are completely invisible to network monitoring.

 

Sysmon Event ID 3: Detecting SMB Connections

Our hypothesis is that 192.168.2.14 (our confirmed compromised beachhead host) has established agent-to-agent communication with another internal system via SMB. To test this hypothesis, we need to examine Sysmon Event ID 3 logs on 192.168.2.14, specifically looking for outbound connections to port 445 (SMB) targeting other hosts on the local subnet (192.168.2.0/24).

While we could manually review these events in Windows Event Viewer, this approach becomes impractical when dealing with hundreds or thousands of events. Instead, we can use PowerShell to query and filter the Sysmon logs programmatically – see Image 8 below.

 

The script uses Get-WinEvent to retrieve all Sysmon Event ID 3 entries from the Microsoft-Windows-Sysmon/Operational log. It then filters for connections where:

1. The destination port is 445 (SMB)
2. The destination IP matches the pattern 192.168.2.* (same subnet)

Running this script produces the following results – see Image 9 below.

 

The results reveal two SMB connections from 192.168.2.14 to another internal host: 192.168.2.88.

Now, it’s important to acknowledge that SMB connections between internal hosts are common and legitimate. Windows systems routinely use SMB for file sharing, printer access, administrative tasks, and numerous other operations. A single SMB connection to another host is not, in isolation, evidence of compromise.

However, in the context of our investigation – where we’ve already identified 192.168.2.14 as compromised with high confidence – this SMB activity takes on greater significance. The question is: Has 192.168.2.88 been compromised as well, or was this simply a reconnaissance attempt by the attacker?

To answer this question, we need to shift our investigation to 192.168.2.88 itself and examine Sysmon Event IDs 17 and 18.

 

Sysmon Event IDs 17 and 18: Named Pipe Analysis

Named pipes are the mechanism by which AdaptixC2 (and many other C2 frameworks) implement agent-to-agent communication over SMB. When a secondary agent is deployed on a pivot host, it creates a named pipe – essentially, a communication endpoint that the gateway agent can connect to across the network.

By analyzing these events on 192.168.2.88, we can determine if any processes have created suspicious named pipes that might be used for C2 communications. Let’s run a PowerShell script to extract all Event ID 17 and 18 entries – see Image 10 below.

 

This script retrieves both Event ID 17 (pipe creation) and Event ID 18 (pipe connection) from the Sysmon log, extracting the pipe name and the associated process image path. The results include a mix of legitimate system activity and our suspicious entries.

It’s worth taking a moment to understand what “normal” named pipe activity looks like. Windows uses named pipes extensively for inter-process communication. Some common examples include:

• \crashpad_*: Used by Chromium-based browsers (Chrome, Edge) for crash reporting
• \LOCAL\crashpad_*: Similar crash reporting pipes with local scope
• \mojo.*: Used by Chromium’s Mojo IPC framework for inter-process communication
• \chrome.*: Various Chrome browser communication channels
• \PSHost.*: PowerShell host pipes for console applications

These are all completely benign. When reviewing Sysmon Event IDs 17 and 18, the majority of entries will be legitimate system and application activity. Our task is to identify the outliers – pipes that don’t fit expected patterns. Though C2 frameworks have default values they employ – for example Cobalt Strike uses \msagent – this value can be set manually by the attacker, so it’s more important to be able to spot something out of place, than any specific value per se.

Filtering through our results, two categories of entries stand out as highly unusual – see Image 11 below.

 

These entries are deeply suspicious for multiple reasons:

Unknown Process: smb69.exe is not a standard Windows system binary, with the filename itself being suspicious – “smb69” suggests someone manually naming a file with limited creativity.

Downloads Folder Execution: The process is running from C:\Users\tresa\Downloads\, a location commonly used for malware delivered via phishing, drive-by downloads, or social engineering. Legitimate applications, once installed, do not typically execute from the Downloads folder.

Named Pipe “\agent”: This is a highly suspicious pipe name. While there’s nothing technically wrong with creating a pipe called “\agent,” this name doesn’t correspond to any known legitimate Windows service or application. More significantly, \agent is a common naming convention in C2 frameworks – it’s simple, descriptive (from the attacker’s perspective), and memorable.

Anonymous Pipes: The second pair of events shows the creation and connection to an <Anonymous Pipe>. While anonymous pipes are legitimate (they’re unnamed pipes typically used for parent-child process communication), their use by an unknown executable in the Downloads folder is concerning.

The final step in our investigation is to take a closer look at the identified binary.

 

Binary Analysis with VirusTotal

With high confidence that smb69.exe on 192.168.2.88 is malicious, we need to confirm its identity and risk level. While we could perform static or dynamic malware analysis in a sandbox environment, a faster initial assessment is to check the binary’s hash against VirusTotal’s extensive malware database.

After extracting the file from the endpoint (following proper evidence handling procedures and ensuring we don’t execute it), we calculate its SHA-256 hash. Submitting this hash to VirusTotal reveals the following results – see Image 12 below.

 

We see that not only did numerous vendors identify this binary as being malicious, but a handful also specifically identified it as belonging to AdaptixC2, confirming our initial suspicion.

At this stage of our investigation, we have definitively confirmed a compromise affecting two hosts. The case is now sufficiently strong to escalate to the Incident Response team with high confidence.

 

Conclusion

This investigation into an AdaptixC2 compromise highlights several critical lessons for threat hunters and network defenders:

 

The Limits of Network-Only Monitoring

Traditional network security monitoring – even with sophisticated tools like RITA and AC-Hunter – can only detect what it can see. While these tools excel at identifying suspicious north-south traffic patterns, they typically have limited or no visibility into east-west communications within network segments. Attackers increasingly leverage this blind spot by using agent-to-agent communication architectures that minimize external connections while enabling lateral movement and coordination entirely within the internal network.

This isn’t a failure of network monitoring tools – it’s an architectural reality. The solution isn’t to abandon network monitoring but to complement it with endpoint telemetry that provides visibility into host-level activities that network captures miss.

 

The Power of Behavioral Analysis

Even when confronted with sophisticated evasion techniques, behavioral analysis remains our most reliable detection method. The multi-phase beaconing pattern exhibited by the AdaptixC2 agent on 192.168.2.14 was distinctive enough to generate high-confidence alerts in both RITA and AC-Hunter.

The framework’s use of dynamic beacon intervals – intended to balance operational efficiency with stealth – potentially worked against the attacker by creating a clear multi-modal pattern in the connection interval histogram.

This underscores a fundamental truth about threat hunting: we’re not looking for individual indicators, we’re looking for patterns of behavior that deviate from baseline norms. RITA and AC-Hunter’s strength lies in their ability to automatically identify these behavioral anomalies at scale, cutting through the noise to surface the handful of connections that warrant investigation.

 

Layered Defense is Not Optional

The detection of this compromise required data from three distinct layers:

1. Network Behavioral Analysis: RITA and AC-Hunter identified the suspicious external C2 connection from 192.168.2.14
2. Endpoint Network Telemetry: Sysmon Event ID 3 revealed the lateral SMB connections to 192.168.2.88
3. Endpoint Process Telemetry: Sysmon Event IDs 17 and 18 exposed the named pipe communications indicative of agent-to-agent C2

Had we relied exclusively on network monitoring, we would have detected the beachhead compromise but missed the pivot to the second host. Had we relied exclusively on endpoint monitoring without network context, we might have dismissed the SMB connections and named pipes as potentially legitimate. It was the combination and correlation of data from multiple sources that built an irrefutable case.

 

Recommendations for Defenders

Based on this investigation, we recommend the following for organizations seeking to improve their detection capabilities for sophisticated C2 frameworks like AdaptixC2:

1. Deploy Sysmon with comprehensive logging: At minimum, enable Event IDs 1 (Process Creation), 3 (Network Connection), 7 (Image Loaded), 17 (Pipe Created), and 18 (Pipe Connected). Use a well-maintained configuration template like the SwiftOnSecurity config as a starting point.
2. Centralize and analyze endpoint logs: Sysmon logs are only valuable if they’re collected, centralized, and analyzed. Forward them to a SIEM or log analysis platform where they can be queried and correlated with network data.
3. Maintain behavioral baselines: Know what “normal” looks like for your network – typical beacon patterns, common User-Agents, expected SMB communications. Anomalies are only detectable when we understand the baseline.
4. Investigate SMB connections holistically: Don’t dismiss SMB connections between internal hosts as automatically benign, especially when combined with other suspicious indicators. Look at the process context: What initiated the connection? When? To which specific host?
5. Monitor named pipe activity: Named pipes are legitimate and common, but unusual pipe names (especially short, generic ones like “\agent”, “\cmd”, “\shell”) combined with unknown or suspicious processes warrant investigation.
6. Leverage threat intelligence: Correlate observed indicators (User-Agents, file hashes, network patterns) with published threat intelligence. The User-Agent in this case was a key clue precisely because security researchers had documented it in their AdaptixC2 analysis.
7. Practice layered detection: No single tool or technique will catch every compromise. The combination of network behavioral analysis (RITA/AC-Hunter) and endpoint telemetry (Sysmon) creates a defense-in-depth approach where bypassing one layer still leaves the attacker exposed to detection by another.

 

Final Thoughts

The detection of this AdaptixC2 compromise demonstrates that even as attackers adopt increasingly sophisticated techniques like agent-to-agent communication and dynamic beaconing, they still leave behavioral traces that can be identified through systematic analysis.

The key is to approach threat hunting not as a search for known-bad indicators, but as an investigation of anomalous patterns. When we combine the pattern recognition strengths of tools like RITA and AC-Hunter with the deep host visibility provided by Sysmon, we create a detection capability that is resilient against evasion and adaptable to evolving threats.

Most importantly, this case reinforces that detecting the initial compromise is only the first step. Without the ability to identify lateral movement and agent-to-agent communications, we risk remediating the obvious while leaving the hidden persistent mechanisms intact. A truly effective threat hunting program must have visibility and analytical capabilities across multiple layers of the infrastructure – network, endpoint, and application – to build a complete picture of attacker activity.

 

Happy Hunting!
Faan

 

 

Capture Files

PCAPs

Because… PCAPs, or it didn’t happen. 😊

The following PCAP files are packet captures taken from the same lab environment over a 24-hour time frame. The files were generated using Wireshark from the target host and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The PCAPs are safe, standard PCAP files and do not include any actual malware.

AdaptixC2 Agent-to-Agent Hour Capture
adaptix_agent_to_agent_24h.pcapng
File Size: 590 MB
SHA-256 Checksum: 7A09ECBE04D4ABAFED0E122DA0E5A81AD296D4EE377CF2643A7620EBA6F55CDE

 

Zeek Logs

If you are an AC-Hunter or RITA user, we are providing the 24-hour Zeek logs for you to import directly into AC-Hunter or RITA. The following Zeek Logs have been taken from the same lab environment over a 24-hour time frame and include normal Windows OS traffic and normal network broadcast traffic. They have not been edited. The Zeek logs are safe, standard log files and do not include any actual malware.

Importing Zeek logs into AC-Hunter or RITA example:

ssh into your AC-Hunter or RITA server and upload all the Zeek logs contained in the zip file below (all files that have the ‘.log’ extension) into a temporary directory on the server. In this example, we are uploading the Zeek logs into /tmp/zeek_adaptix24h/

Then run the following command:

For AC-Hunter v6.x and RITA v4.x and earlier:

rita import /tmp/zeek_adaptix24h/*.log adaptixc2

For RITA v5.x+:

rita import --logs=/tmp/zeek_adaptix24h/*.log --database=adaptixc2

You will now have a new database in the AC-Hunter UI/web interface or RITA CLI titled “adaptixc2” you can select and view.

 

AdaptixC2 Agent-to-Agent Hour Zeek Logs
zeek_adaptix_agent_to_agent_24h.zip
Size: 1.1 MB
SHA256 Checksum: 9EEB2C2C89673CF003E432E8C9DA5029114FDAFE199D9DBDD0F77B3E06A09B68

 

Discussion

Want to talk about this or anything else concerning threat hunting? Want to share how good (or not so good) other detection tools were able to detect this sample?

You are welcome to join our Discord server titled “Threat Hunter Community” to discuss topics surrounding threat hunting. We invite you to join our server here.