CoinStomp Malware Family Targets Asian Cloud Service Providers

Newly Discovered Malware Employs Anti-forensics & Anti-hardening Techniques

Introduction

Researchers at Cado Security recently discovered a new malware campaign targeting Asian Cloud Service Providers (CSPs). This malware, which we’ve since named CoinStomp, is comprised of a family of shell scripts that attempt to exploit cloud compute instances hosted by these CSPs for the purpose of mining cryptocurrency. While this form of crpytojacking attack is commonplace these days, CoinStomp makes use of some interesting techniques and even references a prior campaign.

The following summarises our findings and noteworthy capabilities:

• Timestomping (manipulation of timestamps) employed as an anti-forensics measure
• Removal of system cryptographic policies 
• Command and Control communication initiated via a /dev/tcp reverse shell
• Reference to a prior cryptojacking campaign named Xanthe

Timestamp Manipulation (Timestomping)

Timestomping is the process of manipulating timestamps for files dropped or utilised during a malware attack. Generally, this technique is employed as an anti-forensics measure to confuse investigators and foil remediation efforts. Timestomping has been used by the Rocke group in prior cryptojacking attacks. However, it’s not a technique commonly seen in the wild. 

On Linux systems, timestomping is easily achieved via the touch command’s -t flag. Running touch -t and passing in a timestamp updates the specified file’s modified and access times with that timestamp.

As can be seen from line 16 in the above screenshot, this sample searches for the string “Change the mode of each FILE to MODE”, copies the file containing that string to /usr/bin/modusr and updates the modified and access timestamps for the modusr file to 22:23 20/05/2019. The grep search matches on the binary for the chmod utility, installed at /usr/bin/chmod. Line 21 demonstrates the same technique used for the chattr (change attributes) utility. 

Chmod is responsible for changing permissions of files and is typically used by malware to ensure dropped files are executable. In subsequent lines of this script, we observed the modusr binary being used in place of chmod. 

It seems likely that timestomping was employed to obfuscate usage of the chmod and chattr utilities, as forensic tools would display the copied versions of these binaries as being last accessed (executed) at the timestamp used in the touch command.

To determine how Cado handles this, we ran the timestomping commands in a test machine and acquired an image of it from within the Cado Response platform. The image below shows the modusr and chusr files within Cado and highlights the disparity between the timestamps:

Cado’s timeline view also displays the files with the correct created and modified timestamps:

Removal of System Cryptographic Policies

Linux distributions (such as RHEL) allow system-wide configuration of cryptographic policies via the use of configuration files. On an instance of RHEL, these configuration files are stored in /usr/share/crypto-policies/ and are enforced by the crypto process which interfaces with the Linux Kernel Crypto API. 

The policies themselves allow or deny usage of certain versions of cryptographic protocols depending on the user’s risk posture. For example, American Federal institutions are required to deploy computing systems that conform to FIPS 140-2. There is a FIPS-specific policy bundled with RHEL that pins versions of common cryptographic protocols (such as TLS, DH, RSA etc) and prohibits application usage of deprecated and insecure protocols.

Clearly, enforcement of cryptographic policies has a tangible effect on the deployment of malware. Additional payloads may be prevented from being downloaded and malicious applications could be prevented from running if they make use of insecure protocols - as, in the case of malware, they often do. 

For the sample in question, the developer is obviously aware of this and attempts to remove the configuration files that define system-wide cryptographic policies and even kill the crypto process itself.

This could undo attempts to harden the target machine by administrators, ensuring that the malware achieves its objectives. 

Command and Control (C2) Communication via /dev/tcp Reverse Shell

Most Linux distributions support read/write operations to a remote host via the /dev/tcp device file. Naturally, this is perfect for malware developers as it’s an easy and natively-supported method of creating a reverse shell or C2 communication channel.

As can be seen from the above, the sample in question makes use of a function named __curl() which is used to retrieve additional payloads and communicate information about the state of the target system back to the C2 server. 

Line 4 establishes a reverse shell connection via the /dev/tcp device file to a remote server at 106[.]53.115.114 over port 443 - the port number typically associated with HTTPS traffic. Searching for this IP in Shodan shows that the server is running the Python-based SimpleHTTPServer. This means that despite the use of port 443, the traffic itself is unencrypted - as it’s being transferred using HTTP. 

Regardless, the traffic is likely to pass unimpeded by firewall restrictions as outbound traffic (especially to a common port, such as 443) is generally unrestricted and considered normal. 

Throughout the script, we observed examples of this function being invoked after file existence and username checks to determine whether it was necessary to retrieve additional payloads.

Reference to Xanthe Cryptojacking Campaign

Creation of scheduled tasks via the Cron scheduler is a common malware persistence technique on Linux systems. However, rather than using Cron for persistence in this sample, two lines are added to kill the tail and masscan utilities - the former of which is used to view a live buffer of the end of a file (usually a log file) and the latter, a tool for scanning large portions of the internet.

What’s more interesting is the inclusion of an additional line consisting of a URL pointing at an anonymous DNS provider. As can be seen below, inclusion of the hash character indicates this line is commented and no command precedes the URL - meaning that the line alone wouldn’t do anything when executed by Cron.

When visiting this URL, the following is displayed:

The name Xanthe was attributed to a previous cryptojacking campaign that we analysed and one of the installation scripts used in that campaign was named fczyo. 

Unfortunately, the payload hosted at this URL wasn’t available at the time of analysis so we can’t determine whether it actually was a component of the Xanthe campaign. Given a lack of overlap in capabilities and infrastructure, along with the commenting of this line in the crontab, it seems that this campaign is distinct from Xanthe. Inclusion of this URL may well have been an attempt to foil attribution.

Analysis of Additional Payloads

A number of additional binary payloads were retrieved based on logic within the analysed script. Analysis of the most noteworthy is included in this section. Each of these payloads were persisted as system-wide systemd services, resulting in them being executed with root privileges and kept alive.

Sshno, stater and adupd

Sshno is a heavily-obfuscated 32 bit ELF binary which was retrieved from the C2 server if the logged-in username differed from “tech”. This binary was installed in /usr/bin/sshno and repeatedly attempted to create a socket connection to 195.2.93[.]34 upon execution. At the time of analysis, this connection was refused.

Stater and adupd were two additional payloads with similar functionality to sshno. The only difference being that adupd attempted to create a socket connection to a different IP address: 109.234.36[.]173. 

This looks like an attempt to establish additional backdoor or C2 communication channels in the event that the machine was not yet fully compromised.

Dhcpclient and .Jason Statham

The dhcpclient binary is a customised version of the XMRig Monero mining software, and is responsible for carrying out the mining capabilities of this malware. Rather amusingly, this binary attempts to open a file named “config.jason” in the working directory and another file named “xmrig.jason” in root’s home directory. 

It’s assumed that these are XMRig configuration files but it’s not clear whether the spelling mistakes are intentional.

Conclusion

CoinStomp demonstrates the sophistication and knowledge of attackers in the cloud security space. Employing anti-forensics techniques and weakening the target machine by removing cryptographic policies demonstrates not only a knowledge of Linux security measures, but also an understanding of the incident response process. 

Although it’s a well-documented technique, the use of the /dev/tcp device file to create a reverse shell session is also fairly advanced. C2 communication can often be noisy and easy to spot for monitoring tools but the use of port 443 helps make this traffic appear legitimate. Many cloud computing instances will be vulnerable to this type of C2 communication.

Finally, since attribution is often a key goal of malware analysts and threat intelligence personnel, the presence of strings associated with another campaign is a sophisticated way to foil such attempts.

Indicators of Compromise (IoCs)

For tips and best practices for performing investigations of mining malware attacks, check out The Ultimate Guide to Forensics of Mining Malware in Linux Container and Cloud Environments.