Self-Blocking Docker API Exploit Delivers the VoidLink DDoS-for-Hire Botnet

An attacker who locked the door behind himself

Most attackers who find an exposed Docker daemon leave the door wide open behind them. This one did the opposite. After planting a root SSH key on the host, the deployed script closed the Docker API port it had just walked through, across every firewall (iptables, ufw, firewalld, nftables) and in the daemon config, then verified the result before exiting. Locking the way in only makes sense for an operator who plans to come back over SSH and does not want a rival taking the same host through the same hole. The traffic came from a single Dutch IP, 45.92.1[.]231, over four days against an internet-facing Docker Engine API on TCP/2375.

A frozen tool with a fingerprint

The operator did not rush. He spent days on version probes and chroot /host escape tests, then ran a single 252-second burst that pushed a persistence script through a rotation of common base images. Every container he exec'd into was one the host had already named in its own /containers/json listing: he enumerated the running set, then replayed real container IDs. The script is a frozen, reused asset with a fingerprint: an ASCII byline by Polly for Соня, a Cyrillic change-log, a hard-coded ed25519 key (ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMhfiGeykxXnvdARJXQSCouFsIHeG…), and a # BEGIN dockerpwn managed ssh block that forces key-only root login. A fleet-wide search found no other IP deploying it and no public sample matching it.

Then he came back to use the door

What the foothold was for stayed a guess until he came back to use it. Three days after the burst he pushed a second stage by hand, pulling an installer via wget from his own source IP. By the next visit he had baked it into a new build of the script, pointed at a dedicated C2 (213.108.21[.]95:3100). The payload is a multi-architecture Go botnet he brands VoidLink: DDoS-for-hire, installed as /usr/local/bin/.systemd-network-monitor, persisted through a systemd unit and an @reboot cron, hidden by a userland libhide.so rootkit. Its command channel showed live tasking against a DDoS-measurement scoreboard and a commercial DDoS-protection provider: an operator measuring firepower before selling it.

One detail separates the two halves. The hands-on foothold ran through a real Docker CLI; the botnet delivery switched to a curl-driven script that wrapped its output in machine-readable markers, named containers programmatically, and polled itself for success between steps. That verbose, self-checking style reads as tool-driven or AI-assisted operation rather than a person typing each command.

What defenders should do now

Remove the exposed TCP/2375; if remote daemon access is genuinely needed, put it on 2376 behind mutual TLS and a firewall rule. Then hunt this operator's leftovers: grep authorized_keys for the ed25519 key and sshd_config for any unexplained # BEGIN dockerpwn managed ssh block, and treat a daemon.json.disabled-by-dockerpwn file as confirmed compromise. The single highest-value network rule matches "Binds" next to "/:/" in a Docker API request body, the host-escape primitive behind most hostile create traffic.

Docker-2375 exposure in 2026 is no longer just a miner-dropper problem. Here, locking the door was the point: within three days the operator walked back through it and installed a botnet. The foothold was the product.