Abcbot - An Evolution of Xanthe

Overview

Abcbot, the emerging botnet that we recently analyzed and reported on, has a longer history than we first thought. Our continued analysis on this malware family reveals a clear link with the Xanthe-based cryptojacking campaign discovered by Cisco’s Talos security research team in late 2020. Researchers at Talos discovered malware resembling a cryptocurrency mining bot when they were alerted to an intrusion on one of their Docker honeypots. 

The malware was named Xanthe and its main purpose is to hijack the resources of a compromised host to mine cryptocurrency. We discovered a link between the two campaigns when analyzing the infrastructure behind Abcbot. Once we began comparing analysis of malware samples from both campaigns, similarities within the code and feature-sets of both malware families became apparent too. 

Based on this analysis, we believe that the same threat actor is responsible for both Xanthe and Abcbot and is shifting its objective from mining cryptocurrency on compromised hosts to activities more traditionally associated with botnets, such as DDoS attacks.

Understanding the Infrastructure Behind Abcbot & Xanthe

To begin mapping the Abcbot campaign, we collated all known Indicators of Compromise (IoCs), including IP addresses, URLs and hashes. From this, we built a VirusTotal Graph which displayed this data in an easily-browsable format. After doing so, it became apparent that there were four main hosts comprising what we thought was the infrastructure behind Abcbot. Instead, we were looking at the infrastructure responsible for delivering two distinct malware campaigns - Abcbot and Xanthe.

Infrastructure Overlaps

There are a few infrastructure overlaps. For example, the following rule allowing ingress traffic from 64[.]225[.]46[.]44 in the Xanthe sample also appears in the Abcbot sample:

Whilst it’s common to see cryptojacking malware authors simply copy code from each other,  there are a number of other similarities discussed below which make a direct link in ownership between the Xanthe and Abcbot campaigns more likely.

For guidance on performing cloud IR, check out our latest playbook the Ultimate Guide to Forensics of Mining Malware in Linux Container and Cloud Environments.

Xanthe - An Overview

Xanthe is a family of cryptojacking malware with the primary goal of hijacking a system’s resources to mine the Monero cryptocurrency. Readers with some knowledge of the cloud threat landscape will not be surprised to hear that Xanthe utilizes XMRig for its mining capabilities. XMRig has been used in several similar campaigns due to its highly-configurable and open source nature. 

Xanthe spreads through the discovery of exposed Docker API endpoints. An initial script is used to install the malware’s main module xanthe.sh, which is responsible for propagation, network scanning and the downloading of four additional payloads. These additional payloads include a malicious library for hiding processes (libprocesshider.so), a script to disable security services and remove miners from competing campaigns and the XMRig binary itself along with configuration data. 

If you read our analysis of Abcbot, you will likely recognize some of the above and may also notice some differences between these malware families.

Code Similarities

In this section we’ll take a closer look at the code of the main Xanthe modules and we’ll compare this with the Abcbot sample we analysed previously. As we’ll see, there are several similarities in both the code itself and overall functionality that suggest the same person(s) are behind both malware families.

Code Formatting

In the original report from Cisco’s Talos security research team, researchers commented on the coding style of the shell scripts being analysed - in particular, functions being declared at the top of the file and then invoked in some of the later lines. Talos researchers suggested that this likely aids testing of new iterations, with functionality enabled/disabled through commenting of the lines responsible for function invocation. Both the Abcbot and Xanthe samples we compared follow this coding style:

Linking these two samples based on code style similarities alone would be tenuous, at best. However, if we look at some of the function names themselves, correlation becomes apparent. Several of the functions have “go” appended to the end of the function name and some functions have identical names. The following names appear in both samples:

• nameservercheck
• croncheckgo
• checkrc
• iptableschecker
• filerungo

We decided to dig deeper and compare the code from each of these functions individually to see if we could further confirm our hypothesis that these samples were related.

nameservercheck()

Comparing the above, we can immediately see that the Abcbot version of the nameservercheck function is significantly larger than the Xanthe counterpart. The Xanthe sample we analyzed is older than the Abcbot sample by over a year (according to VirusTotal submissions). This could indicate that the Abcbot version of the function has been iterated on several times, with new functionality added at each iteration. We covered the semantics of this function in our analysis of Abcbot, but if we focus on lines 59-79, we can see that they’re virtually identical to the Xanthe equivalent.  

As we covered previously, this function ensures that DNS requests are being resolved by a public DNS provider - allowing the malware to make network requests across the internet. 

croncheckgo()

The croncheckgo function in both samples is responsible for achieving persistence via the cron scheduling utility common to most Linux distributions. Both samples include a TODO comment from the author, regarding adding logic to determine whether cron is running on different Linux distributions - a note to add logic presumably to deal with this. The service command is then used to start the cron daemon and cron itself, guaranteeing that any modifications made to the crontab would be honoured by the scheduling utility. 

This is fairly standard and although the wording of the comment is identical, it probably isn’t enough to be considered a link between the two samples. 

The content of the following lines does differ slightly and is better-covered by both our Abcbot article and Talos’ Xanthe article. However, we begin to notice some interesting similarities when we reach the lines responsible for the cron entry itself.

The cron entries consist of curl commands with specified user-agent strings. The purpose of this is covered in Talos’ research but if we look at the strings themselves, we can see that fczyo-cron is used in both samples, with different version numbers appended to each. Incidentally, one of the payloads downloaded by Xanthe is also named “fczyo”. 

Reuse of a unique string such as this does seem more than coincidental and suggests that the code running on servers from both the Xanthe and Abcbot campaigns expects this string to be present in the user-agent. 

checkrc()

This function handles registration of an additional persistence mechanism in both samples - via the /etc/rc.local file. Rc.local is common to most UNIX and UNIX-like systems and it allows commands specified by the user to be run at startup. This is especially useful for malware persistence and, unsurprisingly, is a technique we see often when analysing Linux malware.

When comparing the two functions we can immediately see identical commenting, as we saw in the croncheckgo function. The checkrc function has similar logic to croncheckgo; persistence is achieved by writing shell commands to the rc.local file and a unique user-agent string (rc.local/1.5) is specified. Again, we can see different version numbers appended to this string between the samples, suggesting that the author has iterated on the function itself. It seems logical to assume that the purpose of this string is to identify the method of persistence to server(s) controlled by the attacker and serve an appropriate payload.

Returning to the beginning of the function, we can see that each of the lines preceding the comments are virtually identical between both samples. The author performs an existence check for /etc/rc.local and then checks the contents using grep. A seemingly-random string is searched for in the rc.local file; this string differs between samples but is likely used to identify the campaign.

The author also uses the chattr command to remove attributes from the file (ensuring modification is possible) and re-adds them. This is a common technique used by other cloud-focused malware campaigns so can’t be relied upon solely for attribution. However, it is interesting to note that both the structure of the code, TODO comments, the wording of the logging output and several of the lines themselves are identical in this function.

iptableschecker()

Code style similarities between these two functions are immediately apparent. We can see that in both cases, the author makes use of the hash symbol to delimit distinct iptables rules and the wording of the logging statements are identical throughout.

It’s clear that the Abcbot version of this function has been simplified somewhat, perhaps indicating a difference in objective between the campaigns. If we examine the rules themselves, we can see clear connections in terms of the infrastructure used in the campaigns. For example, the following rule allowing ingress traffic from 64[.]225[.]46[.]44 in the Xanthe sample also appears in Abcbot:

Evidenced by the above, the author clearly no longer deems it necessary to add this rule to the iptables ruleset if it does not exist on a host compromised by Abcbot. This could indicate that the remote server is no longer in use or that the payloads/C2 infrastructure hosted at this IP is no longer relevant to the Abcbot campaign. It’s interesting to note that the author still checks for the existence of this rule. This could indicate a desire to check whether this host was successfully compromised by an earlier campaign, such as Xanthe. 

Similarly, the Xanthe version of this function includes rules to drop ingress traffic from ports 2375 and 2376.

These ports are associated with Docker’s API and researchers at Talos suggested that this could be a tactic to prevent the system from being reinfected by other malware abusing exposed Docker API endpoints. This functionality has been commented-out in the Abcbot version of the function although, once again, the check for the rule is still performed and logged. This could suggest a shift away from targeting misconfigured instances of Docker in the Abcbot campaign.

filerungo()

These functions have more syntactic and style differences than the functions we previously analyzed. However, if we consider the logic that the function is responsible for, we can begin to notice similarities. Firstly, let’s look at an example of lines that are virtually identical between the samples.

In the Xanthe sample, we can see that the authors configure the HugePages feature via the vm.nr_hugepages parameter. This likely facilitates cryptocurrency mining, by configuring the system to support memory pages greater than the default. In Abcbot, we can see these same lines commented-out, potentially indicating that mining is no longer an objective of this campaign. This supports the findings in our initial analysis of Abcbot, as we didn’t see any deliberate attempts to install the XMRig mining software in that particular sample.

Semantically, the two functions are similar in that they check for a process associated with a prior compromise, log whether the process is running and, if not, launch the process as necessary. The lines used to check for the existence of the process (711-712 in Xanthe and 1196-1197 in Abcbot) are virtually identical.

Miscellaneous Findings

SSH Propagation

Talos researchers noted that the method of propagation utilized by Xanthe was via enumeration of the known_hosts file, allowing the malware to spread to new hosts based on hosts the current host had previously connected to. The code responsible for this can be seen below:

We observed this same technique being used by the authors of Abcbot, in the creatively-named function fucksshlog():

Adding Malicious Users 

Our research of Abcbot showed examples of code used to add four malicious users to the compromised host, effectively creating four backdoors for the actor to utilize. The malicious usernames in question were:

• logger
• sysall
• system
• autoupdater

In the Xanthe sample, users with the same usernames are added to the system (if they do not already exist).

Similarly, both Abcbot and Xanthe search for and remove users that we assumed were from competing campaigns. However, we now believe that at least some of these users come from historical campaigns by this same actor. Both samples include code to remove a user with the username “opsecx12”. A similar string can be found displayed as ASCII art at the top of the Xanthe sample (along with an appeal for donations from other actors making use of this malware).

References to /etc/ld.so.preload

As researchers at Talos reported, perhaps one of the defining features of Xanthe was the use of an open source process hiding library named libprocesshider.so. This was used to hide the process created by the XMRig miner by inserting the path to the library into the /etc/ld.so.preload file. 

We did not see evidence of this process hiding technique in the Abcbot sample we analyzed. We did, however, see some code that references use of the technique in previous campaigns (such as Xanthe) in the function kill_miner_proc; a function responsible for clearing artifacts of miners from competing or prior campaigns.

Given that this technique was a fairly noteworthy feature of the Xanthe malware, we believe this indicates yet another link between the two families.

Conclusion

Readers with some experience in this field will have probably already considered the fact that the samples analysed in both of these campaigns are shell scripts and, therefore, incredibly easy to copy. This is, of course, common. Code reuse and even like-for-like copying is often seen between malware families and specific samples on any platform. It makes sense from a development perspective; just as code for legitimate software is reused to save development time, the same occurs with illegitimate or malicious software. 

As we’ve shown in this report, we believe that there are several links between both the Xanthe and Abcbot malware families that suggest the same threat actor is responsible. These include reuse of unique strings, mentions of shared infrastructure, stylistic choices and functionality that can be seen in both samples - most of which would be difficult and/or pointless to copy exactly. If the same threat actor is behind both campaigns, it signals a shift away from the objective of mining cryptocurrency on compromised hosts onto activities more traditionally associated with botnets - such as DDoS attacks. We suspect this won't be the last malware campaign we analyze from this actor.

Indicators of Compromise (IoCs)

References

• https://blog.talosintelligence.com/2020/12/xanthe-docker-aware-miner.html
• https://www.cadosecurity.com/the-continued-evolution-of-abcbot/
• https://s.tencent.com/research/report/1177.html

For tips and best practices when conducting forensics and incident response of mining malware attacks in Linux container and cloud environments, read the Ultimate Guide to Forensics of Mining Malware in Linux Container and Cloud Environments.