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

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.

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.

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:
git clone https://github.com/notdodo/SneakyEndpoints.git
- edit the
provider.tf
file with the AWS profile to use terraform init
terraform apply
- wait for the deployment and then using the EC2 web page connect to the
sneakyendpoints_host
instance using SSM

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

Now import the exfiltrated credential in the attacker EC2 instance.

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

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