TeamTNT
From Exposed Container Infrastructure to Cloud Persistence
Executive Summary
TeamTNT is one of the most extensively documented threat actors targeting containerized and cloud infrastructure. Its campaigns have repeatedly demonstrated a characteristic progression: Internet-Exposed Infrastructure → Container Compromise → Credential Discovery → Container / Kubernetes Enumeration → Cloud Credential Theft → Privilege Escalation → Persistence → Cryptomining or Further Cloud Abuse.
More recent TeamTNT-related activity has included scanning for exposed Docker APIs and deploying backdoors and cloud-credential stealers onto compromised systems. Datadog Security Labs documented a campaign that systematically scanned the internet for exposed Docker API endpoints, deployed multiple backdoors and credential stealers, and attempted to establish persistence through newly created cloud IAM users.
The Runtime Foothold
The importance of TeamTNT from an Opsonance perspective is that the initial compromise almost always occurs at the runtime layer. The attacker does not necessarily begin with a sophisticated zero-day Kubernetes exploit. They begin by finding a runtime that is exposed, misconfigured, or insufficiently isolated.
Attack Surface
The important property demonstrated by TeamTNT is that container compromise is not necessarily the final objective. It is simply the first foothold.
Observed Attack Sequence
Datadog's analysis of a TeamTNT-associated campaign documented internet-wide scanning for exposed Docker API endpoints followed by the deployment of backdoors and cloud credential stealers. The attackers attempted to use stolen cloud credentials and created additional IAM users for persistence, using Linux anti-forensics techniques to make their activity harder to detect.
Analyst Assessment
The crucial observation here involves the economics of cloud-native compromise. An attacker does not necessarily need to compromise the host operating system first. A container may already natively contain:
- Cloud credentials
- Service credentials & API tokens
- Sensitive environment variables
- Mounted configuration files
- Kubernetes credentials (ServiceAccounts)
- Network access to internal microservices
Consequently, the container itself becomes an identity and network pivot point. This produces a massive security asymmetry:
├── Compute
├── Identity
├── Network
├── Filesystem
└── Cloud access
A security system that primarily treats the container as an isolated "application" will fundamentally miss the fact that it has become the attacker's operational platform.
Runtime Security Implication
The TeamTNT campaigns demonstrate exactly why runtime observation needs to correlate seemingly ordinary container activity. Individually, things like process creation, credential access, network connection, and file access may not indicate compromise. However, when viewed contextually:
This represents a substantially different behavioral sequence that can only be identified by continuous, ring-0 monitoring.
Opsonance Point of View
TeamTNT is perfectly aligned with Opsonance's core runtime-defense thesis. The attacker is operating strictly inside the workload runtime. That means security visibility needs to fundamentally shift its focus.
↓
Container Metadata
Opsonance's value proposition in this context is not simply detecting that a container exists or that a Kubernetes resource changed. It is identifying behavior occurring inside the runtime and correlating that behavior with the surrounding infrastructure context. A compromised container is merely the bridge from workload compromise to cloud identity compromise.
Key Finding
CONCLUSION
The container is not necessarily the target. It can be the launch platform. TeamTNT's campaigns demonstrate how a relatively small runtime foothold can be autonomously transformed into credentials, persistence, and broader cloud access.