TeamTNT Reemerged with New Aggressive Cloud Campaign

In part one of this two-part blog series, titled The Anatomy of Silentbob’s Cloud Attack we provided an overview of the preliminary stages of an aggressive botnet campaign that aimed at cloud native environments. This post will dive into the full extent of the campaign and provide a more comprehensive exploration of an extensive botnet infestation campaign.

The botnet run by TeamTNT has set its sights on Docker and Kubernetes environments, Redis servers, Postgres databases, Hadoop clusters, Tomcat and Nginx servers, Weave Scope, SSH, and Jupyter applications.

During our research, Aqua Nautilus managed to access TeamTNT’s Command and Control (C2) server, a move that enabled us to collect invaluable intelligence about the victims, the targeted environments, the arsenal at the attacker’s disposal, and the tactics employed in this campaign.

Based on our research, we have discerned that this botnet perpetually scans the entirety of the internet. Consequently, every IP address undergoes a scan at least once every hour. We discovered that the rate of infection is fairly rapid, with a minimum of two new victims emerging every hour.

The infrastructure

We recently uncovered an emerging campaign that is targeting exposed Docker APIs and JupyterLab instances. Upon further investigation of the infrastructure, we found evidence of a broader campaign orchestrated by TeamTNT.

Figure 1 – Interactive attack graph, you can control the attack graph by choosing specific elements in the attack

The IP address 45[.]9[.]148[.]108 is registered to NiceIT-NL, a company that provides domain names and web hosting services. In many cases, a single server is shared by multiple customers, making it challenging to link malicious activity to a specific entity from an external viewpoint.

However, despite these challenges, we managed to trace a significant amount of activity related to TeamTNT back to this IP address.

Figure 2 – Interactive Virus Total graph of the C2 server of TeamTNT

As illustrated in Figure 2 above, the subdomains on the AnonDNS website, are associated with TeamTNT. They all point to the same cloud native campaign, which aims to infect systems with their cloud worm.

So far, we have identified the following subdomains involved in this campaign:

• http[:]//silentbob[.]anondns[.]net
• http[:]//everlost[.]anondns[.]net
• http[:]//everfound[.]anondns[.]net
• http[:]//ap-northeast-1[.]compute[.]internal[.]anondns[.]net

The trend in activity strongly suggests that TeamTNT is still in the process of building, refining, and preparing their campaign.

Figure 3 – DNS queries trend taken from our honeypots

TeamTNT’s toolbox

The following are files that TeamTNT deposited on our diverse array of honeypots during the execution of their campaign.

Mind that all the above mentioned artifacts were uploaded to VirusTotal.

The targeted environments

The following are the targeted environments as identified in the scripts, as well as from observed attacks against our honeypots and actual organizations:

We also saw some tests made with various vulnerabilities and misconfigurations in applications and environments such as Tomcat, Nginx, add ssh access.

Exploiting public container registries to deploy malware

TeamTNT is recognized for utilizing Docker Hub’s public registry to distribute their malware. Our Team Nautilus frequently reports to Docker Hub about malicious activities occurring on their public registry. The following container images were used in this current campaign:

We notified Docker Hub about these malicious users and container images.

The scanning mechanism

Each target in this campaign is infected with malware and runs a worm script that operates in three stages:

1. Scanning the internet for potential victims.
2. Infecting the newly identified victims with the malware and worm (example can be seen in the technique section below).
3. Reporting back to the Command and Control (C2) server about the compromised victims. Figure 4 – Scanning operation of TeamTNT’s botnet.

Figure 4 – Scanning operation of TeamTNT’s botnet

This botnet is notably aggressive, rapidly proliferating across the cloud and targeting a wide array of services and applications within the Software Development Life Cycle (SDLC). It operates at an impressive speed, demonstrating remarkable scanning capability.

The botnet is designed to communicate with a central C2 server to determine the next range of IP addresses to scan. Each compromised system, or ‘victim’, involved in scanning the internet, queries the C2 server to receive a number between 1 and 255. This number corresponds to the first octet of the IP range in a /8 CIDR block, which encompasses approximately 17 million IP addresses.

In our experiment, we observed that each number (1-255) in the first octet is selected six times per minute. This suggests that for each number in the first octet, there are six compromised servers scanning the internet for vulnerable targets every minute.

Using Masscan, a tool renowned for its high-speed scanning capabilities, we estimate that a /8 CIDR range can be scanned within three minutes for a specific port. Based on these calculations, we estimate that each IP address is scanned approximately once every 30 seconds. This level of scanning frequency is truly remarkable.

To validate our hypothesis, we examined a dedicated honeypot and observed a significant increase in Docker API scanning activity, while the scanning frequency of other ports remained consistent. Over a two-week period, we recorded 440 scans, suggesting that each IP address worldwide is scanned approximately 1.3 times per hour. Despite being more moderate than some estimates, this frequency still represents a significant volume of scanning activity.

In the eye of a Tsunami

Over the years, TeamTNT has consistently used Tsunami malware as part of their tactics, techniques, and procedures (TTPs), and this campaign is no exception. Tsunami is a type of malware, specifically a botnet, that primarily targets Linux systems.

A key feature of Tsunami is its ability to connect to a Command and Control (C2) server using the Internet Relay Chat (IRC) protocol. This server is used to control the botnet, issuing commands to the infected systems. The C2 server operates through IRC channels, functioning like chat rooms on the IRC network. Each infected system joins a specific channel on the IRC server, where it waits for commands.

These commands can instruct the botnet to download additional malware or perform other malicious activities, effectively transforming the infected system into a backdoor for various nefarious purposes.

Tsunami includes features to maintain its presence on the infected system, such as hiding its processes and files to avoid detection. It can also automatically reconnect to the C2 server if the connection is lost, ensuring sustained control over the compromised system.

By connecting to the IRC channel of TeamTNT’s Tsunami malware, one can observe all the infected machines, the commands sent from the C2, and the targets.

Figure 5 – Screenshot from the IRC channel #AWS used as Command and Control server

Over a span of 7 days, we observed 196 unique infected hosts. This equates to ~1.3 new victims every hour. Given that this campaign is aggressively scanning the internet for exposed Docker APIs, Jupyter Lab and Notebook instances, Redis servers, SSH connections, and Weave Scope applications, it can rapidly infect new hosts that are exposed even for a brief moment.

Understanding the techniques used by TeamTNT

In the following section, we delve into the various techniques that TeamTNT employs as part of their campaign.

Initial Access

In figure 6 below, you can see our Honeypots alert system indicates a malicious container deployed. You can see the vanilla image alpine:latest with a malicious command, mounting the ‘/host’, decoding (base64) and running an encoded command and downloading aws.sh script from the C2 server.

Figure 6: A screenshot taken from our honeypot’s alert system

Execution

In terms of execution and the download command is a bash implementation used to download scripts and binaries from the C2 server. It receives an address, parses it, and downloads the available files

Figure 7: Execution examples

Persistence

We’ve seen 4 types of backdoors used by TeamTNT. The first one was by creating a new account by modifying the passwd, shadow and sudoers files. First the files’ permissions are modified so they can be modified. Next under the use system the data is inserted or modified.

Figure 8: the make_user_axx() function which creates new users

The passwd file contains information about the users in the system. Per each user, the username, password, user ID, group ID, Home directory and command shell.

The shadow file stores hashed passphrases of the users’ accounts.

The sudoers file stores the system privileges of the users.

In the script above TeamTNT creates or runs over the user ‘system’, it got listed in the sudoers file with the highest privileges to the system.

Below in figure 9, you can see that TeamTNT is creating an SSH backdoor by inserting their own RSA key. In addition, they are altering the SSH configuration to prevent access from known hosts, while making the configuration more flexible to SSH connection by them.

Figure 9: the make_user_axx() function which creates new users

Figure 10 below, illustrates a function that is creating a hidden backdoor. This is very similar to the pervious mechanism in figure 9 above. Here the user is games. This function also creates an SSH backdoor, allowing TeamTNT backdoor access to the server via SSH.

Figure 10: the make_hiden_door() function which creates ssh backdoor

As can be seen in figure 11 below, once the user and password were created, the access command (with the credentials) is sent to the C2 server of TeamTNT.

Figure 11: the get_ssh_link() function which reports to TeamTNT about a newly acquired backdoor

The second one was by using Gsocket, as seen in the execution command in figure 12 below, TeamTNT is using PHP to execute a script that runs on a compromised server.

Figure 12: Opening backdoor on attacked server with gscat.php

This is a snippet from the gscat.php script, and as illustrated is set to download x, which is Gsocket, which is a powerful reverse shell tool that allows for the creation of secure, always-on, global server sockets. Essentially, it enables you to create a network socket that is accessible from anywhere on the internet, bypassing NAT and firewalls by using the Global Socket Relay Network to route the traffic.

Figure 13: A couple of snippets from the Gsocket infection sctipt

The third backdoor is by using a webshell of tmate[.]io. Tmate is legitimate software serves as a terminal multiplexer with instant terminal sharing: it enables a number of terminals to be created, accessed, and controlled from a single screen and be shared with another mates. In figure 14 below, you can see how TeamTNT is utilizing this tool as a backdoor.

Figure 14: Tmate backdoor execution script

The fourth backdoor is by utilizing a socket connected over HTTP service with Ngrok product.

Another interesting persistence technique we’ve seen in the campaign is removing the execution of runc when the initial access is via misconfigured Docker API. This is a new type of persistence we offer to MITRE, as it didn’t appear in record. TeanTNT is locking runc, which effectively locks the misconfiguration and closes the access to the compromised server. They are doing it to prevent from other campaigns to access the server and remove their attack, hence gaining persistence to their attack from competing campaigns.

Figure 15: Changing runc so it won’t execute to block exposed Docker API initial access vector to increase persistence

As can be seen in figure 15 above, TeamTNT delete the malicious container with which they gained the initial access, thus reducing the chances of detection. Then they run chmod -x on container runtime component, which prevents it from being executed. Thus, preventing from other attackers to exploit the misconfiguration of exposed Docker API and blocking the initial access. This increases the persistence of the attack.

In part 1 of this blog, we reported about TeamTNT’s cloud worm – silent bob. In one of the containers, TeamTNT used an interesting persistence technique. They ran the container with the --restart=always flag, which means that if for some reason the container stops it will always attempt restarting, hence creating a new persistence technique.

Figure 16: A part of the botnet infection script, containing docker execution with high privilege and persistence

Privilege escalation

As depicted in figure 16 above, TeamTNT is running the container as a privileged one, and mounting the host, this enables privileged access to the host.

Defense evasion

In figure 16 above, TeamTNT is using dload() function which is utilizing dev/tcp to invoke communication and download payloads, instead of using wget or curl which might be monitored or don’t exist on the machine. This helps them evade detection.

TeamTNT is using prochider rootkit to hide cryptomining execution. As seen in figure 17 below, TeamTNT is writing to /tmp/ld.so an SO file which contains prochider. It is moved to /dev/shm and loaded to ld.preload. This will ensure the prochider is running and hiding the xmrig in processes whenever the user is running ps, for instance, to check running processes.

Figure 17: this function deploys prochider rootkit hidden in ldpreload.

Credential Access

In the script grab.sh depicted in Figure 18 below, you can see the types of credentials that TeamTNT’s scripts are designed to scan for.

Figure 18: Some lists of credential files that TeamTNT is looking to extract from targeted hosts.

As depicted in Figure 19 below, the get_azure() function is designed to scan for Azure configuration files, which can include sensitive information such as secrets and environment data.

Figure 19: the get_azure() function reflects what TeamTNT is looking for in Azure cloud

As shown in Figure 20 below, the ‘get_google()’ function is configured to scan for Google Cloud Platform (GCP) configuration files, which can include sensitive information such as secrets and environment data.

Figure 20: the get_google() function reflects what TeamTNT is looking for in GCP

TeamTNT is scanning for credentials across multiple cloud environments, including AWS, Azure, and GCP. They are not only looking for general credentials but also specific applications such as Grafana, Kubernetes, Docker Compose, Git access, and NPM. Additionally, they are searching for databases and storage systems such as Postgres, AWS S3, Filezilla, and SQLite. They are also targeting more unique systems such as ngrok data, Samba, Censys, and others. This indicates that TeamTNT has evolved alongside the industry, shifting from solely targeting containers (as seen in 2019) to becoming a threat actor that targets cloud native applications. As the attack surface expands, they are leveraging the expertise they’ve gained in the cloud over the past few years to gain initial access, move laterally across the cloud, and deploy backdoors and further malware for their benefit.

From k8s clusters, TeamTNT is collecting cluster secrets with the function illustrated in figure 21 below:

With the curl command, using the token, TeamTNT is calling the secrets via the API server. With the second function TeamTNT is collecting further information about the environment, such as pods, deployments, secrets and daemonsets.

Discovery

The env_aws() function is used to connect to AWS meta-data server to collect sensitive infotmation about the account, such as keys, secrets, IAM roles etc.

The next 3 functions are very interesting. TeamTNT is collecting information about AWS, Azure, Kubernetes and running containers from running containers, processes and AWS configuration files.

Downloading kubectl tool to better query the k8s cluster.

Figure 24: downloading kubectl tool to better explore k8s environments

As seen in figure 25 below, TeamTNT is running 2 functions to discover the k8s environment, more specifically the sysvars and namespaces.

Figure 25: further discovery of k8s environments

As depicted in figure 26 and 27 below, TeamTNT is running in pacu.sh, a pip install command to install Pacu Python package. In the second figure you can see the configuration of what TeamTNT is looking for. They are after various AWS services, including EC2, Glue, Lambdas, and Lightsail, which is a virtual private server (VPS) provider and is the easiest way to get started with AWS for developers, small businesses, students, and other users who need a solution to build and host their applications on cloud. In the past it was reported as an interesting attack vector, since it is aimed for less proficient practitioners, thus more susceptible to misconfigurations.

Figure 26: Pacu package on Pypi

Figure 27: Pacu configuration file

Command and Control

TeamTNT is using Tsunami malware, as explained above, this is done by deploying and executing ELF files (a, system, systems). In figure 28 below you can see command execution via IRC channel.

Figure 28: IRC commands passed to infected hosts

Impact of TeamTNT on the Software Development Lifecycle

TeamTNT doesn’t directly compromise the code creation phase. However, their actions can indirectly impact code security. By targeting source code management applications such as GitHub they can impact organizations code, and even open a supply chain attack vector.

In the same manner TeamTNT can affect the CI/CD and Build processes by compromising GitHub or NPM. In addition, they are extensively scanning for misconfigured Kubernetes (k8s) clusters, Docker API, and Weave Scope. They can attack any of these stages: development, staging and production environments and compromise any of them. By exploiting misconfigurations in these components, or stealing artifact registries secrets, they can gain unauthorized access to the CI/CD pipeline infrastructure, potentially compromising the build process, injecting malicious code, or tampering with build artifacts. This can lead to the deployment of compromised or vulnerable applications into the runtime environment.

In the runtime phase, TeamTNT targets cloud native environments and cloud service providers. As mentioned above, they extensively seek for misconfigurations in Docker and K8s environments, and they seek unauthorized access to data and secrets stored in services such as Glue, S3 buckets, and Lambdas. By compromising these resources, they can potentially gain access to sensitive data, manipulate runtime configurations, or disrupt the normal operation of the applications.

Attributing this campaign to TeamTNT

The infrastructure in question shares significant similarities with previous campaigns attributed to TeamTNT, including the same coding style, similar infrastructure choices, targeting similar systems, and employing comparable tools and coding conventions. However, the focus this time seems to be more on infecting systems and testing the botnet, rather than deploying cryptominers for profit.

TeamTNT was known for its unique approach, often communicating with researchers through ASCII art, Twitter, and embedded messages in their code and malware. However, in this latest round of activity, after seemingly coming out of retirement, they have become noticeably less communicative.