Cloud
Commando Cat: A Novel Cryptojacking Attack Abusing Docker Remote API Servers
We analyse a cryptojacking attack campaign exploiting exposed Docker remote API servers to deploy cryptocurrency miners, using Docker images from the open-source Commando project.
Save to Folio
Summary
- We analyse a cryptojacking attack campaign exploiting exposed Docker remote API servers to deploy cryptocurrency miners, using Docker images from the open-source Commando project.
- Malicious actors employ the cmd.cat/chattr image for initial access, employing techniques like chroot and volume binding to break out of the container and access the host system.
- Attack indicators can include specific User-Agent strings, plus the use of DropBear SSH on TCP port 3022, which can help in detecting the presence of the malware.
- To mitigate such attacks, it is essential to adhere to container security best practises, such as properly configuring containers and APIs and using trusted Docker images.
We observed an attack campaign abusing exposed Docker remote API servers to deploy cryptocurrency miners. This attack campaign bears the name Commando Cat due to its initial step, which involves the deployment of benign containers generated using the publicly-available Commando project (an open-source GitHub project that creates Docker images on-demand for developers). Commando, which is publicly available, is deployed using cmd.cat. The attackers used the cmd.cat/chattr docker image container that retrieves the payload from their own command-and-control (C&C) infrastructure. This attack campaign has been active since the start of 2024.
Initial access
To gain initial access, the attacker deploys a docker image named cmd.cat/chattr, a harmless docker image. Once deployed, the malicious actor creates a docker container based on this image and uses chroot to break out of the container and gain access to the host operating system. It also uses curl/wget to download the malicious binary into the host.
Attack sequence
Let's break down how the attack unfolds step by step:
1. Probing the Docker Remote API server
The sequence of events in this attack campaign begins with a ping to the Docker Remote API server, which serves as the pivotal starting point for the ensuing chain of actions.
2. Creating the container using the cmd.cat/chattr image:
Upon confirming the server's status as "OK," the attacker proceeds to instantiate a container using the cmd.cat/chattr image.
In the container creation request, we see the malicious actor employing chroot and volume binding to escape the container. Using chroot, the attacker can peek outside the container and then enter the host system using the Binds parameter, which specifies volume bindings.
The binding /:/hs mounts the host's root directory into the container's /hs directory, granting the attacker unrestricted access to the host file system. It also binds the Docker socket (/var/run/docker.sock:/var/run/docker.sock), giving the container direct access to the Docker daemon on the host, therefore allowing the attackers to control Docker as if they were on the host machine itself.
3. Image creation in absence
If the above request returns a “No such image” response, the attacker will pull the chattr docker image from the cmd.cat repository.
4. Container deployment
With the image in place, the attacker proceeds to create a Docker container, effectively executing a replica of the previous step.
While creating the docker container, the malicious actor executes a base64-encoded string:
This translates to the following shell script:
The script starts with a conditional check to determine if a file named "z" exists in the directory /usr/sbin/. If the file does not exist, the script proceeds to download and execute the malicious binary from its file server (hxxp[:]/leetdbs[.]anondns[.]net/z) and saves it to the directory /usr/sbin/, which is potentially ZiggyStarTux, an open-source IRC bot based on the Kaiten malware. This binary is packed using the UPX packer.
While doing the analysis, we found the C&C server to be down. However, the following User-Agent strings present in the binary can be used to monitor the presence of this malware in the network:
- User-Agent: HackZilla/1.67 [en] (X11; U; Linux 2.2.16-3 x64)
- User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-3 i686)
The strings present in this binary/code suggest this malware is using DropBear SSH, a relatively small SSH server and client application on TCP port 3022. This could serve as another clue for spotting the malware.
The deployed malware tries to connect its C&C server 45[.]9[.]148[.]193 on port 1219. Figure 6 depicts the initial network traffic, which shows the initial IRC communication.
The significance of this attack campaign lies in its use of Docker images to deploy cryptojacking scripts on compromised systems. This tactic allows attackers to exploit vulnerabilities in Docker configurations while evading detection by security software. As cybersecurity researchers continue to monitor this malicious actor, it's essential for organisations to strengthen their defences against Docker-related attacks.
Recommendations
To protect development environments from attacks targeting containers and hosts, we recommend implementing the following best practises:
- Containers and APIs should always be properly configured to minimise the chance of exploitative attacks. Docker has specific guidelines on how their users can strengthen their security.
- Organisations should use only official or certified images to ensure that only trusted content is run within the environment.
- Running containers should not be run with root privileges, but rather as application users instead.
- Containers should be configured so that access is granted only to trusted sources, such as the internal network.
- Organisations should adhere to recommended best practises. For example, Docker provides a comprehensive list of best practises and has built-in security features users can follow to improve the security of their cloud environments.
- Security audits should be performed at regular intervals to check for any suspicious containers and images.
- Conclusion
The Commando Cat attack campaign highlights the threat posed by the abuse of exposed Docker remote API servers. By exploiting Docker configurations and leveraging open-source tools like cmd.cat, attackers can gain initial access and deploy malicious binaries, while evading conventional security measures. The campaign's use of Docker images to propagate cryptojacking scripts underscores the importance of implementing robust container security practises.
Trend solutions
The following security solutions are recommended for safeguarding Docker servers.
- Trend Vision One™ - Container Security – for automated container image and registry scanning that helps detect threats early on
- Trend Cloud One™ – Workload Security – for protecting new and existing workloads against even unknown threats using techniques such as machine learning and virtual patching
The following protections exist to detect malicious activity and shield Trend customers from the attack discussed in this blog entry:
- 1010326 - Identified Docker Daemon Remote API Call
- 1008619 - Application – Docker
- 1010349 - Docker Daemon Remote API Calls
Trend Vision One hunting query
The following text lists potentially useful queries for threat hunting within Vision One:
eventId:100115 AND (remarks: POST_IMG_BLD_CRE OR remarks: POST_CON_CREATE) AND "cmd.cat"
MITRE ATT&CK
| Tactics | Technique | Technique ID |
|---|---|---|
| Initial Access | Exploit Public-Facing Application | T1190 |
| Execution | Deploy Container | T1610 |
| Command and Scripting Interpreter: Unix Shell | T1059.004 | |
| Privilege Escalation | Escape to Host | T1611 |
| Command and Control | Data Encoding: Standard Encoding | T1132.001 |
| Ingress Tool Transfer | T1105 |
Indicators of Compromise
The indicators of compromise for this entry can be found here.