Black-T Malware: How TeamTnT Exploits Exposed Docker Daemon APIs for Cryptojacking

Docker

YOUR COSMETIC CARE STARTS HERE

Find the Best Cosmetic Hospitals

Trusted • Curated • Easy

Looking for the right place for a cosmetic procedure? Explore top cosmetic hospitals in one place and choose with confidence.

“Small steps lead to big changes — today is a perfect day to begin.”

Explore Cosmetic Hospitals Compare hospitals, services & options quickly.

✓ Shortlist providers • ✓ Review options • ✓ Take the next step with confidence

This article is based on reporting originally published by BankInfoSecurity, sourced from research by Palo Alto Networks Unit 42.

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.

0 0 votes
Article Rating
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
0
Would love your thoughts, please comment.x