Cloud
Exposed Docker Server Abused to Drop Cryptominer, DDoS Bot
Malicious actors continue to target environments running Docker containers. We recently encountered an attack that drops both a malicious cryptocurrency miner and a DDoS bot on a Docker container built using Alpine Linux as its base image.
Save to Folio
Malicious actors continue to target environments running Docker containers. We recently encountered an attack that drops both a malicious cryptocurrency miner and a distributed denial-of-service (DDoS) bot on a Docker container built using Alpine Linux as its base image. A similar attack was also reported by Trend Micro in May; in that previous attack, threat actors created a malicious Alpine Linux container to also host a malicious cryptocurrency miner and a DDoS bot.
Infection chain analysis
In this recent attack, the infection starts with threat actors connecting to an exposed Docker server and then creating and running a Docker container. On the Docker container, the command shown in Figure 1 is executed.
The XMI download file (detected by Trend Micro as Trojan.Linux.MALXMR.USNELH820) is a Bash script, shown in Figure 2, that moves laterally to other hosts in the same container network using information from /.ssh/known_hosts.
The commands shown in Figure 3 download and execute the XMI Bash script and a Python script named “d.py” (Trojan.Python.MALXMR.D).
The XMI shell script extensively uses Base64 encoding to avoid detection. Decoding the encoded string shown in Figure 3 yields the command shown in Figure 4, which downloads and executes d.py.
It is also worth noting that the shell script contains commented-out code, shown in Figure 5, that seems to be used for propagating the malware via SSH brute-forcing. It is likely that the actors behind this attack used to target or are also targeting SSH servers.
The attack uses multiple techniques to establish persistence. Aside from setting up cron jobs, as shown in Figure 6, it also creates its own service for automatic payload execution.
The portion that creates the service is also Base64-encoded. Its decoded form, shown in Figure 7, is placed in the the /etc/init.d directory.
We detect the cryptocurrency-mining payload, whose download script is shown in Figure 8, as Coinminer.Linux.MALXMR.UWELD. Interestingly, the cryptocurrency wallet used by the threat actors is the same one used in campaigns that exploited vulnerabilities such as CVE-2019-3396, a Confluence vulnerability, and CVE-2017-5638, an Apache Struts vulnerability. According to a report by Tencent Security, the 8220 mining group, a criminal gang based in China, is behind the campaign that exploited CVE-2017-5638.
To check whether the payload has been successfully dropped, the malware uses md5sum, a program that calculates and verifies 128-bit MD5 hashes. This verification method is similar to the one used by the Kinsing malware, which was used by the H2Miner cryptocurrency-mining botnet that targeted cloud servers in China.
In addition, the attack drops another payload in the form of a DDoS bot (Backdoor.Linux.KAITEN.AMV), as shown in Figure 9.
This DDoS bot, some of whose backdoor commands are shown in Figure 10, is based on IRC (Internet Relay Chat) and appears to be a variant of Kaiten (aka Tsunami). Its command-and-control (C&C) servers are c4k[.]xpl[.]pwndns[.]pw, 104[.]244[.]75[.]25, and 107[.]189[.]11[.]170.
As previously mentioned, the attack also drops d.py, the Python script that we detect as Trojan.Python.MALXMR.D. We found that it performs the same routine as Trojan.Linux.MALXMR.USNELH820, that is, it establishes persistence and drops cryptocurrency miner and DDoS bot payloads. A code snippet of d.py is shown in Figure 11.
The infection chain of the attack is illustrated in Figure 12.
Security recommendations
As Docker containers become increasingly targeted by malicious actors, development teams should adopt a risk-based security approach to reduce containers’ exposure to threats. They can start by not leaving their Docker daemon ports exposed online. They should also use only official Docker images to ward off threats such as the ones discussed in this post. The following best practices could further mitigate risks to their containers:
- Deploy an application firewall to help secure containers and catch threats before they can enter the environment.
- Minimize the use of third-party software and use verifiable software to ensure malware is not introduced to the container environment.
- Implement the principle of least privilege. Container images should be signed and authenticated. Network connections and access to critical components (such as the daemon service that helps run containers) should be restricted.
- Employ automated runtime and image scanning to gain further visibility into a container’s processes. Application control and integrity monitoring help catch anomalous modifications on servers, files, and system areas.
Enterprises can also rely on the following cloud security solutions to protect their Docker containers:
- Trend Micro Hybrid Cloud Security: Provides automated security and protects physical, virtual, and cloud workloads
- Trend Micro Cloud One™ – Container Security: Performs automated container image and registry scanning
- Trend Micro Deep Security™ Software and Trend Micro Deep Security Smart Check – Container Image Scanning: Scan container images to detect malware and vulnerabilities earlier in the development life cycle
With additional analysis from Arianne Grace Dela Cruz.
Indicators of compromise (IOCs)
File name |
SHA-256 |
Detection name |
d.py |
29316f604f3c0994e8733ea43da8e0e81a559160f5c502fecbb15a71491faf64 |
|
i686 |
35e45d556443c8bf4498d8968ab2a79e751fc2d359bf9f6b4dfd86d417f17cfb |
|
x32b |
9b8280f5ce25f1db676db6e79c60c07e61996b2b68efa6d53e017f34cbf9a872 |
|
x64b |
855557e415b485cedb9dc2c6f96d524143108aff2f84497528a8fcddf2dc86a2 |
|
x86_64 |
fdc7920b09290b8dedc84c82883b7a1105c2fbad75e42aea4dc165de8e1796e3 |
|
xmi |
51654c52e574fd4ebda83c107bedeb0965d34581d4fc095bbb063ecefef08221 |
URL
- 205[.]185[.]113[.]151