TeamTNT Is Scanning for Your Cloud Right Now

#You probably think "cloud security" is someone else's problem.

Your hosting provider handles the servers. Your SaaS vendor manages the platform. Your IT guy set up the Office 365. The cloud is abstracted away, invisible, and therefore secure. Right?

No. And there's a threat actor who has been proving that wrong since 2019.

Their name is TeamTNT. They are one of the most prolific cloud-focused attack groups in operation. They scan the entire internet looking for misconfigured Docker containers, exposed Kubernetes clusters, open Redis instances, and unprotected cloud APIs. When they find one, they move fast: deploy cryptominers to burn your compute bill, steal your cloud credentials, install rootkits for persistence, and sell access to your compromised infrastructure to other criminals.

They "retired" in 2021. They came back in 2024 with better tools. They're still active.

#What TeamTNT actually does.

TeamTNT's playbook is straightforward and devastatingly effective:

1. They scan the entire internet for exposed services. Using tools like masscan and ZGrab, they look for Docker daemon APIs on ports 2375, 2376, 4243, and 4244. They look for Kubernetes API servers on port 6443. They look for exposed Redis on port 6379. They look for Jupyter notebooks and SSH. All of these services, when left exposed to the internet without authentication, are free entry points.

2. They steal your cloud credentials. Once inside, TeamTNT harvests credentials from everywhere: the AWS EC2 instance metadata service, on-disk credential files for AWS, GCP, Docker Hub, and GitHub. Your cloud provider credentials, sitting on the server where your app runs, become their cloud provider credentials.

3. They spread like a worm. Stolen SSH keys and credentials from one compromised host are used to pivot to others. One exposed Docker container becomes access to your entire environment.

4. They mine cryptocurrency on your hardware. XMRig, a Monero miner, is their primary payload. Your CPU cycles, your electricity, your cloud bill. Their profit.

5. They sell access. Their 2024 campaign, dubbed "Docker Gatling Gun," didn't just mine crypto. They rented compromised servers to other attackers. Your infrastructure becomes a platform for other crimes.

6. They cover their tracks. TeamTNT deploys the Diamorphine rootkit to hide processes, sets immutable file attributes to prevent cleanup, creates backdoor root accounts, and clears logs. Once they're in, they're hard to find and harder to remove.

#Why this matters if you're a small business.

You might be reading this thinking "we don't run Docker" or "we don't have Kubernetes." You might be right. But consider this:

Your web hosting probably runs containers. Modern hosting platforms -- AWS, Google Cloud, Azure, DigitalOcean, and plenty of smaller providers -- run your applications in containers. If your hosting provider has a misconfigured Docker deployment, TeamTNT doesn't need to compromise you directly. They compromise the infrastructure you're running on.

Your SaaS tools run on cloud infrastructure. Every SaaS product your business uses -- your CRM, your project management, your accounting software -- runs on cloud infrastructure with Docker, Kubernetes, Redis, and the rest of the stack TeamTNT targets. We've written before about SaaS as a liability. A compromised SaaS provider means compromised customer data.

Your developers might be exposing things without knowing it. If your company has developers or a contracted development team, they might be running Docker locally, might have exposed a development environment to the internet, might have committed AWS credentials to a Git repository. These are the kinds of misconfigurations TeamTNT hunts for at internet scale.

Redis is everywhere. If your application uses Redis for caching or session management -- and many do -- an exposed instance is a direct path in. Redis itself has critical vulnerabilities that make this even worse.

The cloud is not "someone else's problem" just because you outsource your hosting. The cloud is infrastructure. Your data runs on it. Your business depends on it. And TeamTNT is scanning it 24/7.

#The campaigns.

TeamTNT doesn't run one-off attacks. They run campaigns at scale.

Chimaera (2021): Compromised thousands of Docker, Kubernetes, and Redis hosts across the internet. Mass exploitation. Industrial-scale cryptomining.

Black-T (2020): Added cloud credential scanning to their toolkit. Not just mining on your hardware anymore -- stealing the keys to your cloud accounts.

Docker Gatling Gun (2024): The comeback campaign. Targeted exposed Docker daemons with Sliver-based command and control (replacing their older Tsunami IRC bot). Rented out compromised servers to other threat actors. Your infrastructure as a service -- for criminals.

Each campaign builds on the last. Better evasion. Better persistence. Better monetization.

#What to do.

This is not theoretical. These are the concrete steps that close the doors TeamTNT walks through.

#If you manage any cloud infrastructure:

1. Never expose Docker APIs to the internet. Bind the Docker socket to localhost. If you need remote access to Docker, use SSH tunneling. Ports 2375 and 2376 should never be reachable from the public internet. This single step eliminates TeamTNT's primary attack vector.

1. Lock down your Kubernetes API server. Require mutual TLS (mTLS) and role-based access control (RBAC). The API server should not be accessible without authentication. Ever.

1. Enforce IMDSv2 on AWS. If you run anything on AWS EC2, switch from IMDSv1 to IMDSv2. IMDSv1 allows any process on the instance to grab IAM credentials from the metadata service with a simple HTTP request. IMDSv2 requires a session token, which blocks TeamTNT's credential theft technique.

1. Apply least-privilege IAM everywhere. Your application server does not need admin-level cloud credentials. If the credentials TeamTNT steals can only read from one S3 bucket, the blast radius is limited. If they can do anything in your AWS account, the blast radius is total.

1. Restrict egress traffic and monitor for mining pools. Cryptominers need to connect to mining pools. If your servers can only reach the specific external services they need and everything else is blocked, a miner can't phone home. Monitor for unusual outbound connections.

1. Scan your own external exposure. Run regular scans of your own IP ranges for ports 2375, 2376, 4243, 4244, 6443, and 6379. If any of those ports are open to the internet, close them immediately. Don't wait for TeamTNT to find them first.

1. Deploy runtime container security. Tools like Falco can detect rootkit loading, unauthorized scanning, and anomalous process execution inside containers in real time. This is your alarm system for when prevention fails.

#If you don't manage infrastructure directly:

1. Ask your hosting provider and SaaS vendors about their container security posture. Specifically: are their Docker and Kubernetes APIs authenticated? Are they running IMDSv2? Do they have runtime container monitoring? If they can't answer these questions, that's an answer.

1. Audit your cloud credentials. Rotate AWS keys, GCP service account keys, Docker Hub tokens, and GitHub tokens. If your developers have credentials on their laptops, those credentials should be short-lived and scoped to minimum necessary permissions.

1. Make sure you actually have a security program. Not just antivirus. Not just a firewall. A program that includes asset inventory, access control, monitoring, and incident response. TeamTNT is automated. Your defenses need to be too.

#The bottom line.

TeamTNT is not sophisticated in the way nation-state actors are sophisticated. They don't need to be. They scan the entire internet for basic misconfigurations -- exposed APIs, default credentials, unauthenticated services -- and they find thousands of targets every time they look. The bar for getting compromised is not high. It's leaving a door open that should have been closed.

The cloud made infrastructure invisible. It did not make it secure. If you can't tell me right now whether your Docker APIs are exposed, whether your cloud credentials follow least privilege, or whether your hosting provider uses IMDSv2, you don't know if TeamTNT is already inside.

That's not a comfortable place to be. But it's fixable. And it's fixable today.

#Further reading

• Aqua Security: Docker Gatling Gun Campaign - 2024 campaign technical analysis
• Unit 42: TeamTNT Cloud Operations - comprehensive threat research
• MITRE ATT&CK: TeamTNT - full TTP mapping
• Falco - open source runtime container security
• AWS IMDSv2 Guide - how to enforce IMDSv2
• Docker Security Best Practices - official Docker security documentation