APT & Targeted Attacks
TeamTNT Continues Attack on the Cloud, Targets AWS Credentials
While investigating the team's activities, we found a binary containing a hardcoded shell script designed to steal AWS credentials, which provided us a lead on the scope of the attack.
Save to Folio
We covered the threat actor group TeamTNT in previous entries, noting that they were actively stealing Amazon Web Services (AWS), Docker and Linux Secure Shell (SSH) credentials as well as participating in other activities, including cryptojacking and placing backdoors — such as IRC bots and remote shells — inside Linux devices. However, the scope of the attack remained unknown. While investigating the team's activities, we found a binary containing a hardcoded shell script designed to steal AWS credentials, which provided us a lead on the scope of the attack.
We begin by examining the dropped script from a new AWS-focused credential stealer. As the image in Figure 2 shows, after the actor compromises an instance and runs their script, it searches for any credentials deployed via the AWS metadata service, as we previously highlighted. To gather these credentials, the attacker must perform remote code execution (RCE) on the initial target, which can be accomplished via a number of methods, including abusing the abuse of such as abusing misconfiguration issues or the exploitation of exploiting unpatched vulnerabilities and other security flaws. An AWS instance, by default, does not have any identity access management (IAM) permissions attached; rather, these permissions must be defined by the AWS administrator. AWS administrators should follow the principle of least privilege when attaching roles to an AWS instance. Regardless of whether this search is successful or not, the script creates a file and then uploads it to a remote web server that is set to receive the stolen files.
Although the script is meant to run on AWS instances, our analysis reveals that it ran on any kind of Linux machine, container, or cloud instance when they are compromised by this actor. Additionally, it failed to retrieve any useful data most of the times.
The web server where the malware uploads its data was configured (or misconfigured) to be set as open directory, thus allowing access to all the uploaded files — including data on targets to be further compromised, stolen files, and statistics of ongoing attacks.
Alongside storing the stolen data, the server also serves as a repository for Linux cryptocurrency-mining tools that the group deploys on infected systems, which is part of their objectives.
If the group succeeds in running their malicious script on an AWS instance, the script uploads any credentials that it is able to retrieve from the instance metadata service. If an AWS administrator has not attached any permissions to these credentials, then they will not grant the attacker any additional access. AWS administrators can also detect the use of these instance credentials outside of AWS by enabling the UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration finding in Amazon GuardDuty.
Conclusion and impact
During our research, we noticed over 4,000 infected instances. While not all of them necessarily ran on AWS instances, the malware that was deployed against them was designed to target AWS users (due to the shell script looking for AWS services metadata that is present only with AWS services). From the total number, around 5% or approximately 200 of them contained sensitive information on AWS costumers. Note that AWS instances will not have permissions defined unless the user specifically takes action for such.
Based on the timestamps in the file names, we can assume that the campaign started on February 10, 2021. In addition, we can also assume that the number of files represents the number of infected machines. As a result of observing TeamTNT for a while now, we are able to note that they are following IT industry trends and shifting to the cloud as well.
Recommendations and Trend Micro Solutions
Given the increased focus on the cloud by threat actor groups, organizations should take the necessary steps to secure as much of their cloud infrastructure as they can. Most cloud service providers, including AWS, follow the shared responsibility model for securing the cloud. Following this model, the cloud provider is responsible for securing the infrastructure — such as the hardware, software, networking, and facilities — needed to run the cloud service. On the other hand, AWS adminstrators are tasked with the responsibility of securing their assets running within the cloud service. Although the specifics differ depending on the type of cloud service being used, AWS administrators are generally expected to secure their own data, platforms, applications, operating systems, and network configurations, among others.
As mentioned earlier, Team TNT is targeting cloud service providers and is able to compromise AWS instances based on a number of methods. Hence on the shared responsibility model, the AWS administrator is responsible for securing its instances. We advise organizations to consider the following security measures:
- Patch and update systems regularly to reduce the chance of vulnerability exploitation.
- Apply the principle of least privilege, which helps reduce the attack surface and minimizes the damage potential of an attack. For this specific TeamTNT attack, granting access to security information only to those who need it can prevent the threat actors from leaking the information.
- Prioritize the continuous monitoring and auditing of devices, especially if these are used to access the organization’s network.
- Use private key authentication when you have SSH enabled inside your instance.
- Use strong passwords and always enable multifactor authentication on your cloud account.
Amazon also offers additional recommendations on how to secure AWS resources, as well as services such as Amazon GuardDuty, Amazon Macie, and AWS Security Hub that enhance the existing security of cloud implementations.
Security solutions such as Trend Micro Hybrid Cloud Security can also help in protecting cloud-native systems and their various layers. By using Trend Micro Cloud One™, enterprises gain access to protection for continuous integration and continuous delivery (CI/CD) pipeline and applications. The Trend Micro Cloud One platform includes:
- Workload Security: runtime protection for workloads
- Container Security: automated container image and registry scanning
- File Storage Security: security for cloud file and object storage services
- Network Security: cloud network layer IPS security
- Application Security: security for serverless functions, APIs, and applications
- Conformity: real-time security for cloud infrastructure — secure, optimize, comply
Indicators of Compromise (IOCs)
SHA-256 |
Detection |
Description |
9504b74906cf2c4aba515de463f20c02107a00575658e4637ac838278440d1ae |
Backdoor.Linux.TSUNAMI.USELVBF21 |
IRC bot |
3139a85a18e42bf60ba65deb3d691b5c088a0fac2b80a4d05f17a68eac3d4882 |
TrojanSpy.SH.AWSTEAL.A |
Script |