Kiss-a-Dog Discovered Utilizing a 20-Year-Old Process Hider

Introduction

Researchers at Crowdstrike recently discovered a novel cryptojacking campaign, targeting Docker and Kubernetes, that they named Kiss-a-Dog. While triaging honeypot data, we uncovered a newer variant of this campaign. Interestingly, the campaign we observed was leveraged at our Redis honeypot - suggesting a broadening of scope from Docker and Kubernetes.

Despite many of the TTPs and overall objective remaining the same, this campaign employed a new method of initial access and deployed some additional payloads that weren’t reported by Crowdstrike. These included a (rather old) open source process hider and a version of Tsunami, a Linux backdoor that’s long been a favourite of cryptojacking groups.

Initial Access

For initial access, this updated version of the Kiss-a-Dog campaign utilised a common Redis exploitation attack pattern to download and execute an initialisation shell script on the compromised node. Essentially, this attack involves writing the contents of a cron job to the data store, using the CONFIG SET DIR command to set the working directory to one of the cron directories and then saving the database. When the cron scheduler runs, the database file is read and interpreted as a cron job, resulting in arbitrary code execution. 

In this example, Redis was exploited to download and execute a second stage payload (b.sh), hosted at the kiss[.]a-dog[.]top domain. In the first command written to Redis, the domain is encoded in base64 and then decoded on the fly when the job executes. The malware also attempts to use Python’s urllib2 library in a separate command as a failover.

Examples of cron commands used to retrieve additional payloads

Actions on Objective

With the b.sh payload retrieved and executed on the target system, the malware follows an attack pattern largely consistent with Crowdstrike’s original report. We won’t delve too deeply into the payloads that Crowdstrike described, instead we’ll focus on a small shell script with a relatively low detection rate (ai.sh) that differentiates this campaign.

ai.sh

Contents of ai.sh

The script begins with a log statement and some variable assignment, including the decoding of the following payload URL:

http://kiss[.]a-dog[.]top/b2f628/m/xm.jpg

As we can see from lines 24 and 27 in ai.sh, the resource in this URL is a tarball which appears to contain another executable (start).

Extracted contents of xm.jpg tarball

“start”

The “start” executable, referenced by the ai.sh script can be seen amongst the tarball contents. It’s another simple shell script, used to determine the CPU architecture of the target system and rename one of two ELF binaries compiled for each architecture.

Contents of “start”

Unsurprisingly, given the new name for the aarch64 and x86_64 binaries, these are versions of XMRig compiled for each of the two architectures. More interestingly, the script executes something named “hide”, as can be seen on line 9.

XHide Process Hider

Searching for this executable on VirusTotal revealed a number of vendors detecting it as XHide, an open source process hider that appears to have been in circulation since 2002(!). There have been reports of this process hider being utilised by cryptojacking groups in the past. However, it’s not a common occurrence.

Confusingly, a version of the XHide source code (hide.c) is delivered alongside the compiled binary. Initially, we thought this would be used to compile the hider after delivery, as Crowdstrike had observed this technique being used in their original report. However, It doesn’t appear to be used by the malware at any point.

To add to the confusion, the “start” script above invokes the hider without any arguments, printing the help text for the executable and not actually hiding any processes.

Invoking XHide without any arguments

Further along the execution chain, we discover a script named “mining”, which was included in the xm.jpg tarball.

On lines 7 and 9, we can see the XHide process hider being used to disguise the miner process created by either the ARM64 or x86_64 versions of XMRig. The developers have chosen to masquerade as Sendmail, a Linux email transfer agent. The PID of this process is then saved to the file ra.pid, for later use by the malware.

Testing XHide

Since it’s not every day you encounter a 20 year old process hider, we decided to test whether this approach does actually work. We transferred the payloads used by this campaign to an analysis machine running Ubuntu 20.04, and executed the script above. 

After running ps auxxx, we noticed a process with the name “sendmail: accepting connections” with 99.6% CPU usage. This was then confirmed to be the XMRig executable.

Fake “sendmail: accepting connections” process in ps aux output

This showed that XHide does indeed still function as intended, and is an effective tool for masquerading malicious processes.

Open Source Process Hiders: a quick note

Cryptojacking groups have utilised open source process hiders and rootkits for quite some time. 

We previously reported on TeamTNT’s use of Diamorphine, in their campaign to steal AWS credentials. Diamorphine is an open source LKM rootkit for Linux kernel versions 2.6 and newer. It can be used to hide or unhide a specific process and elevate privileges. This version of the Kiss-a-Dog campaign also makes use of Diamorphine, compiling it from a base64-encoded tarball containing the source code in a later script.

Extracting and compiling diamorphine

Another popular choice is libprocesshider, which uses the LD Preload dynamic linker hijacking technique to execute the process hiding code whenever a new process is executed. This was also utilised by Kiss-a-Dog, as originally reported by Crowdstrike.

Finally, if you’ve followed our research for a while, you’ll likely have seen another process hiding technique utilised by cryptojacking groups. Back in June, we reported on a campaign by WatchDog who targeted our honeypot infrastructure. When analysing payloads delivered during this campaign, we encountered a very rudimentary custom process hider deployed to hide malicious scanning processes executed by the malware.

Custom shell script process hider utilised by WatchDog

Conclusion

Clearly, hiding processes is a key goal of cloud cryptojacking groups. Mining cryptocurrency is incredibly resource intensive and can result in the compromised system grinding to a halt. Naturally, when investigating slow-downs like this, the first step an administrator will take is to list the CPU usage of running processes and look for anything with high utilisation. Masquerading as legitimate processes may help the attackers evade detection, even if only momentarily. 

The developers behind this new version of Kiss-a-Dog obviously value the ability to hide the mining process, as they’ve utilised three individual open source process hiders. This gives them redundancy, should a method fail. Once again, the use of a 20 year old process hider demonstrates the resourcefulness of attackers in the cloud malware landscape, and we expect to see the Kiss-a-Dog campaign continue to evolve over time.

Indicators of Compromise