Loading story…
TeamTNT abused an exposed Docker API to deploy a privileged Ubuntu container, mount the host filesystem, run cryptominers, and create a privileged SSH user. The group installed the legitimate Weave Scope Docker/Kubernetes administration tool, exposing its web dashboard on default port 4040 to map container environments and execute commands—effectively obtaining backdoor-like control through trusted software rather than custom malware.
A compromised container can also become a path to cloud-account takeover through instance metadata services, pod IAM/AAD identities, embedded long-term cloud keys, and container escapes. Organizations should restrict Docker APIs and Weave Scope access, prevent pod access to metadata endpoints, enforce least-privilege workload identities and Kubernetes RBAC, eliminate long-term credentials from pods and secrets, remediate vulnerable workloads, and segment networks to limit lateral movement.
Map this exposure pattern across your cloud, code, and identities.
2 events from the most recent confirmed update back to the earliest known activity.
Wiz research found that about 40% of surveyed managed-Kubernetes cloud environments had a pod containing a cleartext long-term cloud key, while about 10% had a publicly exposed vulnerable pod associated with a highly privileged IAM or AAD identity. The analysis detailed how compromised pods and nodes can abuse instance metadata, workload identities, secrets, and pod escapes for lateral movement into cloud environments.
Intezer observed TeamTNT exploiting an exposed Docker API to create a privileged Ubuntu container, mount the host filesystem, run cryptominers, and attempt persistence through a privileged SSH user named "hilde." The attackers installed the legitimate Weave Scope tool and used its port-4040 dashboard to map Docker environments and execute commands without a conventional malware backdoor.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. See the values in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Attackers have been abusing improperly exposed Docker daemon APIs, especially unauthenticated services on port `2375`, to take control of running containers and deploy malware. One documented campaign used the Dofloo (AESDDoS) Trojan to enumerate containers and run malicious payloads with Docker commands, giving operators DDoS capability, host profiling data, and a foothold for follow-on activity such as cryptojacking or broader system compromise. Public tooling has also lowered the barrier to exploiting these weaknesses. The **BOtB** container assessment tool demonstrates how exposed Docker daemons, privileged container configurations, Kubernetes service account exposure, metadata service access, Linux kernel keyring leakage, and even `runc` escape flaw `CVE-2019-5736` can be used to break out of containers or extract secrets in CI/CD and live environments. Docker’s guidance recommends protecting the daemon socket and restricting remote API access to trusted systems, underscoring that exposed or misconfigured container management interfaces can quickly turn a single container issue into host-level compromise.
Aug 15, 2026
Palo Alto Networks Unit 42 reported that attackers are actively targeting **unsecured Docker daemons** exposed to the internet, using the Docker API to create and run malicious containers on victim systems. By abusing misconfigured deployments that lack proper access controls, intruders can gain effective control of the underlying host, execute arbitrary workloads, and use compromised infrastructure for follow-on activity such as cryptomining, persistence, and broader cloud or network compromise. The report details attacker tradecraft focused on exposed container management interfaces, where adversaries issue Docker commands remotely to pull attacker-controlled images and launch privileged containers that can interact with the host environment. The activity highlights a recurring cloud security risk: organizations that leave Docker services reachable without authentication can enable rapid compromise of containerized environments and the systems that support them.
Jul 12, 2026
An active cryptojacking campaign is targeting Internet-exposed Kubernetes API servers that permit anonymous authentication and grant excessive permissions. Attackers deploy malicious Docker Hub images impersonating legitimate Kubernetes components, abusing container deployment capabilities to run a UPX-packed DERO miner named `pause`; Kubernetes workloads can also enable deployment across multiple nodes and expand the attacker’s reach. The miner stores encrypted, hardcoded wallet and mining-pool settings, avoiding conspicuous command-line arguments and configuration files. Supporting Linux tooling kills rival miners, selects GPU or CPU payloads, and modifies shell startup files for persistence. Defenders should remove public Kubernetes API exposure, disable or tightly restrict anonymous access, apply least-privilege RBAC, and permit only trusted, verified container images; Docker Hub removed the reported `dockerproxys` and `nohuppo` accounts.
Sep 3, 2026