Dero miner container infection campaign

The recent campaign uncovered by Kaspersky, involving the Dero cryptocurrency miner spreading through containerized Linux environments by exploiting exposed Docker APIs, represents a sophisticated and highly automated threat vector with significant implications for container security and cloud-native infrastructures.

Attack overview

At its core, this campaign leverages an insecurely published Docker API endpoint (commonly exposed on TCP port 2375 without authentication) as the initial attack surface. Once a single container is compromised, the malware autonomously propagates by scanning the internet for other exposed Docker APIs, then creating new malicious containers or infecting existing ones on those hosts. This results in an exponentially growing network of infected containers—effectively a “container zombie horde” mining Dero cryptocurrency and spreading laterally without any command-and-control (C2) infrastructure.

1. Malware components

• nginx propagation malware
  Despite its name, this is a malicious Golang binary masquerading as the legitimate Nginx web server to evade detection. It is responsible for persistence, propagation, and infection management. Key capabilities include:
  • Maintaining infection state via a sentinel file /usr/bin/version.dat with content 1.4 to mark already infected containers.
  • Ensuring the Dero miner process (cloud) is continuously running.
  • Scanning the internet for exposed Docker APIs using masscan (a high-speed port scanner).
  • Exploiting remote Docker daemons by creating malicious containers with the --restart always flag to guarantee persistence.
  • Infecting existing containers based on specific criteria (Ubuntu 18.04 base image and absence of the version marker).
• cloud Dero miner
  Also written in Golang and packed with UPX, this binary is a customized version of the open-source DeroHE CLI miner. It contains hardcoded, encrypted configuration data including:
  • A Dero wallet address for mining proceeds.
  • Encrypted Dero node addresses used for mining pool communication.
  The encryption of configuration data (AES-CTR) and obfuscation techniques indicate a higher level of sophistication compared to earlier campaigns.

2. Propagation mechanism

• The nginx malware generates random /16 IPv4 subnets and scans them for hosts with port 2375 open.
• Upon finding a responsive Docker API, it verifies the daemon’s availability by listing running containers.
• It then creates a new malicious container on the target host using the Ubuntu 18.04 image, installs dependencies (masscan and docker.io), and copies the malware binaries into it.
• Persistence is ensured by adding the nginx binary to the infected container’s .bash_aliases, so it runs on shell login.
• The malware also attempts to infect existing containers that meet its criteria, thus hijacking more container resources.

3. No Command-and-Control server

Unlike many advanced persistent threats, this campaign does not rely on a centralized C2 infrastructure. Instead, it uses a fully autonomous propagation model:

• Each infected container independently scans and compromises new victims.
• This self-propagating behavior makes containment and eradication more challenging.

Security implications

• Exposed Docker APIs are a critical risk: The default Docker API port 2375 is often left open without TLS or authentication, providing an easy vector for attackers to gain control over containerized environments.
• Container runtime compromise is as dangerous as host compromise: Even if container images are sourced from trusted registries, runtime infection can occur if the Docker daemon is exposed or misconfigured.
• Automated lateral movement: The malware’s ability to infect both new and existing containers on remote hosts enables rapid horizontal spread within and across networks.
• Cryptojacking impact: Besides resource theft, mining operations degrade system performance and increase operational costs, while also potentially masking other malicious activities.

Recommendations for container security

1. Never expose Docker APIs publicly without strong authentication and encryption
   • Use TLS certificates and role-based access controls.
   • Restrict API access to trusted networks or VPNs.
2. Implement continuous runtime monitoring and anomaly detection
   • Deploy container security platforms (e.g., Kaspersky Container Security) to detect suspicious container behavior, unauthorized image usage, and misconfigurations.
3. Harden container infrastructure
   • Apply the principle of least privilege to container permissions.
   • Regularly audit container images and running containers for unexpected binaries or processes.
4. Proactive threat hunting and incident response
   • Monitor for indicators of compromise such as unusual container creation, presence of /usr/bin/nginx or /usr/bin/cloud binaries, and suspicious network scanning activity.
   • Use forensic analysis and compromise assessment services to identify and remediate infections early.

This Dero miner campaign exemplifies the evolving threat landscape targeting containerized environments. The blend of autonomous propagation, exploitation of insecure Docker APIs, and stealthy mining operations underscores the urgent need for robust container security hygiene and vigilant monitoring. Organizations leveraging container technology must prioritize securing their Docker daemons, implement runtime defenses, and maintain proactive incident response capabilities to mitigate such sophisticated cryptojacking threats.

Indicators of Compromise (IoCs)

This analysis highlights the criticality of securing container orchestration environments and the sophistication of modern cryptojacking campaigns exploiting cloud-native infrastructure misconfigurations.