Credential Access

The adversary is trying to steal account names and passwords. Credential Access consists of techniques for stealing credentials like IAM access and secret keys. Techniques used to get credentials include using the Cloud Instance Metadata API and finding Credentials in Files. Using legitimate credentials can give adversaries persistent access to AWS services and make them harder to detect, ultimately helping the adversary achieve their goals.

Techniques

Techniques: 3

ID Name Description

ID	Name	Description
T1552	Unsecured Credentials	Adversaries may search compromised systems to find and obtain insecurely stored credentials. These credentials can be stored and/or misplaced in many locations on a system, including plaintext files (e.g. Bash History [MITRE] ), operating system or application-specific repositories (e.g. Credentials in Registry [MITRE] ), or other specialized files/artifacts (e.g. Private Keys [MITRE] ).
↳	T1552.005	Cloud Instance Metadata API	Adversaries may attempt to access the Cloud Instance Metadata API to collect credentials and other sensitive data. Most cloud service providers support a Cloud Instance Metadata API which is a service provided to running virtual instances that allows applications to access information about the running virtual instance. Available information generally includes name, security group, and additional metadata including sensitive data such as credentials and UserData scripts that may contain additional secrets. The Instance Metadata API is provided as a convenience to assist in managing applications and is accessible by anyone who can access the instance. A cloud metadata API has been used in at least one high profile compromise. If adversaries have a presence on the running virtual instance, they may query the Instance Metadata API directly to identify credentials that grant access to additional resources. Additionally, attackers may exploit a Server-Side Request Forgery (SSRF) vulnerability in a public facing web proxy that allows the attacker to gain access to the sensitive information via a request to the Instance Metadata API. The de facto standard across cloud service providers is to host the Instance Metadata API at `http[:]//169.254.169.254`. AWS Specific Content A prerequisite for this technique is an Amazon EC2 instance hosting a vulnerable application where IMDSv2 is either configured as an optional configuration, or not configured at all. Instance metadata is data about an Amazon EC2 instance that can be used to configure or manage running instances, and can include configuration data about the EC2 instance and also security data such as credentials for attached instance profiles. If a threat actor gains the ability to compromise the application or operating system running on the EC2 instance, it may be possible for them to retrieve security credentials using the instance metadata service. The use of this technique can typically occur after a threat actor gains Initial Access into the environment through the EC2 Hosted Application Compromise technique. A common example of this is where threat actors compromise an application through the use of SSRF (Server Side Request Forgery) to execute code remotely on the application hosted by the EC2 instance. If IMDSv2 is not configured on the EC2 instance, or only configured as optional, and the application has been compromised, the threat actor may then retrieve the EC2 instance credentials which can be used by the adversary to access resources and services within the AWS account.
↳	T1552.001	Credentials In Files	Adversaries may search local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords. It is possible to extract passwords from backups or saved virtual machines through OS Credential Dumping [MITRE] . Passwords may also be obtained from Group Policy Preferences stored on the Windows Domain Controller. In cloud and/or containerized environments, authenticated user and service account credentials are often stored in local configuration and credential files. They may also be found as parameters to deployment commands in container logs. In some cases, these files can be copied and reused on another machine or the contents can be read and then used to authenticate without needing to copy any files. AWS Specific Content A prerequisite of this technique is that the credentials of an AWS IAM identity are stored in an unsecured manner, either on a local file system, or on the public internet. Threat actors may search on-premise local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords. A file commonly associated with this technique is the `.env` file, which is an environment variable file used on some services and operating systems. This file is used to store configuration information about the host service or operating system on the host, but can also contain long-term AWS IAM credentials saved within the file. AWS credentials have also previously been found in files publicly available via GitHub and used by threat actors to gain access into an AWS account.

T1552

Unsecured Credentials

Adversaries may search compromised systems to find and obtain insecurely stored credentials. These credentials can be stored and/or misplaced in many locations on a system, including plaintext files (e.g. Bash History [MITRE] ), operating system or application-specific repositories (e.g. Credentials in Registry [MITRE] ), or other specialized files/artifacts (e.g. Private Keys [MITRE] ).

↳

T1552.005

Cloud Instance Metadata API

Adversaries may attempt to access the Cloud Instance Metadata API to collect credentials and other sensitive data.

Most cloud service providers support a Cloud Instance Metadata API which is a service provided to running virtual instances that allows applications to access information about the running virtual instance. Available information generally includes name, security group, and additional metadata including sensitive data such as credentials and UserData scripts that may contain additional secrets. The Instance Metadata API is provided as a convenience to assist in managing applications and is accessible by anyone who can access the instance. A cloud metadata API has been used in at least one high profile compromise.

If adversaries have a presence on the running virtual instance, they may query the Instance Metadata API directly to identify credentials that grant access to additional resources. Additionally, attackers may exploit a Server-Side Request Forgery (SSRF) vulnerability in a public facing web proxy that allows the attacker to gain access to the sensitive information via a request to the Instance Metadata API.

The de facto standard across cloud service providers is to host the Instance Metadata API at http[:]//169.254.169.254.

AWS Specific Content

A prerequisite for this technique is an Amazon EC2 instance hosting a vulnerable application where IMDSv2 is either configured as an optional configuration, or not configured at all.

Instance metadata is data about an Amazon EC2 instance that can be used to configure or manage running instances, and can include configuration data about the EC2 instance and also security data such as credentials for attached instance profiles. If a threat actor gains the ability to compromise the application or operating system running on the EC2 instance, it may be possible for them to retrieve security credentials using the instance metadata service.

The use of this technique can typically occur after a threat actor gains Initial Access into the environment through the EC2 Hosted Application Compromise technique. A common example of this is where threat actors compromise an application through the use of SSRF (Server Side Request Forgery) to execute code remotely on the application hosted by the EC2 instance. If IMDSv2 is not configured on the EC2 instance, or only configured as optional, and the application has been compromised, the threat actor may then retrieve the EC2 instance credentials which can be used by the adversary to access resources and services within the AWS account.

↳

T1552.001

Credentials In Files

Adversaries may search local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords.

It is possible to extract passwords from backups or saved virtual machines through OS Credential Dumping [MITRE] . Passwords may also be obtained from Group Policy Preferences stored on the Windows Domain Controller.

In cloud and/or containerized environments, authenticated user and service account credentials are often stored in local configuration and credential files. They may also be found as parameters to deployment commands in container logs. In some cases, these files can be copied and reused on another machine or the contents can be read and then used to authenticate without needing to copy any files.

AWS Specific Content

A prerequisite of this technique is that the credentials of an AWS IAM identity are stored in an unsecured manner, either on a local file system, or on the public internet.

Threat actors may search on-premise local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords.

A file commonly associated with this technique is the .env file, which is an environment variable file used on some services and operating systems. This file is used to store configuration information about the host service or operating system on the host, but can also contain long-term AWS IAM credentials saved within the file. AWS credentials have also previously been found in files publicly available via GitHub and used by threat actors to gain access into an AWS account.