ALPS blog

TeamTNT Upgrades Arsenal, Refines Focus on Kubernetes and GPU Environments

In previous entries, we described how the hacking group TeamTNT targeted unsecured Redis instancesexposed Docker APIs, and vulnerable Kubernetes clusters in order to deploy cryptocurrency-mining payloads and credential stealers. TeamTNT was one of the first cybercriminal groups to focus on cloud service providers (CSPs), specifically the metadata stored on elastic computing instances being run on cloud services. It is mainly engaged in the theft of environmental metadata used by CSPs. Because instance metadata and user data can’t be authenticated or encrypted, it’s important for users to avoid storing sensitive data in metadata fields, including secrets and CSP-related preauthorization data which can then be used in other services such as serverless deployments.

If a running instance used by a CSP customer is not properly configured or has a security weakness such as exposed APIs or leaked credentials, malicious actors who are able to abuse these security flaws might be able to use other services as well. Therefore, it’s important for organizations to safeguard critical authentication credentials, or secrets, to ensure that they are out of cybercriminals’ reach.

Today, TeamTNT remains to actively exploit compromised cloud environments in its campaigns. Using a new batch of campaign samples, we take a look at its more recent cybercrime contributions and compare them with its previous deployments to demonstrate the group’s use of upgraded tools and payloads.

TeamTNT’s upgraded arsenal

What stands out from our analysis is that the samples obtained from TeamTNT’s recent campaigns look more professionally developed than previous versions. The samples, which cover more corner cases and include bug fixes, show marked improvements in how the hacking group targets misconfigured Amazon Web Services (AWS) or Kubernetes services.With cybercriminals setting their sights on cloud deployments, it’s important for cloud users to understand the importance of the shared responsibility model. Users play an important role in the overall security of their cloud environments. Cloud users are in charge of securing the data, platforms, applications, and operating systems that they run within their respective cloud services. Hence, they must also be aware of where to place critical data within the cloud environment for it not to be targeted by malicious actors.

Rather than incorporating all-in-one samples with multiple functionalities, TeamTNT’s attacks have become more modular. The samples have a defined scope and feature well-defined functions, showing how the group has evolved to apply a more targeted approach to its campaigns.

TeamTNT’s typical attack chain
Figure 1. TeamTNT’s typical attack chain
An older version of TeamTNT’s AWS credential stealer (left) compared with newer versions (middle and right) from instances that they have already compromised
Figure 2. An older version of TeamTNT’s AWS credential stealer (left) compared with newer versions (middle and right) from instances that they have already compromised

Earlier this year, we detailed how TeamTNT crafted a hard-coded shell script that targeted credentials from vulnerable AWS instances. Aside from AWS, we have also observed how TeamTNT has refined its development of tools specifically for one of its primary targets, Kubernetes.

Figure 3 shows TeamTNT samples that target different Kubernetes environments, obtained in August and September 2021. These show that TeamTNT has developed multiple payloads for different targeted Kubernetes environments. Upon closer look, the payloads have minor changes specifically geared toward adapting a bit better to the infected environment: They are less noisy as they are less generic, and they change command-and-control addresses as they get updated.

TeamTNT tools targeting Kubernetes environments using different payloads
Figure 3. TeamTNT tools targeting Kubernetes environments using different payloads

Checking this trend with Shodan data, we see that TeamTNT’s focus on Kubernetes deployments makes sense since the number of open and exposed Docker APIs has been decreasing. In September 2021, the number of exposed Docker APIs was 836, down from 7,276 12 months prior. Meanwhile, the number of vulnerable Kubernetes APIs has been increasing since June 2021. In September 2021, exposed Kubernetes APIs even reached 161,993.

Shodan data showing a significant decrease in exposed Docker APIs from the latter part of 2020 to 2021
Figure 4. Shodan data showing a significant decrease in exposed Docker APIs from the latter part of 2020 to 2021
Shodan data showing a significant increase in exposed Kubernetes APIs in 2021
Figure 5. Shodan data showing a significant increase in exposed Kubernetes APIs in 2021

TeamTNT is also extending its focus on its mining hash rate by enhancing its chances to exploit devices equipped with GPUs by having toolsets designed for multiple GPU manufacturers. This is no surprise as the actual reward for mining monero cryptocurrency is getting lower. Thus, to mine the same amount of moneroj, a bigger contribution (with hashes provided) is needed, which in this case is indicated by the hash rate. Simply put, the bigger the hash rate, the higher the amount of money mined.

TeamTNT tools that target GPU environments
Figure 6. TeamTNT tools that target GPU environments

Conclusion and security recommendations

This entry highlights our three major observations on TeamTNT’s recent campaigns. The first concerns the changes the group has employed in its arsenal development. Rather than using messy, all-in-one malicious files, its new-generation payloads seem to be more professionally developed and targeted, and generates less noise during infection by reducing the number of executions and deploying more accurately.

Another crucial observation is that TeamTNT is developing more tools targeting Kubernetes. This is backed by in-the-wild Shodan data showing the number of exposed Kubernetes APIs. Because the hacking team has also mentioned the launch of a new Kubernetes campaign on its social media account, we highly recommend that Kubernetes users pay special attention to its deployments. However, despite TeamTNT’s apparent preference for exposed Kubernetes APIs, it still targets CSPs.

The final point is that the payloads now identify GPU-based environments and deploy specific payloads to target instances running in CSPs and take advantage of the computational power and generate more cryptocurrency by ill means.

With organizations relying on cloud services now more than ever, attacks targeting cloud services are likely to become more ubiquitous and sophisticated in the coming years. To keep systems and services protected against evolving threats, organizations should create strong security policies that highlight the shared responsibility model and the principle of least privilege. It is also a good practice to encrypt metadata or use obfuscated or otherwise non-sensitive metadata to ensure that critical data is kept secure. AWS provides a detailed example of encrypting metadata with the AWS Glue Data Catalog and a listing of ITAR-controlled data related to each AWS service.

Organizations can also benefit from prioritizing continuous monitoring and auditing, and regularly patching and updating their systems.

Indicators of compromise

SHA-256 Detection name
024445ae9d41915af25a347e47122db2fbebb223e01acab3dd30de4b3546496 TROJAN.SH.KIMERA.YXBJ3
06e8e4e480c4f19983f58c789503dbd31ee5076935a81ed0fe1f1af69b6f1d3d TROJAN.SH.KIMERA.YXBJ3
4a00f99ce55f6204abcfa0b0392c6ee4c6a9fa46e8c1015a7c411ccd1b456720 TROJAN.SH.KIMERA.YXBJ3
6075906fbc8898515fe09a046d81ca66429c9b3052a13d6b3ca6f8294c70d207 TROJANSPY.SH.CHIMAERA.AA
71af0d59f289cac9a3a80eacd011f5897e0c8a72141523c1c0a3e623eceed8a5 TROJAN.SH.KIMERA.YXBJ3
8bb87c1bb60cbf88724e88cf75889e6aa4fba24ab92a14aa108be04841a7aa86 TROJAN.SH.KIMERA.YXBJ3
9ad4daaa5503bef61bb9ae7e5e75e92c3afd7077296c9a0ddee8ee38a0ce380e TROJAN.SH.KIMERA.YXBJ3
b07ca49abd118bc2db92ccd436aec1f14bb8deb74c29b581842499642cc5c473 TROJAN.SH.KIMERA.YXBJ3
c57f61e24814c9ae17c57efaf4149504e36bd3e6171e9299fd54b6fbb1ec108c TROJAN.SH.KIMERA.YXBJ3
fa2a7374219d10a4835c7a6f0906184daaffd7dec2df954cfa38c3d4dd62d30d TROJAN.SH.KIMERA.YXBJ3
Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Featured News