A sophisticated self-replicating malware strain targeting Docker environments has been discovered propagating across insecurely published Docker APIs.
This “zombie” malware, observed in May 2025, autonomously infects Docker containers and transforms them into cryptomining nodes while simultaneously scanning for new victims to continue its spread—all without requiring a command-and-control server.
Securelist researchers identified two primary components in this attack: a propagation module named “nginx” (disguising itself as the legitimate web server software) and a cryptocurrency mining module called “cloud” that mines for Dero currency. Both components are written in Golang and packed with UPX to evade detection.
The malware specifically targets Docker APIs exposed on port 2375, which according to Shodan data, includes approximately 520 publicly accessible instances worldwide as of April 2025.
The malware’s infection vector begins when a compromised container scans the internet for exposed Docker APIs and exploits them by creating new malicious containers and compromising existing ones.
Each infected container becomes a new “zombie” in the growing network of miners. This autonomous propagation method allows the malware to spread exponentially while maintaining persistence across reboots and container restarts.
“This is one of the more sophisticated container-specific threats we’ve seen recently,” said a cybersecurity researcher tracking the campaign.
“The self-replicating nature combined with the complete lack of dependency on external command infrastructure makes it particularly resilient to takedown efforts.”
Infection Mechanism Analysis
The nginx propagation component works methodically to ensure its persistence and spread.
After initial infection, it creates a marker file at “/usr/bin/version[.]dat” containing “1.4” to identify containers that have already been compromised.
.webp)
This prevents re-infection of the same container. The malware then continuously monitors to ensure the mining component is running:-
do {
local_18 = "cloud";
uStack_10 = 5;
uVarl = 5;
var_cloud = slocal_18;
uVar2 = 1;
lVar3 = 1;
/* searches for a process named "cloud" */
os/exec[.]Command("pgrep",5,var_cloud,1,1,in_stack_ffffffffffffffc8);
os/exec[.](*Cmd).Output
(in_stack_ffffffffffffffc8,uVarl,var_cloud,uVar2,1Var3,in_stack_ffffffffffffffc8);
if (lVar3 != 0) {
/* logs an error if not running */
log.(*Logger).Printf(param_1,"Ec: %s\n",7,&local_28,1,1);
in_stack_ffffffffffffffc8 = peVar4;
}
if (var_cloud == (char **) 0x0) {
/* execute the cloud process if not running */
main.startCloudProcess(param_1);
}
time. Sleep(3600000000000);
} while(true);To propagate, the malware generates random IPv4 /16 network subnets and scans them using masscan with the command masscan -p 2375 -oL - --max-rate 360 to identify vulnerable Docker APIs.
When it discovers a vulnerable target, it creates containers with randomly generated 12-character names via the command docker -H run -dt --name [random_name] --restart always ubuntu:18.04 /bin/bash.
The malware ensures persistence by adding itself to the container’s bash startup files.
It inserts /usr/bin/nginx & into the /root/.bash_aliases file, ensuring the malware launches whenever a shell session starts.
Additionally, it uses Docker’s --restart always flag to ensure containers automatically restart after system reboots or container exits.
The mining component uses encrypted configuration data, including a hardcoded wallet address (dero1qyy8xjrdjcn2dvr6pwe40jr13evv9vam6tpx537vux60xxkx6hs7zqgde993y) that gets decrypted at runtime using AES-CTR encryption.
This obfuscation technique demonstrates the threat actors’ attempt to increase sophistication and avoid detection.
What makes this campaign particularly concerning is its ability to operate without any centralized control infrastructure, making disruption efforts significantly more challenging for security teams working to contain this threat.
Equip your SOC team with deep threat analysis for faster response -> Get Extra 𝗦𝗮𝗻𝗱𝗯𝗼𝘅 𝗹𝗶𝗰𝗲𝗻𝘀𝗲𝘀 for Free
