Researchers reported Friday that TeamTNT is using compromised AWS credentials to attack AWS cloud environments via the cloud platform’s application programming interface. The threat actors are now also targeting the credentials of 16 additional applications, including the AWS apps as well as Google Cloud credentials.

The researchers said the threat actors can now identify all identity and access management (IAM) permissions, elastic computer cloud instances, S3 buckets, CloudTrail configurations, and CloudFormation operations granted to the compromised AWS credentials.

This attack was significant because in hitting Google Cloud it represents the first time attackers have targeted IAM credentials on compromised cloud instances outside of AWS. Although it’s still possible that TeamTNT could target the IAM credentials of Microsoft Azure, Alibaba Cloud, Oracle Cloud, or IBM Cloud using similar methods, Unit 42 researchers have yet to find evidence that there has been an attack on the other cloud providers. TeamTNT first started collecting AWS credentials on cloud instances they had compromised as early as August 2020.

In a blog post, Palo Alto’s Unit 42 researchers said these latest discoveries followed the threat group having targeted Kubernetes clusters and creating a new malware called Black-T that integrates open source cloud-native tools to advance its cryptojacking operations.

Yaniv Bar-Dayan, co-founder and CEO at Vulcan Cyber said any enterprise using cloud services needs to understand that offloading compute and storage infrastructure to a cloud provider doesn’t mean offloading cloud security. Companies still need to apply a comprehensive vulnerability management and mitigation plan to all cyber resources utilized by a company, including cloud apps.

“Cloud vulnerabilities are not the same as application vulnerabilities and both require different remediation and mitigation actions to protect from organizations like TeamTNT,” Bar-Dayan said. “We agree with Unit 42 researchers and reiterate the immediate need to protect cloud infrastructure using the appropriate remediation steps common to cloud environments such as configuration changes, compensating controls, and workarounds.”

TeamTNT starts by infiltrating a public cloud environment – with AWS by far the most prevalent target, though Google Cloud was hit this time around – and builds a map of the environment which includes scraped credentials, workloads, and storage, said Oliver Tavakoli, CTO at Vectra.

“All this represents the equivalent of establishing a base camp prior to climbing a high summit,” Tavakoli said. “Then the insertion of cryptomining software begins with TeamTNT counting on the fact that target organizations won’t notice the uptick in usage charges for a while.”

Overview

Palo Alto Networks Unit 42 researchers identified a new malware variant called Black-T, attributed to the cloud-focused threat actor group TeamTnT. Black-T targets exposed Docker daemon APIs to conduct scanning, credential theft, and Monero cryptojacking operations. The malware represents a significant evolution over earlier TeamTnT tooling, incorporating post-exploitation capabilities the group had not previously been observed using.

Who Is TeamTnT?

TeamTnT is a cloud-focused threat group first identified by security researchers in May 2020. The group primarily targets misconfigured or unprotected cloud workloads — including Docker containers and Kubernetes clusters — deploying cryptomining malware to monetize compromised infrastructure. A recurring technique is stealing AWS credential files from compromised systems and using the harvested compute resources to mine Monero (XMR).

Prior to Black-T, TeamTnT had already been observed weaponizing Weave Scope, a legitimate open-source cloud monitoring tool from Weaveworks that integrates with Docker, Kubernetes, and AWS EC2. By deploying Weave Scope on victim systems, the group gained a persistent, interactive foothold inside cloud environments without writing obviously malicious binaries.

What Makes Black-T Different

According to Unit 42, Black-T introduces capabilities not seen in earlier TeamTnT malware:

• Competitor eviction: Black-T actively searches for and terminates competing cryptojacking malware already running on the compromised host, including the Crux worm, an ntpd miner, and a redis-backup miner.
• Memory password scraping: The malware uses mimipy and mimipenguins — Linux and Unix equivalents of the Windows-focused Mimikatz tool — to scrape plaintext credentials from system memory.
• Credential exfiltration: Any passwords recovered by mimipenguins are exfiltrated to a TeamTnT command-and-control (C2) node. Unit 42 noted this was the first observed instance of TeamTnT performing this type of post-exploitation operation.
• Cloud security evasion: Black-T includes code to remove or bypass security agents from Alibaba Cloud (Aliyun) and Tencent Cloud.
• Extended network scanning: The malware uses three network scanners — masscan, pnscan, and zgrab — to discover additional attack targets.

The Black-T Attack Chain

The attack follows a structured sequence of steps:

Step 1 — Initial Access via Exposed Docker Daemon API

TeamTnT scans for Docker daemon APIs that are exposed on the public internet or on a local network without authentication. When Docker is configured to listen on a TCP socket (commonly port 2375 for unauthenticated access or 2376 for TLS), and that port is reachable without proper access controls, an attacker can issue Docker API commands remotely — including creating and running containers — without any credentials.

Once an exposed API is found, TeamTnT uses it to drop the Black-T malware onto the victim host.

Step 2 — Environment Preparation

After execution, the malware displays an ASCII art banner identifying itself, then begins preparing the environment. This includes:

• Searching for and removing competing cryptomining processes (Crux, ntpd miner, redis-backup miner).
• Disabling or removing cloud security agents from Aliyun and Tencent Cloud to reduce detection risk.

Step 3 — Credential Theft

Black-T uses mimipy (a Python implementation) and mimipenguins (a shell-script-based tool) to extract plaintext credentials from system memory on Linux and Unix hosts. These tools mirror the functionality of Mimikatz on Windows. Any recovered passwords are sent to a TeamTnT C2 server.

The malware also contains AWS credential-stealing functionality, targeting the standard AWS credential file locations that developers and automation tools commonly use (~/.aws/credentials).

Step 4 — Network Scanning for Lateral Expansion

Black-T uses three scanning tools to identify additional exposed Docker daemon APIs and other targets on both the local network and connected networks:

• masscan — A fast TCP port scanner capable of scanning large address ranges quickly.
• pnscan — A parallel network scanner.
• zgrab — A Go-based application-layer scanner used to capture service banners. Unit 42 noted that zgrab is relatively lesser-known in this context, and researchers assessed that TeamTnT may have been testing its capabilities for future operations at the time of analysis.

Step 5 — Monero Mining

After the environment is secured and the network has been mapped, the malware downloads a Monero mining payload and begins mining, sending mined currency to a pre-configured wallet address controlled by TeamTnT.

Broader Context: Cloud Cryptojacking Trends in 2020

Black-T emerged as part of a broader wave of cloud-targeted cryptojacking activity in 2020:

• In June 2020, Unit 42 reported a cryptojacking campaign that used malicious Docker images hosted on public registries to embed hidden cryptocurrency mining code inside containers pulled by unsuspecting users.
• Also in June 2020, Microsoft’s Azure Security Center warned of a campaign targeting the Kubeflow machine-learning platform on Kubernetes, where attackers deployed the XMRig cryptominer to mine Monero on compromised clusters.
• In the weeks prior to the Black-T report, TeamTnT had been observed abusing Weave Scope to gain persistent access and deploy cryptojackers in Docker and Kubernetes environments.

Defensive Recommendations

The Black-T campaign exploits a well-known and avoidable misconfiguration. Engineering teams running Docker in any environment — cloud or on-premises — should take the following steps:

Secure the Docker Daemon API

• Do not expose the Docker daemon TCP socket to the internet or untrusted networks. By default, Docker listens on a Unix socket (/var/run/docker.sock) with no network exposure. Enabling TCP without TLS authentication is the root cause of this attack vector.
• If remote API access is required, enforce mutual TLS (mTLS) authentication using client certificates.
• Apply firewall rules and network security groups to restrict access to Docker API ports (2375, 2376) to trusted IP ranges only.

Protect Cloud Credentials

• Avoid storing long-lived AWS access keys in ~/.aws/credentials on cloud instances. Use IAM instance roles instead to grant permissions without static credentials.
• Monitor AWS CloudTrail for unexpected API calls, particularly from unknown IP addresses.

Monitor for Cryptomining Indicators

• Alert on unexpected CPU spikes on container hosts, which are a common indicator of cryptomining activity.
• Monitor outbound network connections to known Monero mining pool endpoints.
• Use container runtime security tools to detect unexpected process execution inside containers (e.g., masscan, zgrab, XMRig, mimipy).

Harden Container Environments

• Regularly audit running containers and deployed images for unexpected or unauthorised workloads.
• Use read-only container filesystems and drop Linux capabilities where possible to limit what malware can do if it gains execution.
• Apply Kubernetes Network Policies or Docker network segmentation to limit lateral movement between services.

Summary

Black-T represents a meaningful step up in sophistication for TeamTnT. By combining exposed Docker API exploitation with competitor eviction, Linux memory credential scraping, cloud security evasion, and multi-tool network scanning, the group demonstrated an increasingly systematic approach to compromising and monetising cloud infrastructure. The core vulnerability — an unauthenticated Docker daemon API accessible over the network — remains entirely preventable through correct configuration. Engineering and security teams running containerised workloads should treat an exposed Docker API as a critical severity finding and remediate it immediately.