|
Unsecured Credentials: Cloud Instance Metadata API
Other sub-techniques of Unsecured Credentials (4)
| ID | Name |
|---|---|
| T1552.005 | Cloud Instance Metadata API |
| T1552.001 | Credentials In Files |
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
Detection
AWS Specific Content
When this technique is used by the threat actor, actions taken by the threat actor using the credentials obtained through the instance metadata service will still be logged in CloudTrail.
When this technique is used by the threat actor, actions taken by the threat actor using the credentials obtained will be logged in CloudTrail. You can use the Event history page in the AWS CloudTrail console to view the last 90 days of management events in an AWS Region for the events logged which, if this technique is used, will include the EC2 instance ID (from which the credentials were obtained) in the
userIdentity.arn fields of the CloudTrail event record instead of just the name of an IAM user or role.A separate CloudTrail trail will give you an ongoing record of events in your AWS account past 90 days and can be configured to log events in multiple regions. You can also review events using the console as well as the AWS CLI.
It is also possible to create a CloudWatch metric filter to watch for when specific AWS API calls are used and perform notification actions if logged, and additionally configure CloudWatch to automatically perform an action in response to an alarm.
For other methods of detection, configure, review, and monitor VPC Flow logs for access to the EC2 instance. If the EC2 instance is placed behind an ELB, ELB logs can also be reviewed for access to the EC2 instance. AWS GuardDuty provides detection for when EC2 instance credentials are accessed and used.
You can also use AWS Config Rules to check if IMDSv2 is configured on your EC2 instances. Security Hub controls can also check whether EC2 instances are configured to require the use of IMDSv2.
Mitigation
AWS Specific Content
You can mitigate the unauthorized misuse of IMDS by configuring IMDSv2 on EC2 instances, and making sure that IMDSv2 is set to required. By using AWS Config you can use the ec2-imdsv2-check rule to check whether your Amazon EC2 instance metadata version is configured with IMDSv2. The rule is NON_COMPLIANT if the
HttpTokens is set to optional, which means that the EC2 instance does not have IMDSv2 as a required configuration.You can also use Service Control Policies to restrict where EC2 instance credentials can be used from. The example policy denies access if the value of
aws:SourceVpc is not equal to the value of aws:ec2InstanceSourceVPC, or if the value of aws:VpcSourceIp is not equal to the value of aws:ec2InstanceSourcePrivateIPv4. This means that the request to an AWS service must pass through a VPC endpoint, and originate from the same EC2 instance that an instance's credential was issued to in order to allow access.