Skip to content
Get a Demo
    curve design on left cloud image

    CoinStomp Malware Family Targets Asian Cloud Service Providers

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


    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.

    Example of timestomping on lines 16 and 21

    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. 

    Examples of modusr 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.

    Command to remove cryptographic policy files and kill the crypto process

    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.

    __curl() function which facilitates C2 communication via /dev/tcp

    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. 

    Shodan results page for the 106[.]53.115.114 IP address

    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.

    If stater file exists, notify C2 server. Otherwise, retrieve stater payload

    If username is “tech”, notify C2 server. Otherwise, notify server and retrieve sshno payload

    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.

    Cron entry created by the analysed sample

    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.

    Strace of sshno payload

    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.

    References to config.jason and xmrig.jason in decompiled dhcpclient binary


    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)

    Filename SHA256
    eb1932fbad01525f47617913f7624d61fcdb5a6fed700d64f888f67bd740636f cb9f0dca725fa0eae8a39c7d07e62441d6ae50b776df8a9ab1cb7f86a22c75ca 17dd410fd7d42d34bd01b96c135f7890f1b3b15354a5d67f63acb70044752397
    adupd 7a065c7f0d17436809ce3a9bb6bebb74d4207f8555b8291c7ee3e3deac492a2b
    dhcpclient c1a3f32689461fb9570d4e212bba18391f6bb413bc77cb16def92d0226320e7d dbe44ec7e9d6600cc0daf4e8aac1835348d6d4929c732bb7e30c32b3563362e6
    sshno 57c2fef3dd66a3756e85df53ad825d7bf6ff1ee38504323b756b4fc5d47023c3
    stater 3420588e7231167052775e68bab84384f449e08f1dd9ec9ba29f8437b5f86334

    IP Addresses

    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.

    More from the blog

    View All Posts