AWS GuardDuty Exfiltration Bypass with VPC Endpoints

On January 20, 2022, Amazon AWS has introduced a new threat detection rule in GuardDuty.

GuardDuty is an AWS service (free for only 30 days) that detects suspicious activities in your AWS account; for example, it can alert you if an EC2 instance (basically a VM in the cloud) is performing a port scanning on your AWS IPs.

The new alert informs you when EC2 instance credentials are used to invoke APIs from an IP address that is owned by a different AWS account than the one that the associated EC2 instance is running.

The new finding name is:

• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS

The new GuardDuty alert of credential exfiltration inside AWS

What does this mean?

EC2 instance credentials are the temporary credentials made available through the EC2 metadata service (endpoint: http://169.254.169.254) to any applications running on an instance when an AWS Identity and Access Management (IAM) role is attached to it.

These credentials can be used to maliciously invoke APIs based on the permissions defined in the IAM role attached to the instance.

If an attacker is able to access the metadata service of an EC2 using, for example with RCE, XXE or SSRF vulnerabilities, it can impersonate the role attached to the instance and perform lateral movements or privilege escalations in the AWS organization.

Command to dump the EC2-METAVERSE role from the instance metadata service

How was it before?

Before the 20/01/2022 an attacker could have used any AWS account to bypass the detection in case of stolen credentials.

If the attacker were to try to use those credentials outside of that compromised AWS host (for example the attacker’s laptop) an alert on GuardDuty would be triggered and the security team notified with the signature: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS.

GuardDuty alert of credential exfiltration outside AWS

Nevertheless, attackers could just use an EC2 instance to bypass the detection because the alert only detects if the credentials were used outside of AWS, not the victim’s specific AWS account.

Steps to bypass the old detection:

• the attacker gains access to an EC2 instance
• the attacker dumps the EC2 attached role credentials
• the attacker spawns a cloud shell or an EC2 instance on its own AWS account
• the attacker imports the stolen credentials in its cloud shell or EC2 instance

VPC Endpoints

With the new threat detection is not possible to perform the above steps because AWS will also detect for InsideAWS exfiltrations. This means that AWS will check if the IP that is performing the API requests is associated with the same AWS account of the IAM role used to authenticate the API call.

Once Amazon released the new detection a penetration tester, Nick Frichette, found a bypass using VPC Endpoints.

Keep in mind that VPC Endpoints are not free despite its cost is cheap.

What this means is that if an attacker can steal the IAM credentials from an EC2 instance, it can use those from its personal EC2 instance configured to route the traffic through VPC Endpoints since they will not use public IPs to call AWS APIs.

VPC Endpoints enable connections between a Virtual Private Cloud (VPC) and support services without using an Internet Gateway: the traffic is routed internally to AWS.

There are two types of VPC Endpoint:

• Interface: a network interface with private IP inside a subnet acting as an entry point for traffic destined to an AWS service
• Gateway: a target for a route for traffic destined to S3 or DynamoDB services

For the bypass, the first type is used.

To automate the process for faster and easier setup SneakyEndpoints was created (use this fork for EU-based deployment).

The SneakyEndpoint project uses Terraform to spin up a quite complete environment for attackers:

• creates an EC2 instance in the private subnet (without internet access)
• creates a number of VPC Endpoint to communicate with S3, EC2, RDS, EBS, ECS, RedShift, CloudTrail, STS, CodePipeline, KMS, Lambda, SNS, SQS services

To use the project:

1. git clone https://github.com/notdodo/SneakyEndpoints.git
2. edit the provider.tf file with the AWS profile to use
3. terraform init
4. terraform apply
5. wait for the deployment and then using the EC2 web page connect to the sneakyendpoints_host instance using SSM

Connection to the EC2 using SSM

Once inside the EC2 confirm that the instance is not connected to internet.

No internet access

Now import the exfiltrated credential in the attacker EC2 instance.

Credential import and EC2 listing

And continue with the attack chain with triggering any alert on GuardDuty.

No GuardDuty findings

PROFIT!

Do not forget to run terraform destroy once done with the attack to avoid facing useless billing.

Conclusions

Without the new AWS GuardDuty threat detection, credential exfiltration was way more easier because it only required a Cloud Shell or an EC2 in any AWS account.

The new detection, even with the SneakyEndpoint bypass, is not straightforward as before and Amazon has done great work to protect our cloud environments.

References

• https://aws.amazon.com/blogs/aws/amazon-guardduty-enhances-detection-of-ec2-instance-credential-exfiltration/
• https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html#unauthorizedaccess-iam-instancecredentialexfiltrationinsideaws
• https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints.html
• https://twitter.com/Frichette_n/status/1484314130626449417
• https://github.com/Frichetten/SneakyEndpoints