Threat Alert: An Attack Against a Docker API Leads To Hidden Cryptominers

Following an attack against a misconfigured Docker API port, the research team at Aqua Security performed an in-depth examination of the Docker Hub account from which the image was pulled. The examination was done by dynamically scanning for hidden threats in the container images hosted in that specific Docker Hub account (ubuntuz) and comparing them to scans done on other Docker Hub accounts. As a result of this process, we discovered an infrastructure of 23 container images stored in Docker Hub.

These container images had a Potentially Unwanted Application (PUA) hidden either within their image layers or downloaded into their instantiated containers during runtime. All these images have amassed over 330,000 downloads (pulls).

Our investigation showed the images were designed to evade detection by static security tools. To accomplish this, many of them are downloading malicious elements during runtime from GitHub (a code repository allowed by many organizations). The images then download and run a cryptocurrency miner during runtime – to avoid most container security tools.

Dynamic Image Scanning Exposed Hidden Threats

As part of our screening, we analyzed container images hosted in Docker Hub. Using our Dynamic Threat Analysis (DTA) scanner, we dynamically analyzed thousands of Docker Hub container images and classified any similarities into groups. One of these groups immediately drew our attention, as we found a strong connection between 23 container images hosted in Docker Hub (a complete list of the images can be found below). These images are hosted by seven different Docker Hub community members. A follow-up investigation showed a connection between these container images and 15 different GitHub accounts, which seemed to be dedicated solely to this infrastructure.

The modus operandi of these images is to download malicious elements from a remote source during runtime. Unfortunately, most image scanners will classify these images as benign since static detection tools that look for vulnerabilities and malware signatures don’t run these commands. Another layer of detection/prevention security used by many organizations can also be deployed at the network level. However, even if you had a solution to detect suspicious network communication (e.g., firewall or IDS/IPS) the adversaries could avoid this by using GitHub as their malicious code source, and since most organizations allow downloads from GitHub, the malicious code could still be downloaded.

Using DTA, we spun up the container and executed the entry point commands in a secure sandbox environment. As a result of these commands, various files were dropped and executed during runtime. Some of these files contained malicious markers. Network traffic was also recorded, and in most cases, communications with cryptocurrency mining pools were detected. Finally, DTA highlighted the presence of a Potentially Unwanted Application (PUA) which was designed to mine cryptocurrency by hijacking some of the host resources. Consequently, the DTA scanner classified all 23 images as malicious.

Below is a screenshot of Aqua’s Dynamic Threat Analysis Scanner, presenting all the scans that were done.

We then traced these accounts for additional indications that the images were designed to mine cryptocurrency. Unfortunately, in neither Docker Hub nor GitHub, did the author provide any references in the descriptions or readme files that these were crypto miners. This means someone could pull and run one of these images and unknowingly launch a mining process. Alternatively, these images and code repositories could potentially serve as the second stage of an attack after a machine was exploited, as happened with Kinsing Malware, which we reported earlier this year.

Distinguishing Between the Container Images

Based on the attack vectors, we can classify these 23 images roughly into two main groups:

A. Downloading PUA elements from remote sources: The first group includes 21 images. These attacks come in many flavors, but essentially, at the entry point command, the adversary is downloading one to two shell scripts (downloading malicious elements and running the entire process), an ELF file (serves as the main payload and is designed to mine cryptocurrency) and a configuration file (containing all the parameters which are needed to execute a cryptocurrency mining process).

B. Opening a Backdoor: The second group includes the two remaining images, which already contain the PUA elements, as they are built into one of the image layers. Here, the attacker is seeking to remotely execute the mining process. Standard static scanning tools should detect these images. It should be noted, the adversary is risking failure with this attack vector, since the targets’ security tools (such as a firewall) may block network communication traffic between the target and the attacker’s C2 server.

Group A: Images Downloading PUA From Remote Source

As mentioned above, in these attacks the container is downloading shell scripts, an ELF file (crypto miner), and the configuration file.

How the Attack is Initiated

There are several flavors to this attack, but in all the attacks the container is initiated with a command aimed at downloading a shell file from a GitHub account. 15 accounts take a role in this attack (a detailed list can be found below). However, one GitHub account dzmltzack is common in all these attacks, as the other GitHub accounts downloaded some or all the elements from this account. Below are a couple of examples of such commands:

Another example:

Downloading the payload from GitHub is a very clever way to evade detection by security tools. It is unlikely that an organization or individual will block any communication with GitHub, which greatly increases the attackers’ chances of success.

Below is a screenshot taken from Aqua Dynamic Threat Analysis scanner, displaying the findings on a specific image (dzoask2/lokmo).

The Payload

In all these images, the payload contains an ELF file that is designed to mine cryptocurrency, a JSON file that contains the configuration and a shell script that executes the commands. In some attacks, there are mid-stages, when some shell files download and run one or more of the files mentioned above. In several cases, all the files are downloaded directly from the dzmltzack GitHub account, in other cases, there are shell scripts downloaded from other GitHub accounts and then these shells download the ELF file and the configuration file from the dzmltzack GitHub account.

In 11 out of 23 cases, the entry point command is downloading the script iab.sh directly from dzmltzack Git. Then, the ELF file (XM) is downloaded, which is a Potentially Unwanted Application, and another shell script (cmd.sh) is also downloaded and executed. Here is a screenshot of the IAB.sh shell script:

The second shell script (cmd.sh) downloads a configuration file that contains the parameters needed to initiate the cryptocurrency mining process (i.e., mining pool, user, and password). Finally, the mining command is executed. Here is the cmd.sh shell script.

A Configuration File

A configuration file contains all the parameters needed to mine the cryptocurrency. Some of the configuration files mine TurtleCoin while others mine Worktip (WTIP) coin. Here is a screenshot of the arqt JSON configuration file:

Potentially Unwanted Application (PUA)

Two ELF files were identified. The ELF file XM was downloaded by 17 images and the ELF file ZXM was downloaded by four images. XM is a Cryptocurrency miner, identified by Virus Total after we submitted it for analysis:

ZXM is also a Cryptocurrency miner, also identified by Virus Total:

Group B: Opening A Backdoor

The image already contains the PUA elements, as they are built into one of the image layers. From there, the attacker is seeking to remotely execute the mining process.

How the Attack is Initiated

Instantiate the container with the following entry point:

This shell script was designed to execute sshd -D command, which is an OpenSSH Daemon, aimed to listen to connections from clients and allow ssh communication. Probably serving as a backdoor for the attacker, allowing them to execute the attack on the target machine. Here is a screenshot of the entrypoint.sh shell script.

Potentially Unwanted Application (PUA)

The affected container image comes with a built-in library xmr-node-proxy which contains the PUA. This library contains a few files that strongly suggest the PUA is intended to mine cryptocurrency, specifically Monero coin. Here is the dockerfile of the container image dzmlt/letmakeit.

An Attack Against Aqua’s Honeypot

One of these images ubuntuz/jessy:latest actually attacked Aqua’s honeypot 42 times between March 17th, 2020, and June 3rd, 2020.

This latest incident represents another hacking campaign that included malicious activity revealed by Aqua’s honeypot. That attack targeted misconfigured open Docker Daemon API ports. As with this latest incident, we recorded and analyzed attack vectors as well as the adversaries’ Modus Operandi, Tactics, Techniques, and Procedures (TTPs) to continuously improve our defenses.

How the Attack is Initiated

The container was initiated with a command aimed to download a shell file from a remote resource:

The Payload

The payload included a shell script designed to download an ELF file (a PUA), running a mining command with hardcoded parameters. In addition, it also sends the host’s IP address to IPLogger (IP address tracker) which is used by the adversary to monitor the infected host machines.Here is the CMD at the entrypoint.

Potentially Unwanted Application (PUA)

EZ, the ELF file, is a Cryptocurrency miner, identified by Virus Total:

Connecting the Dots & Finding Dz Memory Leak Team (DzMLT)

All these Docker Hub images download one or more files from the same GitHub account (dzmltzack), so we decided to look for similar connections within GitHub. We found 14 additional GitHub accounts that seem to be connected to this infrastructure. Most of these accounts (12 out of 14) have a single project that contains a single file (dockerfile) set to download an ELF file (the PUA), one to two shell scripts and a configuration file from the dzmltzack GitHub account.

The account dzmltzack was created on 20/02/2019. As can be seen in the figure below, there were two periods during which accounts were created. The first period started a month after the dzmltzack account was created, with a new account created, on average, every three days. The second period started two months after the first period ended, then an account was created, on average, every three days.

We identified a Youtube channel of DzMLT which stands for DZ Memory Leak Team. DZ probably stands for the ISO 3166-2 country abbreviation of Algeria. Furthermore, threat intelligence evidence strongly links this infrastructure to this Algeria group.

Summary

The cryptocurrency mining infrastructure we uncovered includes dozens of Docker Hub and GitHub accounts which were built solely to host these suspect container images. The infrastructure allows the adversaries to download these images from remote sources, which are considered safe, and run them on the host. On top of that, the images are downloading files during runtime, which further reduces the chances that they will be marked as malicious by most security tools. Although crypto mining software is not necessarily malicious by nature, the author of the images is not declaring that they are crypto software. One of the images was used to attack a misconfigured Docker API – this MO is clearly designed to avoid detection, which is malicious behavior.

After all our research, one question remained: Cumulatively, there were over 330K image pulls, so how did the attackers persuade thousands of people to pull these images directly from Docker Hub? One idea was that this group targeted misconfigured open Docker Daemon API ports. Another possibility was that malware was used to pull and run these images, which is plausible since we know the DzMLT group offers free hacking tools – which were reported as infected with Malware. But the truth is, we may never know the entire story.

We believe that DevSecOps teams must also “up their game” and be aware of the hidden threats lurking in the cloud and develop a security strategy to mitigate risks. Here’s a list of steps we’d consider making:

1. Identify all cloud resources and group them by some logical structure.
2. Review authorization and authentication policies, basic security policies, and adjust them according to the principle of least privilege.
3. Scan the images that you use, making sure you are familiar with them and their use, using minimal privileges such as avoiding root user and privileged mode. Use a vulnerability scanner such as Trivy (open source).
4. Dynamically scan images using Aqua DTA (a dynamic threat analysis tool) to uncover both suspicious/malicious processes and network communication during simulated runtime conditions using a secure sandbox.
5. Investigate logs, mostly around user actions, look for any anomalous actions.
6. Form a security strategy where you can enforce your policies with ease, consider using cloud security tools that will widen your scope and reach within your cloud resources.