Overview: A Worm That Targets Misconfigured Docker Daemons

A cryptomining worm discovered by Cado Security exposed a serious and widespread Docker security problem: insecure remote API connections. The worm — attributed to a threat actor group known as TeamTNT — targeted Docker daemons that had been left open to unauthenticated remote connections, stole AWS credentials stored on the host, and used those credentials to spread further. The attack is a sharp reminder that containerized environments carry their own distinct security risks, many of which go unaddressed in traditional DevSecOps frameworks.

How the Attack Worked

The attack chain followed a clear pattern:

1. Credential theft: The worm scanned for and harvested AWS credentials stored locally on the compromised host (typically in ~/.aws/credentials).
2. Internet scanning: TeamTNT used those stolen credentials and automated scanning tools to discover other Docker hosts exposed to the internet with unauthenticated remote APIs.
3. Container compromise: Once inside, the attackers deployed cryptomining malware to generate cryptocurrency using the victim’s compute resources.
4. Potential escalation: Security researchers noted that the same access vector could be used to “jailbreak” from the container to the underlying host, enabling the attacker to run arbitrary code, exfiltrate data, or install persistent malware.

While cryptomining is often treated as a nuisance-level threat, the underlying vulnerability is far more dangerous. An attacker with remote API access to a Docker daemon has, in effect, root-level access to the host.

Root Cause: Insecure Docker Remote API Defaults

The Docker daemon can be configured to accept connections over a TCP socket, which enables remote management. The problem is that enabling remote connections without TLS authentication exposes the daemon to anyone who can reach the port — by default, TCP port 2375 for unencrypted traffic and 2376 for TLS-encrypted traffic.

According to Sergei Shevchenko, CTO of Prevasio (a container vulnerability scanning service), the core issue is a gap between Docker’s flexibility and most developers’ security knowledge. Securing the remote API requires generating TLS certificates, configuring mutual TLS (mTLS) authentication, and correctly referencing those certs in the daemon configuration — steps that many developers skip in the interest of simplicity.

The result is a large number of Docker hosts reachable from the public internet with no authentication required whatsoever.

Immediate Mitigations

If your organisation runs Docker daemons accessible over a network, the following steps should be treated as non-negotiable baselines:

• Disable the unauthenticated TCP socket. Unless you have a specific need for remote API access, bind the Docker daemon to the Unix socket only (unix:///var/run/docker.sock). Remove any -H tcp://0.0.0.0:2375 flags from your daemon configuration.
• Enable TLS mutual authentication. If remote access is required, configure the Docker daemon to use TLS with client certificate verification (--tlsverify, --tlscacert, --tlscert, --tlskey). Both the server and the client must present valid certificates.
• Restrict access with firewall rules. Use host-based firewalls or cloud security groups to allow inbound connections to port 2375/2376 only from known management IPs.
• Audit AWS credential storage. Avoid storing long-lived AWS credentials in ~/.aws/credentials on hosts running Docker. Use IAM roles for EC2 instances or environment-specific credential injection via secrets management tools (AWS Secrets Manager, HashiCorp Vault, etc.).
• Scan for exposed Docker APIs. Use network scanning tools internally, or services such as Shodan alerts (externally), to detect any Docker API endpoints accidentally exposed to the internet.

Why Container Escape Is a Serious Risk

When an attacker gains access to a Docker daemon over an unauthenticated remote API, they are not confined to a single container — they have access to the Docker control plane itself. This means they can:

• Start new privileged containers that mount the host filesystem.
• Inspect environment variables and secrets injected into running containers.
• Stop or tamper with legitimate containers.
• Use the host network stack for lateral movement within your internal network.

This makes an exposed Docker API functionally equivalent to unauthenticated SSH access to the underlying host. The cryptomining payloads observed in the TeamTNT campaign represent the least harmful use of such access.

The Broader Container Security Challenge

This attack is not an isolated incident — it reflects a structural tension in how container technology has been adopted at scale.

Containers are not inherently more secure than monolithic applications. They offer benefits such as isolation, reproducibility, and the ability to quickly redeploy patched images. However, in practice the complexity of container orchestration introduces new attack surfaces: misconfigurations, overly permissive network policies, insecure image registries, excessive container privileges, and — as demonstrated here — unprotected management APIs.

As Docker and Kubernetes adoption has grown, so has attacker interest. Threat actors are actively scanning for misconfigured container infrastructure because the population of targets is large enough to make the effort worthwhile. Security research teams are also publishing new container-specific CVEs at an increasing rate, meaning the threat landscape continues to evolve.

The key principle Shevchenko highlights is that container security requires dedicated tooling and processes — not just a translation of existing practices from the VM or bare-metal era. Authentication, least-privilege networking, image scanning, runtime anomaly detection, and secrets management must all be addressed as first-class concerns in any container-based deployment.

Recommendations for DevSecOps Teams

• Integrate container-specific security scanning into CI/CD pipelines to catch misconfigured Dockerfiles and insecure default settings before deployment.
• Adopt a secrets management strategy that avoids placing cloud credentials on container hosts in plaintext files.
• Apply the principle of least privilege to container networking: containers should only be able to communicate with the services they need, and management APIs should never be exposed to untrusted networks.
• Monitor container runtime behaviour with tools capable of detecting anomalous process execution, unexpected network connections, or cryptocurrency mining activity.
• Establish a container security baseline using hardening guides such as the CIS Docker Benchmark as a starting reference point.
• Train developers on container-specific security risks, including the implications of enabling TCP-based Docker API access without TLS.

Key Takeaway

The TeamTNT campaign is a textbook illustration of how operational convenience — leaving a management API open for ease of use — can create critical security exposure. For DevSecOps teams, the lesson is unambiguous: container security is a discipline of its own. Legacy assumptions about network perimeters and application security do not translate directly to containerized environments. Proactive configuration hardening, continuous scanning, and developer security education are not optional extras — they are the baseline required to run containers safely in any internet-connected environment.