TeamTNT Docker Campaigns
When the Container Runtime Becomes the Entry Point
Executive Summary
In a campaign documented by Datadog Security Labs in 2024, attackers associated with the TeamTNT threat actor aggressively scanned the public internet for exposed Docker API endpoints.
The attack completely bypassed the need for an application vulnerability inside a container because the control interface itself was exposed. Once an unauthenticated Docker API was discovered, attackers remotely generated containers with highly privileged configurations designed explicitly to break out onto the underlying host. The campaign deployed backdoors, credential stealers, hid processes using aggressive namespace manipulation, and attempted to use stolen cloud credentials for massive persistence.
The Boundary Paradox
The campaign demonstrated that the container is not necessarily the security boundary. The true security boundary is the combination of the Docker API + Container configuration + Linux namespaces + Kernel Capabilities. A failure at the runtime-control layer collapses all of those boundaries simultaneously.
Initial Attack Surface
Docker's API is effectively a root-level control interface to the container runtime. If that interface is publicly reachable without authentication, the attacker instantly converts the runtime itself into a remote execution primitive.
Container Deployment and Breakout
Datadog observed scanning against Docker API ports (2375, 2376, 2377, 4343). Once an exposed API was identified, the attacker forcefully created a container with configurations explicitly designed for host takeover:
- Host filesystem:
/mounted directly into the container - PID namespace: Set to
host - Privileges: Set to
privileged
The consequence is absolute. The attacker is no longer merely controlling an application inside a container. They are using the container runtime as a native mechanism to physically interact with the host.
Anti-Forensics via Bind Mounts
One particularly aggressive technique involved hiding processes by mounting an empty directory directly over /proc/<pid>. This completely blinded user-space process utilities.
↓
process information visible
↓
empty directory (blind)
The malicious process continues to execute perfectly, but ordinary process-inspection utilities lose all visibility into it. This is another terrifying example of changing the defender's view rather than merely hiding the malware binary.
Runtime Manipulation Lifecycle
The campaign is especially relevant because attackers structurally manipulated the runtime environment itself. The sequence was continuous:
Opsonance Point of View
The TeamTNT campaign illustrates exactly why runtime security must relentlessly monitor how processes are created, not merely what processes exist.
A defender should be evaluating relationships, not individual events:
new container ↓
privileged configuration ↓
host filesystem access ↓
process execution ↓
credential access ↓
external network communication
Each individual event can be totally legitimate in a chaotic CI/CD or development environment. The complete behavioral chain is materially different.
Key Finding
CONCLUSION
The TeamTNT Docker campaigns definitively demonstrate that an exposed container runtime can effortlessly become a remote operating-system control interface. This justifies Opsonance's focus on behavioral runtime observation over static file analysis. The security significance lies in the runtime conditions under which a process was created and the capabilities it subsequently exercises.