Unpacking a troubling attack trend

Misconfigured Docker daemons that expose the API to the internet create an inviting entry point for threat actors. In recent analyses, researchers observed a multi-stage, Tor-enabled workflow that not only gains initial access but also lays the groundwork for a self-spreading, botnet-like operation. This piece explains how such an attack unfolds, why it matters for cloud and container environments, and what defenders can do to reduce risk.

Why exposed Docker APIs pose a serious risk

The Docker daemon often communicates via a port (commonly 2375) that, if left open without TLS or authentication, effectively provides an unauthenticated command channel to anyone who can reach it. When endpoints are reachable from the public internet, attackers can initiate container creation, deploy malicious images, and pivot to other services connected to the host or network. In cloud and multi-tenant settings, this exposure can enable rapid lateral movement and data exposure, making it a high-impact misconfiguration with serious security implications.

The infection chain: how the attack unfolds

Attackers begin by scanning for exposed Docker APIs on port 2375. When a vulnerable host is found, they attempt to create a new container using a compact Alpine-based image that includes a base64-encoded shell command. On startup, the container decodes and executes the command, performing the following steps:

1. Install essential tools (curl and Tor) and launch a Tor daemon in the background to route traffic through the Tor network, masking the attacker's origin with a SOCKS5 proxy.
2. Use Tor to fetch a second-stage script (docker-init.sh) from a Tor hidden service. This script is executed to establish persistence and broaden access to the host.
3. Enable persistent access by adding an attacker-controlled SSH public key to the host's /root/.ssh/authorized_keys on the mounted filesystem, granting ongoing access even if the initial container is replaced.
4. Create a recurring firewall rule via a cron job (written in base64) that aims to block external access to port 2375, leveraging whatever firewall utility is available (iptables, nftables, ufw, etc.).
5. Install supporting tools (masscan, zstd, libpcap, torsocks) to accelerate scanning, data collection, and evasion.
6. Download a Go-based binary compressed with Zstandard, decompress it to a temporary location, give it execute permissions, and run it. This dropper then extracts a second-stage binary and inspects the host's utmp file to identify logged-in users who might be targeted next.

The overall flow emphasizes persistence, stealth, and propagation. By leveraging Tor, the operators aim to evade immediate attribution while deploying a payload capable of scanning for new targets and initiating similar infections on other exposed Docker endpoints.

Botnet-building behavior: self-replication and persistence

Once the initial foothold exists, the binary scans for other exposed Docker APIs and attempts to replicate the same container-creation technique on newly discovered hosts. It also attempts to remove competing containers, a tactic often used in botnets to consolidate control over compromised nodes. Observers noted dormant logic that could enable additional exploitation vectors, such as:

• Telnet (port 23) with default credentials, creating a fallback access method if Docker remains poorly secured.
• Chrome remote debugging (port 9222), which could facilitate credential theft, browser session hijacking, and remote file downloads.

Although no fully realized multi-vector botnet was observed at the time, researchers described the variant as an early-stage, multi-path threat with lateral movement, persistence, and the potential for future credential theft and browser-based exploits.

Implications for cloud environments and defenders

This evolving threat underscores the risk of internet-exposed Docker APIs and the broad attack surface that can emerge when containers are used as an initial foothold. The combination of container abuse, Tor-based anonymity, and automated replication signals a shift from opportunistic crypto-miners to more sophisticated, multi-vector campaigns. Organizations should treat exposed Docker APIs as urgent security issues requiring immediate remediation and continuous monitoring.

Defensive strategies: reducing your attack surface

Mitigating these risks starts with eliminating internet exposure of the Docker API and enforcing strong access controls where it must be reachable. Key steps include:

• Disable public access to the Docker daemon. If remote control is necessary, bind the API to a private network or use a secure tunnel (SSH, VPN) rather than exposing port 2375 publicly.
• Enable TLS with mutual authentication (TLS/SSL) for the Docker daemon. Use certificate-based access control and restrict client permissions to the minimum required.
• Use a dedicated management network and firewall rules to block inbound connections to 2375 from untrusted networks.
• Keep Docker and host systems updated with the latest security patches and monitor for anomalous container creation patterns or the appearance of unexpected SSH keys on hosts.
• Implement network segmentation and least-privilege principles to limit how a compromised host can affect others in the environment.
• Regularly audit container images and registries. Source images only from trusted registries and scan for embedded malware or suspicious startup commands.
• Monitor for indicators of compromise such as unexpected cron jobs, new SSH keys, unusual Tor activity, or sudden changes to firewall rules on hosts.
• Establish incident response playbooks for rapid containment, host isolation, credential rotation, and forensic collection if exposure is detected.

Conclusion: actionable takeaways

Exposed Docker APIs represent a high-stakes configuration risk that can empower attackers to deploy multi-stage payloads, bypass traditional defenses via Tor, and lay the groundwork for a botnet. To reduce risk, organizations should seriously limit API exposure, enforce strong authentication and encryption, and implement robust monitoring and response capabilities. By aligning container security with network hygiene and cloud security best practices, teams can disrupt these attack chains before they gain traction and protect downstream systems from compromise.