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

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.

• 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).

F1: Initial compromise of a host via an exposed Docker API, deployment of malware, and commencement of cryptomining.

• Attacker discovers a Docker API endpoint exposed to the internet, typically on port 2375. (Cited from: "exploiting insecurely published Docker APIs", "Docker APIs exposed to the internet, typically on port 2375")
• The attacker gains access to the Docker daemon via the exposed API and creates a new container, often using an ubuntu:18.04 base image. (Cited from: "Upon gaining access, the threat actor deploys two UPX-packed Golang binaries", "Creating new malicious containers (based on ubuntu:18.04) on vulnerable remote hosts")
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces specified capabilities for containers, potentially limiting the harm of a maliciously created container if the attacker attempts to grant it excessive privileges during creation through the compromised API.
• Two UPX-packed Golang malware binaries, nginx (Trojan.Linux.Agent.gen) and cloud (RiskTool.Linux.Miner.gen), are deployed into the compromised container. (Cited from: "deploys two UPX-packed Golang binaries: nginx (Trojan.Linux.Agent.gen) ... cloud (RiskTool.Linux.Miner.gen)")
• The nginx malware, which masquerades as a legitimate nginx web server, is executed and ensures the cloud miner is also running. (Cited from: "nginx (Trojan.Linux.Agent.gen): This malware is responsible for propagation and persistence. It masquerades as the legitimate nginx web server.", "Maintaining the presence of the cloud miner.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because nginx and cloud are new executable binaries not part of the original container image. If this software ran inside a container, then this mechanism applies because it prevents the execution of these new, unauthorized binaries.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed paths. If the paths /usr/bin/nginx and /usr/bin/cloud (where malware is placed) are not in the pre-defined allowlist for the container, their execution would be blocked.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it prevents unauthorized new processes like nginx and cloud from starting within the container environment, as these malware instances are not legitimate, authorized processes for the workload.
  • BR-67: Container Root User Control - This mechanism is applicable if the nginx or cloud malware attempts to run as the root user within the container (and is not the init process/PID 1). The persistence method in /root/.bash_aliases suggests a root context.
  • BR-90: Process Exec Deny - This mechanism is applicable if policies were configured to deny execution of processes named nginx or cloud (if these names were known to be malicious and added to a deny list). The default deny list (nc, wget, curl) would not catch these specific names.
• The cloud Dero cryptocurrency miner utilizes the compromised container's resources for mining, using hardcoded, encrypted Dero wallet and node addresses. (Cited from: "cloud (RiskTool.Linux.Miner.gen): This is the Dero cryptocurrency miner... executed by the nginx malware to utilize the compromised container's resources for mining Dero.", "miner contains hardcoded, encrypted configuration details, including a Dero wallet address and DeroHE node addresses.")
  • BR-87: Process Socket Deny - This mechanism is applicable because the cloud miner needs to connect to DeroHE node addresses. If the cloud process is not on the allowlist for initiating network connections, its communication with mining pools/nodes would be blocked, rendering the miner ineffective. This constitutes an unauthorized network activity by a specific process.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies because it would prevent the execution of the cloud miner if it's a new binary not part of the original image.
  • BR-88: Process Path Exec Allow - This mechanism would apply if the path to the cloud miner is not in the allowed execution paths for the container.
  • BR-82: Process Runtime Execution Guardrails - This mechanism would apply by preventing the unauthorized cloud miner process from starting.
  • BR-67: Container Root User Control - This mechanism would apply if the cloud miner runs as root within the container (and is not PID 1).
• The nginx malware establishes persistence within the container by adding itself to /root/.bash_aliases. (Cited from: "Establishing persistence by adding the nginx binary to /root/.bash_aliases within compromised containers.")
  • BR-91: Sensitive File Access - This mechanism is applicable because /root/.bash_aliases is a sensitive configuration file that controls command execution at shell startup. Modifying it is an attempt to alter execution flow, and BR-91 can monitor and block unauthorized modifications to such designated sensitive files.
• The nginx malware logs its activities to /var/log/nginx.log. (Cited from: "Logging its activities to /var/log/nginx.log.")

​

F2: Automated propagation of the malware from an infected container to new vulnerable Docker hosts.

• The nginx malware running in an infected container uses masscan to scan random IPv4 /16 subnets for other Docker APIs exposed on port 2375. (Cited from: "Scanning random IPv4 /16 subnets for exposed Docker APIs (port 2375) using masscan.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside a container, then this mechanism applies by preventing the execution of masscan if it's a new binary introduced by nginx and not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism applies by blocking the execution of masscan if its path is not on the container's allowed execution path list.
  • BR-82: Process Runtime Execution Guardrails - This mechanism applies by preventing masscan (an unauthorized process for network scanning) from starting if initiated by nginx.
  • BR-87: Process Socket Deny - This mechanism applies by blocking the network connections masscan attempts to make for scanning, if masscan is not on the process allowlist for network activity.
  • BR-90: Process Exec Deny - This mechanism is applicable if masscan or its path suffix were added to a deny list. While not on the default list, it's a common tool that could be denied.
• Upon discovering a new vulnerable host with an exposed Docker API, nginx connects to it.
  • BR-87: Process Socket Deny - This mechanism is applicable because the nginx malware is initiating an outgoing network connection to the newly discovered vulnerable host. If nginx is not on the allowlist for initiating network connections, this attempt would be blocked.
• A new malicious container, based on ubuntu:18.04, is created on the newly identified vulnerable remote host. (Cited from: "Creating new malicious containers (based on ubuntu:18.04) on vulnerable remote hosts.")
  • BR-47: Container Capability Control - On the remote host, this mechanism applies by potentially limiting the capabilities of the newly created malicious container if excessive privileges are requested.
• The nginx malware installs necessary dependencies, such as masscan and docker.io, within the new container on the remote host. (Cited from: "Installing dependencies (masscan, docker.io) ... into the newly created containers.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - If this software ran inside the new remote container, then this mechanism applies by preventing the execution of the newly installed masscan and docker.io binaries, as they were not part of that container's original image at its load time.
  • BR-88: Process Path Exec Allow - Within the new remote container, this mechanism would apply to block execution of masscan and docker.io if their installation paths are not on the allowlist.
  • BR-82: Process Runtime Execution Guardrails - Within the new remote container, this mechanism would apply to prevent these newly installed and likely unauthorized processes (masscan, docker.io) from starting.
• Copies of the nginx and cloud binaries are transferred into the newly created container on the remote host. (Cited from: "transferring the nginx and cloud binaries into the newly created containers.")
• The nginx malware is executed in the new remote container, which in turn starts the cloud miner and begins scanning for more victims, effectively making the new victim a propagator. (Cited from: "The attack chain is automated: an infected container scans for vulnerable Docker APIs, compromises new hosts, creates malicious containers... turning the new victims into propagators themselves.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - On the new remote container, this mechanism applies to block execution of the transferred nginx and cloud binaries as they are new to this container instance.
  • BR-88: Process Path Exec Allow - On the new remote container, this applies if paths of nginx/cloud are not allowed.
  • BR-82: Process Runtime Execution Guardrails - On the new remote container, this applies to block these unauthorized processes.
  • BR-67: Container Root User Control - On the new remote container, this applies if nginx/cloud run as root.
  • BR-87: Process Socket Deny - On the new remote container, this applies to block network scanning/mining connections by nginx/cloud.
• Persistence for nginx is established in the new remote container via /root/.bash_aliases. (Cited from: "Establishing persistence by adding the nginx binary to /root/.bash_aliases within compromised containers.")
  • BR-91: Sensitive File Access - On the new remote container, this mechanism applies to protect /root/.bash_aliases from unauthorized modification.

​

F3: Intra-host infection: the nginx malware spreads to other existing containers on an already compromised host.

• The nginx malware on a compromised host identifies other existing ubuntu:18.04 containers running on the same host. (Cited from: "Identifying and infecting existing ubuntu:18.04 containers on the compromised host")
  • BR-47: Container Capability Control - If the initial container housing nginx lacks the necessary capabilities (e.g., to mount/access the Docker socket or use host IPC), it would be prevented from discovering or interacting with other containers via the Docker daemon.
  • BR-87: Process Socket Deny - If nginx needs to communicate with the Docker socket over a Unix domain socket to list containers, and nginx's process is denied socket access, this could prevent the discovery.
• For each identified ubuntu:18.04 container, nginx checks for the presence of /usr/bin/version.dat to determine if it has been previously infected. (Cited from: "checked via the presence of /usr/bin/version.dat")
  • BR-49: Namespace Execution Guard - If nginx uses a command like docker exec to enter the target container's namespace to check for the file, BR-49 could apply. docker exec involves setns syscalls. If the process initiating this (e.g., docker CLI if called by nginx) is not a recognized service, its attempt to manipulate namespaces could be blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - If nginx executes a docker CLI binary from within its container to perform docker exec, and this docker binary was not part of the original image of nginx's container, its execution would be blocked by BR-54.
• If an existing ubuntu:18.04 container is found not to be infected (i.e., /usr/bin/version.dat is absent), the nginx malware proceeds to infect it. (Cited from: "infecting existing ubuntu:18.04 containers on the compromised host that have not been previously infected")
• The infection process involves transferring the nginx and cloud binaries into the uninfected existing container and executing nginx. (Cited from: "transferring the nginx and cloud binaries", implicitly from the description of how new containers are infected)
  • BR-54: Container Drift Protection (Binaries & Scripts) - Inside the target existing container, this mechanism applies by preventing the execution of the newly transferred nginx binary.
  • BR-88: Process Path Exec Allow - Inside the target existing container, this mechanism applies if the path for the new nginx binary is not in an allowed execution directory.
  • BR-82: Process Runtime Execution Guardrails - Inside the target existing container, this mechanism applies by preventing the unauthorized nginx process from starting.
  • BR-67: Container Root User Control - Inside the target existing container, this mechanism applies if the new nginx process attempts to run as root (and is not PID 1).
• Persistence for nginx is established in the newly infected existing container, typically via /root/.bash_aliases. (Cited from: "Establishing persistence by adding the nginx binary to /root/.bash_aliases within compromised containers.")
  • BR-91: Sensitive File Access - Inside the newly infected existing container, this mechanism applies to protect /root/.bash_aliases from unauthorized modification.
• The newly infected existing container then also runs the cloud miner. (Cited from: "deploy the miner")
  • BR-54: Container Drift Protection (Binaries & Scripts) - Inside the newly infected existing container, this applies to block the execution of the new cloud binary.
  • BR-88: Process Path Exec Allow - Inside the newly infected existing container, this applies if cloud's path is not allowed.
  • BR-82: Process Runtime Execution Guardrails - Inside the newly infected existing container, this applies to block the unauthorized cloud process.
  • BR-67: Container Root User Control - Inside the newly infected existing container, this applies if cloud runs as root.
  • BR-87: Process Socket Deny - Inside the newly infected existing container, this applies to block network connections by cloud.

​

F4: Compromise of Kubernetes clusters with anonymous authentication enabled, using a malicious Docker Hub image (observed in previous campaigns).

• Attacker identifies a Kubernetes cluster where anonymous authentication is enabled on the API server. (Cited from: "Previous campaigns ... targeting Kubernetes clusters with anonymous authentication enabled")
• Using anonymous access, the attacker interacts with the Kubernetes API to deploy workloads.
  • BR-57: Cluster Drift Protection - If this vulnerability affects Kubernetes environments, then this mechanism applies because it prevents unauthorized pod creation. Deployment via anonymous, unauthenticated API access would be considered an unauthorized deployment channel if policies enforced by BR-57 restrict pod creation to authenticated and authorized entities.
  • BR-47: Container Capability Control - This mechanism applies by restricting the capabilities that can be assigned to pods deployed via anonymous access, even if the deployment itself is permitted by a misconfigured K8s API. This limits the potential impact of the deployed pod.
• The attacker deploys a pod by instructing the Kubernetes API to pull a malicious Docker Hub image, such as pauseyyf/pause:latest, which already contains the Dero miner. (Cited from: "threat actors pulled a malicious Docker Hub image (pauseyyf/pause:latest) containing the miner instead of transferring binaries.")
  • BR-57: Cluster Drift Protection - As in the previous step, this applies if the anonymous deployment channel is considered unauthorized by BR-57's policies.
  • BR-47: Container Capability Control - As in the previous step, this limits the capabilities of the pod created from the malicious image.
• Once the pod is scheduled and the malicious image is pulled, the container starts, and the embedded Dero miner begins operation, using the same Dero wallet and node addresses as the Docker API campaign. (Cited from: "containing the miner", "Previous campaigns using the same Dero wallet address and node addresses have been observed")
  • BR-88: Process Path Exec Allow - This mechanism applies if the path of the Dero miner executable within the malicious image (pauseyyf/pause:latest) is not on the pre-defined allowlist of execution paths for containers in the environment.
  • BR-82: Process Runtime Execution Guardrails - This mechanism applies by preventing the Dero miner process from starting if it's not an explicitly authorized process for workloads running that image or in that namespace.
  • BR-67: Container Root User Control - This mechanism applies if the Dero miner process within the container runs as root and is not the init process (PID 1).
  • BR-87: Process Socket Deny - This mechanism applies by blocking the Dero miner's outbound network connections to its wallet/node addresses if the miner process is not on the allowlist for network access.
  • BR-90: Process Exec Deny - This mechanism would apply if the Dero miner's executable name or path suffix (e.g., /miner_binary) was on a configured deny list.