Skip to content

Article by Nick Frichette

Bypass Credential Exfiltration Detection

  • Tools mentioned in this article

    SneakyEndpoints: Hide from the InstanceCredentialExfiltration GuardDuty finding by using VPC Endpoints

A common technique when exploiting AWS environments is leveraging SSRF, XXE, command injection, etc. to steal IAM credentials from the instance metadata service of a target EC2 instance. This can allow you to execute AWS API calls within the victim's account, however, it comes with a risk. If you were to try to use those credentials outside of that host (for example, from your laptop) an alert would be triggered. There is a GuardDuty finding which detects when IAM credentials are being used outside of EC2 called UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS.

To get around this alert being triggered, attackers could use the stolen credentials from the attacker's EC2 instance. The alert only detected if the credentials were used outside of EC2, not the victim's specific EC2 instance. So by using their own, or exploiting another EC2 instance, attackers could bypass the GuardDuty alert.

On January 20th 2022, AWS released a new GuardDuty finding called UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.InsideAWS. This new finding addressed the shortcomings of the previous one. Now, when IAM credentials are used from ANY EC2 instance, if those credentials don't belong to the same account as the EC2 instance which generated them, it triggers the alert. Thus, simply using your own EC2 instance is no longer viable. This addresses a long standing concern within the cloud security community.

However, there is currently a functioning bypass for this - VPC Endpoints. Using VPC Endpoints will not trigger the GuardDuty alert. What this means is that, as an attacker, if you steal IAM credentials from an EC2 instance, you can use those credentials from your own EC2 instance while routing traffic through VPC Endpoints. This will not trigger the GuardDuty finding.

Warning

Starting in October 2024, GuardDuty began detecting these bypass attempts for services that support CloudTrail network activity events for VPC endpoints. Initially, this applied only to EC2, KMS, Secrets Manager, and CloudTrail, but by mid-2025, it had expanded to 26 services. This means the technique may no longer be reliable depending on the target service — always test current behavior and consult the latest AWS documentation to verify which services will trigger the alert.

Note

There is another bypass option, however, it would only be useful in niche scenarios. The InstanceCredentialExfiltration finding is only tied to the AWS account, not the EC2 instance. As a result, if you compromise an EC2 instance in the target account and then compromise OTHER EC2 instances in the account, or steal their IAM credentials, you can safely use them from the initially compromised instance without fear of triggering GuardDuty.

SneakyEndpoints

To make this setup faster/easier for Penetration Testers and Red Teamers, SneakyEndpoints was created. This project is a collection of Terraform configurations which can quickly spin up an environment to attack form. It will create an EC2 instance in a private subnet (no internet access) and create a number of VPC Endpoints for you to use. This setup ensures we don't accidentally access an internet facing API endpoint and trigger the alert.

Setup and Usage

To use SneakyEndpoints first install Terraform and set AWS credentials within your shell session.

Next, perform the following Terraform commands:

terraform init
terraform apply

Before continuing Terraform will ask you to confirm the deployment. After that, way ~10 minutes for everything to be done. Please note that after the deployment is finished it may take a short period of time for the EC2 instance to be connectable.

After this period of time, connect to the EC2 instance using the AWS Systems Manager Session Manager.

To teardown the infrastructure, run the following command:

terraform destroy

Using STS

Due to a quirk in how STS is setup, you will have to set a specific environment variable with the following command.

export AWS_STS_REGIONAL_ENDPOINTS=regional

This is because some versions of the AWS SDK default to using the global STS endpoint at sts.amazonaws.com. This is problematic because VPC endpoints are regional (e.g. sts.us-east-1.amazonaws.com). The result is that if you use a version that is expecting the global endpoint with SneakyEndpoints, the connection will timeout.