21 August 2025

How to stop data exfiltration from private subnets on AWS

Shaun Webber

Penetration Testing Team Leader

When conducting AWS configuration reviews and Virtual Private Cloud (VPC) endpoints are in use, we find that, more often than not, they are configured with permissive default policies which allow all actions, principals and resources and therefore can be exploited to easily exfiltrate data from the AWS environment. In this blog, we will demonstrate how to configure VPC endpoints to secure your AWS environment from malicious attackers.

VPC endpoints are an AWS networking feature which provide private connections between resources within a VPC to supported AWS services using the backbone network and private APIs of each service. This configuration ensures that resources within a VPC do not require an Internet connection or VPN to communicate with other AWS services, directly supporting the implementation of secure isolated networks which do not require the use of potentially insecure public infrastructure.

Fig. 1 – Screenshot of an example Default VPC Endpoint Policy

{
  "Statement": [
    {
      "Action": "*",
      "Effect": "Allow",
      "Principal": "*",
      "Resource": "*"
    }
  ]
}

Fig. 2 – Code block of the Default VPC Endpoint Policy

As an example, using a VPC endpoint, a service on an EC2 instance can make a request to the private API endpoint of an S3 bucket to download required objects, if a VPC endpoint has not been created for the S3 service, traffic will instead require a route via an internet gateway or similar device to the public, internet-facing S3 API endpoint, making it discoverable for attackers.

Several VPC endpoint service types include the ability to configure endpoint policies to restrict the communications of resources with the associated AWS services. If no endpoint policy is defined when the endpoint is created, AWS will automatically attach a default policy which provides full, unrestricted access to the associated service, including principals in other AWS accounts. As the default policy provides full access to the service, a malicious actor with access to a private subnet within the VPC could leverage the configuration to extract data from the AWS environment and write data to another service controlled by an attacker.

Here are two more common examples of AWS services that can be leveraged via an overly permissive VPC endpoint policy to extract data from private or heavily filtered subsets. There are likely many more.

S3

An S3 VPC endpoint with the default full access policy would provide full access to the private S3 APIs which could be used to extract sensitive information to an S3 bucket within an attacker controlled AWS account.

This can be achieved in several ways. One common method is, if a malicious user has access to an EC2 instance within the VPC, they could upload the AWS access keys of an IAM user with write permission to an S3 bucket within their own account and use these permissions to exfiltrate data to their S3 bucket via the VPC endpoint.

Additionally, tools like S3Backdoor can be used to set up covert remote command and control channels which can be used by an attacker to maintain access and pillage sensitive data.

SSM

A slightly more involved example is leveraging the Systems Manager (SSM) service. An overly permissive SSM VPC endpoint can be used to access EC2 instances in an attacker-controlled account via the SSM “send-command” and “start-session” commands.

Firstly, an attacker with access to a compromised EC2 instance in a private subnet creates an EC2 instance in an external attacker-controlled account which has the “AmazonSSMManagedInstanceCore” policy attached to its instance profile and the SSM agent installed. The attacker then needs to upload IAM access keys for an IAM user account with the “AmazonSSMFullAccess” AWS managed policy attached. These can then be used on the compromised EC2 instance in the private subnet to run the AWS CLI SSM “start-session” and “send-command” commands via the SSM VPC endpoint, and copy data to the EC2 instance hosted in the attacker-controlled account.

Recommendations

Claranet’s recommendations for securing VPC endpoints are:

Create VPC endpoints for each supported service within each VPC to limit the requirement for internet connectivity and provide secure access to AWS services.

Create a custom policy in line with the principal of least privilege for all supported VPC endpoints in use within the AWS environment.

These policies should ensure that network connections to AWS services is only accessible to those resources within the internal AWS account or organisation.

Care should be taken to restrict access to individual resources by name or Amazon Resource Name (ARN) and minimise the use of wildcards which may provide unintended access to services.

Interface endpoints

Additionally there are several types of VPC endpoints available including Interface endpoints which are a type of network interface providing access to the PrivateLink network for access to services. These Interface endpoints also support the use of security groups to restrict traffic, however it is recommended that these security groups are used in tandem with VPC endpoint policies as a defence-in-depth approach to implementing fine grained access controls.

Gateway endpoints

Other VPC endpoint types such as Gateway endpoints which act as route tables do not support the use of security groups and as such it is essential that a restrictive endpoint policy is implemented to restrict traffic to external resources.

Securing VPC endpoints: an example endpoint policy

{
  "Statement": [
    {
      "Action": "S3:*",
      "Effect": "Allow",
      "Resource": ["*:*:*:*:xxxxxxxxxxxx:*", "*:*:*:*:yyyyyyyyyyyy:*"],
      "Principal": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-zzzzzzzzzz"
        }
      }
    }
  ]
}

Fig. 3 – An example S3 service

This example policy ensures that resources in the isolated network can only use the VPC endpoint for S3 if they try to interact with S3 buckets controlled by specific accounts (xxxxxxxxxxxx and yyyyyyyyyyyy) and only if the principal is from your Org (o-zzzzzzzzzz). In this situation and attacker would not able to access any S3 buckets they control.

Speak to one of our cybersecurity experts for more information about how you can secure your cloud environment. 