TeamTNT Upgrades Arsenal, Refines Focus on Kubernetes and GPU Environments
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.
Save to Folio
In previous entries, we described how the hacking group TeamTNT targeted unsecured Redis instances, exposed 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.
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.
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.
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.
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 |