Dero miner zombies biting through Docker APIs to build a cryptojacking horde

A Dero cryptomining campaign is actively targeting containerized Linux environments by exploiting insecurely exposed Docker APIs, primarily on port 2375. The attackers utilize two custom Golang malware samples: nginx and cloud. The nginx malware, masquerading as a legitimate web server, is responsible for propagation and persistence, scanning networks for exposed Docker APIs, and creating malicious containers on vulnerable hosts. It installs necessary dependencies and transfers both the nginx and cloud binaries into these containers, ensuring persistence by modifying bash aliases. The cloud malware is a Dero cryptocurrency miner that exploits the resources of compromised containers, using hardcoded, encrypted configurations. This campaign operates autonomously, turning infected containers into propagators, creating a self-spreading cryptomining botnet. Previous campaigns with the same wallet and node addresses have targeted Kubernetes clusters. Mitigation strategies include avoiding exposure of Docker APIs to the internet, implementing robust authentication, and continuously monitoring for unusual activities. Indicators of compromise include specific file hashes, paths, and node addresses, with a potential for false positives due to the malware's masquerading techniques.

MITRE ATT&CK Technique IDs: T1190

MITRE ATT&CK Techniques Inferred

• T1190: Exploit Public-Facing Application: The attack begins by exploiting Docker APIs that are exposed to the internet, typically on port 2375. This is a classic example of exploiting public-facing applications, where the attacker takes advantage of a service that is improperly configured and accessible from the internet without adequate security controls. The article mentions, "The campaign exploits Docker APIs exposed to the internet, typically on port 2375." This aligns with MITRE ATT&CK's technique of Exploit Public-Facing Application (T1190).

• T1036: Masquerading: Once access is gained through the exposed Docker API, the attacker deploys the nginx binary, which is responsible for propagation and persistence. This binary masquerades as the legitimate nginx web server. The use of masquerading to make the malware appear as a legitimate service is a tactic to evade detection, described in the article as, "It masquerades as the legitimate nginx web server." This aligns with the MITRE ATT&CK technique of Masquerading (T1036).

• T1046: Network Service Discovery: The nginx malware is responsible for scanning random IPv4 /16 subnets for other exposed Docker APIs using masscan. This is an example of Network Service Scanning, as the malware actively scans for vulnerable services to exploit. The article states, "Its functions include:...Scanning random IPv4 /16 subnets for exposed Docker APIs (port 2375) using masscan." This corresponds to the MITRE ATT&CK technique of Network Service Scanning (T1046).

• T1543: Create or Modify System Process: The attacker creates new malicious containers on vulnerable remote hosts after identifying them. This involves the creation of a new execution environment to run malicious code. The article notes, "Creating new malicious containers (based on ubuntu:18.04) on vulnerable remote hosts." This is an example of the MITRE ATT&CK technique of Create or Modify System Process (T1543).

• T1547: Boot or Logon Autostart Execution: To ensure persistence within the compromised containers, the attacker adds the nginx binary to /root/.bash_aliases. This is a form of boot or logon autostart execution, as it ensures the malware is executed whenever a bash session is started. The article describes, "Establishing persistence by adding the nginx binary to /root/.bash_aliases within compromised containers." This aligns with the MITRE ATT&CK technique of Boot or Logon Autostart Execution (T1547).

• T1012: Query Registry: The nginx malware is also tasked with infecting existing containers that have not been previously infected, based on the presence of a specific file (/usr/bin/version.dat). This indicates that the malware checks for the presence of a specific artifact to determine whether a system has already been compromised, which is an example of the MITRE ATT&CK technique of Query Registry (T1012) adapted to file checks in Linux.

• T1496: Resource Hijacking: Finally, the cloud binary is deployed to mine cryptocurrency using the compromised system's resources. This is a classic example of Resource Hijacking, where the attacker's goal is to leverage the victim's resources for cryptocurrency mining. The article states, "This is the Dero cryptocurrency miner, based on the open-source DeroHE CLI miner." This corresponds to the MITRE ATT&CK technique of Resource Hijacking (T1496).
  
  

How BlueRock Helps

This security issue gives an attacker the ability to exploit insecurely exposed Docker APIs, creating a self-spreading cryptomining botnet by deploying malware that mines cryptocurrency and seeks out new vulnerable hosts. The following protection guardrails can further prevent the following steps an attacker can take: Initially, when an attacker discovers an exposed Docker API and attempts to create a malicious container, Container Capability Control helps prevent this by enforcing specified capabilities, limiting the potential harm if the attacker tries to grant excessive privileges like SYS_ADMIN to the new container, thereby restricting its ability to compromise the host or other containers. Should the attacker succeed in creating a container and then attempts to deploy and execute their custom nginx and cloud malware binaries, Container Drift Protection (Binaries & Scripts) steps in to prevent the execution of these unauthorized binaries, as they were not part of the original, approved container image; for example, it would block the nginx binary from running after being dropped into /usr/bin/ within the compromised container. If the cloud cryptomining malware were to execute, its attempts to connect to external Dero mining pool addresses, such as d.windowsupdatesupport[.]link, would be thwarted by Process Socket Deny, which blocks unauthorized network connections from specific processes not on an allowlist, rendering the miner ineffective. To propagate, the nginx malware scans for other vulnerable Docker APIs using tools like masscan; Process Exec Deny can prevent the execution of masscan if it's explicitly added to a deny list, stopping the reconnaissance phase. Furthermore, if the malware attempts to spread within the same host by entering other containers, for instance, using docker exec to check for a marker file like /usr/bin/version.dat, Namespace Execution Guard can block such unauthorized namespace manipulation if the initiating nginx process is not a recognized service, thus preventing lateral movement between containers on the same host. In Kubernetes environments where attackers might exploit anonymous API access to deploy pods from malicious images like pauseyyf/pause:latest, Cluster Drift Protection is crucial as it prevents such unauthorized pod deployments by enforcing policies that require authenticated and authorized entities for workload creation, thereby stopping the attack before the malicious container even starts.