The 2matrix website is designed to help red teamers find the right framework for their engagements and includes a matrix comparing open-source and commercial products. While some are popular and recognizable frameworks, others are new and upcoming frameworks with specific purposes. While these sites can help red teams and penetration-testing teams find the right product for their needs, they could also aid criminals find the next framework to use: preferably one that is growing in support and not detected well by the security industry.

To date, in the criminal underground, there is not as much discussion around DeimosC2 as an alternative, but attackers might be using DeimosC2 in the near future as a tool of choice and as part of their migration away from Cobalt Strike. The other tools that we’ve observed being discussed and used are PoshC2, PHPSploit, and Merlin. Similar to red teamers, cybercriminals like to use a mix of command line- and GUI-based C&C frameworks, depending on their preference among ease to build, maintain, and operate.  

In July 2022, Censys published a blog entry on the open-source C&C frameworks being used by ransomware groups. This included PoshC2 and DeimosC2 being employed in partnership with Metasploit and Acunetix, which are used for vulnerability scanning and system exploitation. Either PoshC2 or DeimosC2 was then used for the post-exploitation C&C communications.

While DeimosC2 is not the most popular choice for attackers currently looking for other C&C platforms to use, this is also exactly one of the reasons that it is important to study it in advance. Attackers will continue to evaluate tools that are lower in popularity, hoping that these systems go undetected for longer. Because of this, we have decided to look at DeimosC2 to get a better idea of what might make a criminal want to use this platform as their C&C framework of choice.

What is DeimosC2?

DeimosC2 is an open-source C&C framework that was released in June 2020. It is a fully-functional framework that allows for multiple attackers to access, create payloads for, and interact with victim computers. As a post-exploitation C&C framework, DeimosC2 will generate the payloads that need to be manually executed on computer servers that have been compromised through other means such as social engineering, exploitation, or brute-force attacks. Once it is deployed, the threat actors will gain the same access to the systems as the user account that the payload was executed as, either as an administrator or a regular user. Note that DeimosC2 does not perform active or privilege escalation of any kind.

Post-exploitation C&C servers are popular with red teams since they provide a convenient method of interacting with multiple victim machines, collecting notes, and storing evidence of what was done to each machine so that when incident responses are involved in any cleanup efforts, they can be provided information on everything that was done while the red team was in the systems.

The features Of DeimosC2

DeimosC2 has two options for installation on a system: a pre-built binary that does not depend on Go being installed, and the source code that can be compiled and run on any system with Go installed. For this research, the pre-built binaries inside of a Debian virtual machine (VM) were used, so some behaviors might be different compared to if the source code directly downloaded from the GitHub project had been used.

DeimosC2 combines a lot of the same features as other C&Csoftware platforms. One of the main purposes for a C&C system like DeimosC2 is to help red teams and penetration testers consolidate their infrastructure, collaborate with others by sharing compromised hosts during the engagement, and aid with reporting when engagements are finished. With that in mind, DeimosC2 has multiple user support with two roles for the users: Administrator and User. Figure 4 shows the two user setups in our tests of DeimosC2. 

Since DeimosC2 is also aimed at red teams, it has support for multifactor authentication (MFA), an API, backup, and restore features, as well as an ability to mark systems as either a development or a production system.

Once the users are set up, the next step is to set up the listeners, which are the sockets and protocols that the victim machines will reach out to. DeimosC2 has five types of listeners that users can configure for their payloads, with the most common that we’ve seen so far being HTTPS and TCP. We expect that as the popularity of tools like these grow, it is likely that we will see malicious actors use the DNS over HTTPS DNS over HTTPs (DoH) option as well. 

Once a selection is made, in this case HTTPS, the listener is configured by entering the data required for mandatory and certain optional settings. Settings such as domain names and IP addresses are required by the user, while the key and most of the advanced settings are optional. 

Inside the advanced settings, there are some configurable options for how the C&C server works. This is where you will find the settings for changing the default paths that the victim will use over HTTP POST to the C&C server. By default, these paths are /login, /index, /settings, and /profile, but these can be changed during the creation of the listener. They can also be changed at a later time; however, new binaries will need to be created.

Once all the settings are configured, the binaries will be created based on the options in the “compile options” portion of the settings. These settings determine which binaries are to be created and if they should be obfuscated.

Once the binaries are created, they are downloaded via the interface by selecting “interact” from the listener options. 

Once downloaded, these are ready to deploy on a machine that has been compromised via another means such as through phishing or an exploit. The ease of use to create post-exploitation binaries for C&C communications makes this an attractive framework for red teamers and penetration testers to include in their arsenal of tools.

DeimosC2 agent analysis

While many of the DeimosC2 samples are obfuscated with gobfuscate, an open-source tool for obfuscating programs written in Go language, we also found non-obfuscated samples. These allowed us to spot DeimosC2 package names, where we figured out that this was an open-source post-exploitation C2 framework. It is also possible to manually de-obfuscate the implemented changes of a tool like gobfuscate, but this will take more time for the investigator.

In DeimosC2 terminology, a client binary intended to infect victims is called an agent. DeimosC2 leverages the multi-platform nature of the Go language to compile agents for different architectures such as Windows, Linux, macOS, and Android.

The agent is straightforward: When executed, it immediately tries to contact the listener in the hard-coded C&C domain or IP address, except when an execution time range is set.

DeimosC2 agents use three different keys to exchange messages with the listener.

Agent key

This is a unique key that identifies the agent. The key is initially set to “000000000000000000000000000000000000”, but the first response from the listener updates it to a new version, 4 UUID.

AES key

This 256-bit AES key is randomly generated every time an agent talks to a C&C listener. This is used to encrypt messages exchanged with the C&C listener.

RSA key

Aside from AES encryption, DeimosC2 uses RSA-2048 to encrypt both the agent and the AES keys previously explained. The agent uses a hard-coded public key to encrypt the other keys, while the C&C listener decrypts the data with its private key.

Figure 8 illustrates the encryption process from the agent’s perspective.

The first message sent to the C&C listener includes information about the infected machine in JSON format, as shown in Figure 9.

The data sent includes information about the operating system, installed antivirus products, the host name, the logged username, the internal IP address, the agent path on the file system, available shell programs, the Process ID (PID), and user privileges.

Commands

The C2 listener response can include one or more commands (called “jobs” in DeimosC2 terminology). Table 1 provides a description of these commands.

Table 1. DeimosC2 commands and their descriptions

Modules

DeimosC2 extends its functionalities through modules that can be executed in the victim’s machine. In our lab, the following modules were available:

Table 2. The available DeimosC2 modules, as seen in our lab

The module interface of DeimosC2 allows the C&C listener to push new modules and execute them from either disk or memory (using code injection).

Network analysis

As we previously mentioned, there are a few listener types that users can choose while using DeimosC2, including HTTPS, TCP, and DoH. These are likely to be the most common options as they are popular with other C&C platforms. We were able to investigate how these listeners worked in detail because of DeimosC2’s open-source nature.

HTTPS listener

Once the listener is running for HTTPS, we observed that there was a default webpage that was configured. By reviewing the GitHub page, we confirmed that it was a default Ubuntu webpage for Apache. 

Based on the configuration of the listener during setup, we know that the tool uses a few paths. Looking into the .go version of the agent source code, we can see the processes that have been set up and are being used. 

The variable “firsttime” is used for the initial communication to the server. From then on, the variable “checkin” will be used as a heartbeat.

Based on this, we can fingerprint if the C&C server is in the default configuration and if HTTPS inspection is enabled. The agents will send HTTP POST to /login, and then to /index afterward at periodical intervals. The default port used for the HTTPS listener is 4443. However, this can be changed easily when creating the listener on any other port. The variable “moduleloc” at /profile is used to send data from the agent back to the server. Finally, the “piviotloc” variable is used to pass data through the current victim as part of the previously described piviotTCP functionality of the agents. 

Figure 13 shows an encrypted POST request sent by an agent configured to use an HTTPS listener. By default, it uses /login to send the first message, after which the agent sends requests to /checkin by default.

TCP listener

The TCP listener utilizes the Go language functions to create a packet and send it to a created socket. The flow for encryption works the same as it does with the HTTPS encryption. The only difference, in this case, is that there is a length for the overall message that will aid in the decryption of the data. To accomplish this, it prepends the encrypted data with the length of the data that was encrypted and is to be sent. This is sent to the socket, and then to the C&C server. 

Based on our analysis of the packets that were being sent from the TCP agent to the listener, this part has a predictable behavior. Because of the uint64 call, the created length will be in an unsigned integer that is 64 bits or 8 bytes long. The start of the data portion of the packet will have 8 bytes for the length of the packet to follow. This was the case with most of the information we observed on the heartbeat communications to the C&C server. Each packet was 350 bytes in total with 296 bytes of data. 

Since we know that the packet size is prepended to the data portion of the packet, and that it is an unsigned integer of 8 bytes, we can conclude that the first 8 bytes of the data is the size that will be followed in processing the packets.

In this case, where there is a data field of 296 bytes, if we take away the 8 bytes for the length field, this will leave 288 bytes for the commands from the C&C server. This is easily calculated if we take 288 bytes and convert it to the hexadecimal system, resulting in 0x120 or 01 20, which is what we find after the first 6 bytes of 0s in the examples we have seen. 

One possible way to detect this behavior is with a snort rule that looks for the heartbeat traffic. Here is an example of a Snort rule that would detect our sample packets:

alert tcp any any -> any any (content: “|00 00 00 00 00 00 01 20|”; offset: 0; depth: 8; msg:”Possible DeimosC2 TCP
Agent Heartbeat Communications”; sid:123400; priority:3; rev:1;)

Based on testing in Snort with only this rule enabled, we confirmed that it will detect the heartbeat communications from the TCP agent. Note that this rule might need tuning based on specific setups to remove false positives and enhance sensor performance. 

DoH listener

The DoH or DNS over HTTPS listener uses DNS queries to communicate with the C&C server. One of the advantages of using DoH is that there are no direct communications with the C&C server. However, there is a delay in the communications; therefore, DoH is often used if stealth is a requirement for the red-team engagement. DeimosC2 utilizes the HTTPS JSON API for DNS from Google. This is different from the RFC 8484-compliant DoH requests that Google also supports. It is an easier solution programmatically and is common for attackers to use. 

Within the listener configuration, there are two names you can change: the firsttime and checkin variables. When setting up the listener, the default names for these are getname and checkin, respectively. When the agent first reaches out to the listener, it will first use the firsttime variable, after which the checkin variable will be used for the heartbeat communications. Unlike HTTPS and TCP, the agent will not communicate directly with the listener, but it will communicate to the DNS Google service previously mentioned. 

On initial setup, one query that can be observed looks like the following:

• https://dns.google.com/resolve?name=0000000000.6765746e616d65.ftr.trendmicro.com

When you look at this query, there are a few things that stand out, one of which is the 6765746e616d65 subdomain that is generated from the code during the check-in process. In this case, the value takes the variable firsttime and converts its content to a hexadecimal system based on its ASCII values (getname in our case). This is then used as the first subdomain sent to dns.google.com. To decode this, the AES key is needed from either the agent or the C&C server itself. 

All these methods we’ve discussed are based on the paths and variables that are set to the defaults in the configuration, which is easy to change while building the listeners. Changing the default settings is good for when a red team is using it, since they can work with the blue teams to help find their traffic in the network logs. However, when a criminal changes these settings, it will make it more difficult to find them in future campaigns, since they change their variables to alter their tools, tactics, and procedures (TTPs) slightly to avoid detection or modify configurations based on the campaign. We present this information to help defenders understand what is happening behind the scenes in DeimosC2 should they encounter non-default behavior in an attack.

Changing default listener settings

Changing the paths is easy to achieve in the DeimosC2 user interface; take for example the default paths for the HTTPS Listener of /login, /index, /settings and /profile. To change this, all an attacker needs to do is to expand the Advanced Options while building the listener. 

Changing the paths is likely something that an attacker will do, and this will cause some of the things we’ve previously discussed to change in the binaries and in the traffic patterns. For instance, if the getname in the DOH agent is changed, it will no longer go to 6765746e616d65 but will instead redirect to a subdomain of whatever it was changed to, converted to the hexadecimal system (an example being “trendmicroftr”, which would look like 7472656e646d6963726f667472 in the DoH query). This is one of the things that makes finding some of these red team tools increasingly more difficult since the evasion techniques are built into the options.

Each of the listeners can be updated for specific information that will change some of the paths and subdomains that are used. The TCP listener has the least number of options and as of writing, will likely be one of the easiest listeners to detect via network monitoring methods.

Recommendations for defending networks against DeimosC2

Detecting C&C traffic can be a difficult proposition for network defenders across the globe. Fortunately, during our investigation into DeimosC2, we have found some techniques that can be used to detect the presence of the agents communicating with the servers.

• While some network activities are dynamic, such as the inspection of the paths of the URL (as these can be changed by malicious actors while setting up the listeners), others are predictable. For example, the first 8 bytes of the TCP listener communication can be used for detection using the provided Snort rule in an intrusion detection system (IDS).
• In the case of the DoH example, if defenders are not using a service that leverages the JSON version of DoH within normal business operations, it is recommended that HTTPS to dns[.]google is blocked or at least logged. Most of the current DeimosC2 samples that leverage DoH currently use the JSON version of DoH provided by Google, which will stop this agent from working altogether.

However, it is important to remember that DeimosC2 is a post-exploitation C&C framework, and if you are seeing its traffic on your network, you have already been compromised by another means, and this is just the actor setting up persistency. If you detect DeimosC2 in your system, you should be aware there will likely be other attack tools deployed that you might not be aware of. Assuming a stance that you are already compromised also provides additional defensive options:

• Defenders should perform regular monitoring of outbound communications for top talkers. In particular, they should flag any hosts that have a significantly larger amount of data sent than during a normal monitoring period.
• Looking for communications that are new but also occur suddenly and frequently is an important part of network defense and helps not only in spotting DeimosC2 communications but also in helping spot other malware and communications that are malicious in nature early — especially if they are based on any sort of phone home or heartbeat patterns.

Although not designed to be a defensive measure, these kinds of tools can also sometimes provide an unexpected advantage for the defenders. As we mentioned, a C&C framework is meant to make the lives of penetration testers and red teamers easier through a variety of functions, such as by logging every command they run (whether this is on by default varies from framework to framework).

While non-malicious actors use these kinds of tools to enable faster report creation, if investigators are able to seize a server in which the attackers had this option configured (perhaps unknowingly), it can be a fantastic source of intelligence on the attacker’s post-compromise activities.

Conclusion

This report was intended to shed light on one of several C&C frameworks that criminals are using. DeimosC2 is one of the alternative tools that SOC teams will likely see being used against their networks for post-compromise activities. Over the coming months and years, we expect to see a rise in the use of many of these alternative C&C frameworks. We have already seen malicious actors switching from Cobalt Strike to these alternatives as defenders get better at identifying and blocking the communications and agents that are deployed.

It is important to remember that tools like these are dual-purpose: Their presence does not immediately indicate cybercriminal behavior since they are also popular with both internal and external penetration testers and red teams. While the red team’s role is to perform adversary simulations and work with companies to help them defend their networks from these exact same tools, it is still in the interest of network defenders to be aware of their presence. By learning how to identify and block these tools, an organization can strengthen their defensive posture and prevent attackers from pivoting within networks, exfiltrating data, or generally doing harm to enterprises.

Indicators of Compromise (IOCs)

Known historical DeimosC2 servers

These are IP addresses that were observed to have a DeimosC2 panel. Some of these IP addresses are likely to have been part of a red-team exercise.

DeimosC2 samples

The details of several DeimosC2 samples observed in the wild, complete with platform, protocol, C&C server, and RSA public keys (useful for clustering behavior) can be found in this link.

This was compiled with the help of two x64dbg scripts we developed, which assist with configuration extraction.

Meanwhile, the list of Trend Micro detections can be found here.